US20170078961A1 - Smart co-processor for optimizing service discovery power consumption in wireless service platforms - Google Patents
Smart co-processor for optimizing service discovery power consumption in wireless service platforms Download PDFInfo
- Publication number
- US20170078961A1 US20170078961A1 US14/850,793 US201514850793A US2017078961A1 US 20170078961 A1 US20170078961 A1 US 20170078961A1 US 201514850793 A US201514850793 A US 201514850793A US 2017078961 A1 US2017078961 A1 US 2017078961A1
- Authority
- US
- United States
- Prior art keywords
- datapath
- data packets
- service
- incoming data
- wireless application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
- H04W52/02—Power saving arrangements
- H04W52/0209—Power saving arrangements in terminal devices
- H04W52/0261—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level
- H04W52/0274—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof
- H04W52/028—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof switching on or off only a part of the equipment circuit blocks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/02—Capturing of monitoring data
- H04L43/028—Capturing of monitoring data by filtering
-
- H04L67/16—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
- H04W52/02—Power saving arrangements
- H04W52/0209—Power saving arrangements in terminal devices
- H04W52/0251—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity
- H04W52/0258—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity controlling an operation mode according to history or models of usage information, e.g. activity schedule or time of day
-
- H04W76/023—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/14—Direct-mode setup
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Definitions
- Various aspects and embodiments described herein generally relate to a smart co-processor that may be provided in a wireless application processing datapath to optimize service discovery power consumption in wireless service platforms that employ out-of-band device-to-device (D2D) communication between peer wireless devices.
- D2D device-to-device
- Wireless communication systems are widely deployed to provide various types of communication content, including voice, video, packet data, messaging, and broadcast, among many others.
- Wireless communication systems e.g., multiple-access networks that can share available network resources to support multiple users
- 3G Third-generation
- 4G fourth-generation
- Example cellular systems include the cellular Analog Advanced Mobile Phone System (AMPS), digital cellular systems based on Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Orthogonal FDMA (OFDMA), Single-Carrier FDMA (SC-FDMA), the Global System for Mobile access (GSM) TDMA variation, and newer hybrid digital communication systems that use both TDMA and CDMA technologies. More recently, Long Term Evolution (LTE) has been developed as a wireless communication protocol for wireless communication of high-speed data for mobile phones and other data terminals.
- LTE Long Term Evolution
- LTE is based on GSM, and includes contributions from various GSM-related protocols (e.g., Enhanced Data rates for GSM Evolution (EDGE)) and Universal Mobile Telecommunications System (UMTS) protocols (e.g., High-Speed Packet Access (HSPA)).
- GSM-related protocols e.g., Enhanced Data rates for GSM Evolution (EDGE)
- UMTS Universal Mobile Telecommunications System
- HSPA High-Speed Packet Access
- a wireless communication network may include various base stations (also referred to as evolved node Bs, eNBs, or access nodes) that can support communication for a user equipment (UE).
- UE user equipment
- a UE typically communicates via uplink/downlink channels between the UE and a base station to thereby communicate with the base station.
- the UEs may be enabled to communicate directly, that is, without communicating through any base station.
- a UE may therefore support direct peer-to-peer (P2P) or device-to-device (D2D) communication with one or more other UEs.
- P2P peer-to-peer
- D2D device-to-device
- LTE-Direct (LTE-D, sometimes also referred to as “LTE-Advanced”) is a proposed 3GPP (Release 12) D2D solution for proximate discovery.
- LTE-D dispenses with location tracking and network calls by directly monitoring for services on other LTE-Direct devices within a large range ( ⁇ 500 m, line of sight).
- LTE-D can directly monitor for services on other LTE-D devices in a synchronous system and concurrently detect many services in proximity in a continuous and battery efficient manner.
- P2P Peer-to-Peer
- Wi-Fi Direct supports pre-association service discovery among peer wireless devices.
- the WFD protocol enables a client wireless device or station (STA) to query peer STAs within Wi-Fi range to determine what services, if any, are available on the peer STAs. Determining the services that peer STAs provide typically involves a device discovery phase and a service discovery phase.
- a client STA e.g., a STA requesting a particular P2P service
- the client STA queries any available peer STAs that may have been discovered during the device discovery phase about the services that the available peer STAs provide. For example, the client STA typically transmits one or more service discovery requests to each peer STA that supports the service discovery operation, one at a time, until the client STA identifies a suitable peer STA that provides the requested service.
- service discovery messaging and signaling is the bedrock for many wireless use cases and application platforms, which may include mirroring, screen sharing, streaming video, streaming audio, remote video/graphics rendition, remote audio rendition, remote sensing, remote control, and file transfers, among many others.
- service discovery messages and signaling can be used to support announcements and inquiries, composition and mediation, control and presentation, and can further be extended to group management and addressing control, quality of service (QoS) and/or quality of experience (QoE) management, and various other wireless use cases.
- QoS quality of service
- QoE quality of experience
- a wireless application processing datapath can include many ad-hoc devices that will often have unequal capabilities, processing densities, storage capacities, connection and power performance profiles, etc. Furthermore, any device can operate autonomously and without awareness of other devices, whereby operational dependencies and required collaboration among different devices are typically validated and resolved per-application and/or use case.
- a collaborative and distributed (unstructured) service discovery framework typically requires regular service discovery messaging, which may require that each peer device maintain one or more components in a wireless application datapath in an always-on state (e.g., a host bridge, interconnect and system memory, host application processor and high-level operating system typically used to process service discovery messages and signaling).
- a host bridge e.g., a host bridge, interconnect and system memory, host application processor and high-level operating system typically used to process service discovery messages and signaling.
- the need to process and respond to occasional service discovery messages may cause components in the wireless application datapath to stay in an always-on state, which can consume substantial power even though service discovery messages typically have small payloads (e.g., a few bytes).
- service discovery messages typically have small payloads (e.g., a few bytes).
- each client STA typically has no knowledge about whether or not the service(s) that other previously discovered peer STAs provide have changed unless the service discovery (and device discovery) operations are periodically repeated with each peer STA, establishing and maintaining out-of-band P2P and/or D2D connections can consume substantial time and resources, which may be especially problematic in battery-powered electronic devices.
- a low-power co-processor may be used to optimize power consumption in a wireless service platform with a main wireless application datapath, wherein certain service discovery tasks may be offloaded from the main wireless application datapath to the low-power co-processor subsystem (e.g., such that components in the main wireless application datapath can transition to and/or remain in a low-power state as much as possible).
- the service discovery tasks offloaded to the low-power co-processor subsystem may be determined according to protocol-specific service descriptions associated with one or more services to be provided and/or consumed at the wireless device.
- rules to wake the components in the main wireless application datapath may be dynamically defined and redefined or otherwise tuned to maximize the time that the components in the main wireless application datapath can spend in a low-power state and to determine conditions under which to selectively wake the components in the main wireless application datapath as needed.
- a method for optimizing power consumption in a service discovery wireless services platform may comprise establishing a peer-to-peer wireless connection at a wireless device, transitioning one or more components in a main wireless application datapath associated with the wireless device (e.g., a main application processor) to a sleep state, and offloading one or more service discovery tasks from the one or more components transitioned to the sleep state to a low-power co-processor coupled to the one or more components in the main wireless application datapath, wherein the one or more service discovery tasks offloaded to the low-power co-processor may be determined at least in part according to a service description associated with a service discovery protocol used in the peer-to-peer wireless connection.
- the method may comprise defining one or more dynamic rules to wake the one or more components in the main wireless application datapath from the sleep state based at least in part on the service description associated with the service discovery protocol used in the peer-to-peer wireless connection.
- the one or more components in the main wireless application datapath may be selectively woken from the sleep state in response to the one or more incoming data packets having criteria that trigger the one or more dynamic rules.
- an apparatus may comprise means for establishing a peer-to-peer wireless connection, means for transitioning one or more components in a main wireless application datapath to a sleep state, means for offloading one or more service discovery tasks from the one or more components transitioned to the sleep state, wherein the one or more offloaded service discovery tasks may be determined at least in part according to a service description associated with a service discovery protocol used in the peer-to-peer wireless connection, means for defining one or more dynamic rules to wake the one or more components in the main wireless application datapath from the sleep state based at least in part on the service description associated with the service discovery protocol used in the peer-to-peer wireless connection, means for receiving one or more incoming data packets over the peer-to-peer wireless connection, and means for selectively waking the one or more components in the main wireless application datapath from the sleep state in response to the one or more incoming data packets having criteria that trigger the one or more dynamic rules.
- a computer-readable storage medium may have computer-executable instructions recorded thereon, wherein executing the computer-executable instructions on one or more processors may cause the one or more processors to establish a peer-to-peer wireless connection at a wireless device, transition one or more components in a main wireless application datapath associated with the wireless device to a sleep state, offload one or more service discovery tasks from the one or more components transitioned to the sleep state to a low-power co-processor coupled to the one or more components in the main wireless application datapath, define one or more dynamic rules to wake the one or more components in the main wireless application datapath from the sleep state based at least in part on a service description associated with the service discovery protocol used in the peer-to-peer wireless connection, receive, at the low-power co-processor, one or more incoming data packets over the peer-to-peer wireless connection, and selectively wake the one or more components in the main wireless application datapath from the sleep state in response to the one or more incoming data packets having criteria
- a wireless device may comprise a main wireless application datapath that includes a host bridge, an interconnect, system memory, and a host application processor in addition to a low-power hardware processor coupled to the main wireless application datapath.
- the low-power hardware processor may comprise a local memory configured to store one or more outgoing data packets associated with one or more service discovery tasks offloaded from the main wireless application datapath and a schedule to send the one or more outgoing data packets, a programmable deep-packet inspection module configured with one or more dynamic rules to invoke processing in main wireless application datapath and to determine whether criteria associated with one or more incoming data packets received at the wireless device trigger the one or more dynamic rules, wherein the one or more dynamic rules may be based at least in part on a service description associated with a service discovery protocol.
- the low-power hardware processor may comprise a low-power host processor configured to perform the one or more offloaded service discovery tasks, to respond to the one or more incoming data packets without invoking processing in the main wireless application datapath in response to the criteria associated with the one or more incoming data packets not triggering the one or more dynamic rules, and to invoke the processing in the main wireless application datapath in response to the criteria associated with the one or more incoming data packets triggering the one or more dynamic rules.
- FIG. 1 illustrates an exemplary wireless network architecture that may support out-of-band device-to-device (D2D) communication, according to various aspects.
- D2D device-to-device
- FIG. 2 illustrates another exemplary wireless network architecture supporting out-of-band device-to-device (D2D) communication, according to various aspects.
- D2D device-to-device
- FIG. 3 illustrates an exemplary wireless environment in which two wireless devices may communicate over an out-of-band D2D connection, according to various aspects.
- FIG. 4 illustrates an exemplary wireless network architecture in which two or more peer wireless devices may communicate over an out-of-band D2D connection according to one or more service discovery protocols, according to various aspects.
- FIG. 5 illustrates an exemplary power profile at a wireless device configured to communicate over an out-of-band D2D connection, according to various aspects.
- FIG. 6 illustrates an exemplary wireless device that has a low-power co-processor disposed in a main wireless application datapath to support one or more service discovery processing tasks, according to various aspects.
- FIG. 7A and FIG. 7B illustrate exemplary device discovery and service discovery call flows between service provider and service consumer peer devices to establish an out-of-band D2D connection between the peer devices, according to various aspects.
- FIG. 8A illustrates an exemplary architecture associated with a wireless device that may operate a low-power low-bandwidth co-processor subsystem disposed in a wireless application datapath according to a look-aside mode, according to various aspects.
- FIG. 8B illustrates an exemplary architecture associated with a wireless device that may operate a low-power low-bandwidth co-processor subsystem disposed in a wireless application datapath according to a bump-in-the-wire mode, according to various aspects.
- FIG. 9 illustrates an exemplary method that a low-power low-bandwidth co-processor subsystem may perform to optimize service discovery power consumption in a wireless service platform, according to various aspects.
- FIG. 10 illustrates an exemplary method that an application processor disposed in a main wireless application datapath may perform to optimize service discovery power consumption in a wireless service platform having a low-power low-bandwidth co-processor subsystem, according to various aspects.
- a CDMA system may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), CDMA2000, etc.
- UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA.
- CDMA2000 covers IS-2000, IS-95, and IS-856 standards.
- a TDMA system may implement a radio technology such as Global System for Mobile Communications (GSM).
- GSM Global System for Mobile Communications
- An OFDMA system may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMTM, etc.
- E-UTRA Evolved UTRA
- UMB Ultra Mobile Broadband
- IEEE 802.11 Wi-Fi
- WiMAX IEEE 802.16
- Flash-OFDMTM Flash-OFDMTM
- UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS).
- 3GPP Long Term Evolution (LTE) is a release of UMTS that uses E-UTRA, which employs OFDMA on the downlink and SC-FDMA on the uplink UTRA
- E-UTRA, UMTS, LTE, and GSM are described in documents from an organization named “ 3 rd Generation Partnership Project” (3GPP).
- CDMA2000 and UMB are described in documents from an organization named “3rd Generation Partnership Project 2” (3GP
- FIG. 1 illustrates an exemplary wireless network architecture 100 that may support out-of-band device-to-device (D2D) communication, wherein the wireless network architecture 100 may comprise a Long Term Evolution (LTE) (or Evolved Packet System (EPS)) network architecture 100 .
- LTE Long Term Evolution
- EPS Evolved Packet System
- the network architecture 100 may include a first user equipment (UE 1 ) 102 , a second user equipment (UE 2 ) 104 , an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) 110 , an Evolved Packet Core (EPC) 120 , a Home Subscriber Server (HSS) 135 , and Internet Protocol (IP) Services 140 associated with an operator (e.g., a mobile network operator (MNO)).
- the EPS network architecture 100 can interconnect with other access networks and core networks (not shown), such as a UMTS access network or an IP core network. As shown, the EPS network architecture 100 provides packet-switched services; however, those skilled in the art will readily appreciate that the various concepts disclosed herein may be extended to networks that provide circuit-switched services.
- the E-UTRAN 110 may include a first evolved
- the eNBs 112 , 114 may provide user and control plane protocol terminations toward the UEs 102 , 104 and may be connected to each other via a backhaul (e.g., an X2 interface).
- the eNBs 112 , 114 may also be referred to as base stations, Node Bs, access points, base transceiver stations, radio base stations, radio transceivers, transceiver functions, a basic service set (BSS), an extended service set (ESS), or some other suitable terminology.
- BSS basic service set
- ESS extended service set
- the eNBs 112 , 114 each provide an access point to the EPC 120 for the respective UEs 102 , 104 .
- Example UEs 102 , 104 may include, without limitation, a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, a tablet, or any other similar functioning device.
- SIP session initiation protocol
- PDA personal digital assistant
- UE 1 102 and/or UE 2 104 may also be referred to as a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, etc.
- the eNBs 112 , 114 may each connect to the EPC 120 via an Si interface, wherein the EPC 120 may include a Mobility Management Entity (MME) 122 , other MMEs 124 , a Serving Gateway 126 , a Multimedia Broadcast Multicast Service (MBMS) Gateway 130 , a Broadcast Multicast Service Center (BM-SC) 132 , and a Packet Data Network (PDN) Gateway 128 .
- MME Mobility Management Entity
- MBMS Multimedia Broadcast Multicast Service
- BM-SC Broadcast Multicast Service Center
- PDN Packet Data Network
- the MME 122 is a control node that may process signaling between the UEs 102 , 104 and the EPC 120 .
- the MME 122 provides bearer and connection management, while all user IP packets are transferred through the Serving Gateway 126 , which may be connected to the PDN Gateway 128 .
- the PDN Gateway 128 may provide UE IP address allocation as well as other functions.
- the PDN Gateway 128 is connected to the Operator IP Services 140 , which may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), a PS Streaming Service (PSS), and/or other suitable services.
- the BM-SC 132 may provide functions for MBMS user service provisioning and delivery and serve as an entry point for content provider MBMS transmission. Furthermore, according to various aspects, the BM-SC 132 may authorize and initiate MBMS Bearer Services within a PLMN, schedule and deliver MBMS transmissions, and/or provide other similar functions.
- the MBMS Gateway 130 may be used to distribute MBMS traffic to one or more eNBs that belong to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service (e.g., eNBs 112 , 114 ), and may be responsible for session management (start/stop) and collecting eMBMS related charging information.
- MMSFN Multicast Broadcast Single Frequency Network
- a UE pair (e.g., UE 1 102 and UE 2 104 ) may establish an out-of-band device-to-device (D2D) connection to communicate directly without utilizing the respective eNB 1 112 and eNB 2 114 and subsequently transfer data traffic over the out-of-band D2D connection.
- D2D device-to-device
- one or more entities in the network infrastructure may coordinate the out-of-band D2D communication between the UE pair 102 , 104 , meaning that the network entities may assist in establishing the out-of-band D2D connection, control use in a D2D mode versus a legacy mode, provide security support, etc.
- the terms “out-of-band D2D connection,” “D2D mode,” and/or other variants thereof may generally refer to direct communication between two or more UEs 102 , 104 that does not pass through any base station, and the term “legacy connection,” “legacy mode,” and/or other variants thereof may generally refer to communication via the network (e.g., via the eNBs 112 , 114 ).
- the UE pair 102 , 104 may establish the out-of-band D2D connection autonomously, wherein initial discovery used to establish the out-of-band D2D connection may be based on an ability to communicate signals directly between the UEs 102 , 104 .
- the UEs 102 , 104 may connect via the network and exchange serving cell and location information to determine whether the D2D mode is possible. Once the D2D mode is in progress, the UEs 102 , 104 may monitor relative locations associated therewith. Furthermore, a group including three or more UEs may enter the D2D mode whereby some or all UE pairs in the group may maintain direct D2D communication between one another and whereby some UEs in the group may act as relays to relay D2D communication between other UEs in the group.
- one UE in the group may be designated to operate in a relay role to maintain direct D2D communication with the other UE(s) in the group and act in a relay role in order to enable the other UE(s) to communicate indirectly via D2D communication.
- the UE operating in the relay role may act to relay communications between the other UE(s) in the group.
- a group that includes several UEs employing D2D communication between one another may monitor relative locations associated therewith and assign (and/or reassign) the relay role to any UE in the group based on the current relative locations associated therewith.
- the network may assist the two or more UEs 102 , 104 to enter the D2D mode in cases where the legacy mode may be unavailable and/or impossible (e.g., if the network is congested or portions thereof have temporarily failed or do not provide continuous radio coverage to both UEs 102 , 104 ).
- the network e.g., one or more network entities
- FIG. 2 illustrates another exemplary wireless network architecture 200 supporting out-of-band D2D communication (e.g., using LTE-Direct (LTE-D), Wi-Fi Direct (WFD), or another suitable D2D radio access technology).
- the wireless network architecture 200 shown in FIG. 2 may comprise a base station 202 that may include multiple antenna groups (e.g., one antenna group may include antennas 204 and 206 , another group may comprise antennas 208 and 210 , an additional group may include antennas 212 and 214 , etc.).
- LTE-Direct LTE-D
- WFD Wi-Fi Direct
- FIG. 2 illustrates another exemplary wireless network architecture 200 supporting out-of-band D2D communication (e.g., using LTE-Direct (LTE-D), Wi-Fi Direct (WFD), or another suitable D2D radio access technology).
- the wireless network architecture 200 shown in FIG. 2 may comprise a base station 202 that may include multiple antenna groups (e.g., one antenna group may include antennas 204 and 206
- the base station 202 may additionally include a transmitter chain and a receiver chain (not shown), which may each in turn comprise a various components associated with signal transmission and reception (e.g., processors, modulators, multiplexers, demodulators, demultiplexers, antennas, and so forth), as will be apparent to those skilled in the art. Additionally, the base station 202 may be a home base station, a femto base station, a wireless local area network (WLAN) access point, and/or the like.
- WLAN wireless local area network
- the base station 202 may communicate with one or more devices, such as device 216 .
- the base station 202 may communicate with substantially any number of devices similar to the device 216 .
- the device 216 is in communication with the base station 202 via antennas 204 and 206 , where antennas 204 and 206 may generally transmit information to the device 216 over a forward link 218 and receive information from the device 216 over a reverse link 220 .
- the forward link 218 may utilize a different frequency band than that the reverse link 220 , for example.
- TDD time division duplex
- the forward link 218 and the reverse link 220 may utilize a common frequency band.
- FIG. 2 illustrates a first peer device 222 and a second peer device 224 that are in direct communication with one another, such as in a D2D (or peer-to-peer (P2P)) configuration using LTE-Direct, Wi-Fi Direct, etc.
- the first peer device 222 is in communication with the second peer device 224 using links 226 and 228 .
- devices within range of each other such as devices 222 and 224 , may communicate with each other directly without any intermediate base station 202 and/or a wired infrastructure to relay communication therebetween.
- the peer devices (or nodes) 222 , 224 may relay traffic, whereby the peer devices 222 , 224 within the wireless network architecture 200 that communicate over an out-of-band D2D connection may provide functionality otherwise similar to the base station 202 and relay traffic or communications to other devices, until the traffic reaches the ultimate destination associated therewith.
- the peer devices 222 , 224 may also transmit control channels, which may carry information that can be utilized to manage the data transmission between the peer nodes.
- the wireless network architecture 200 may include various devices (or nodes) that are in wireless (or wired) communication, wherein each node may be within sufficient range to one or more other nodes to communicate with the other nodes or utilize the other nodes, such as in a multi-hop topology (e.g., communications may hop from node to node until reaching a final destination).
- the second peer device 224 may comprise a sender node that wishes to communicate with device 216 as a receiver node.
- one or more intermediate nodes may be utilized (e.g., the first peer device 222 may act as an intermediate node to relay communications from the sender node 224 to the base station 202 , which may also act as an intermediate node to relay the communications to the receiver node 216 ).
- the first peer device 222 may act as an intermediate node to relay communications from the sender node 224 to the base station 202 , which may also act as an intermediate node to relay the communications to the receiver node 216 ).
- any node may be a sender node and/or a receiver node and may perform functions to either send and/or receive information at substantially the same time (e.g., a particular node may broadcast or communicate information at about the same time as receiving information, at different times, etc.).
- the wireless network architecture 200 may be configured to allow nodes that have initiated a communication session over a network (e.g., via the base station 202 ) to move the session to a direct D2D connection in which directly connected nodes may exchange packets natively without any encapsulation.
- a “homeless” node may switch to a wireless network without losing an ongoing session, wherein a “homeless” may refer to a node that does not have any home agent entity to assist with keeping ongoing sessions alive while switching to foreign networks and/or to forward any new incoming request(s) to establish new sessions to the node's current location.
- nodes may be mobile (e.g., wireless), static (e.g., wired), or any suitable combination thereof
- FIG. 3 illustrates an exemplary wireless environment 300 in which two wireless devices 310 , 320 may establish and communicate over an out-of-band D2D connection 350 in the event that the two wireless devices 310 , 320 are located in sufficient proximity to establish the out-of-band D2D connection 350 .
- the wireless device 310 may have a near-field communication (NFC) radio 311 , a wireless wide area network (WWAN) radio 313 , a wireless local area network (WLAN) radio 315 , and a Bluetooth radio 317 that the wireless device 310 can use to communicate within the wireless environment 300 .
- NFC near-field communication
- WWAN wireless wide area network
- WLAN wireless local area network
- Bluetooth radio 317 that the wireless device 310 can use to communicate within the wireless environment 300 .
- the wireless device 310 can wirelessly communicate with a cellular base station 340 over a WWAN link 341 using the WWAN radio 313 .
- the wireless device 310 can also wirelessly communicate with a Wi-Fi access point 360 over a WLAN link 361 using the WLAN radio 315 .
- the wireless device 310 can wirelessly communicate with a Bluetooth headset 380 and Bluetooth-enabled wearable device 382 over Bluetooth links 381 , 383 using the Bluetooth radio 317 , wherein the Bluetooth headset 380 and the Bluetooth-enabled wearable device 382 may be in further wireless communication with each other over a Bluetooth link 384 .
- the wireless device 310 can wirelessly communicate with one or more NFC devices within the “near field” of the wireless device 310 using the NFC radio 311 via magnetic field induction.
- the second wireless device 320 may likewise have multiple radios that each operate in accordance with a different radio access technology.
- the second wireless device 320 may also have an NFC radio 321 , a WWAN radio 323 , a WLAN radio 325 , and a Bluetooth radio 327 , wherein the wireless device 320 can use the radios 321 , 323 , 325 , 327 to communicate within the wireless environment 300 .
- the wireless device 320 can use the radios 321 , 323 , 325 , 327 to communicate within the wireless environment 300 .
- the wireless device 320 can wirelessly communicate with a cellular base station 340 over a WWAN link 345 using the WWAN radio 323 , with a Wi-Fi access point 360 over a WLAN link 365 using the WLAN radio 325 , with a Bluetooth headset 385 and a Bluetooth-enabled wearable device 387 over Bluetooth links 386 , 388 using the Bluetooth radio 327 , wherein the Bluetooth headset 385 and the Bluetooth-enabled wearable device 387 may be in further wireless communication with each other over a Bluetooth link 389 . Further still, the wireless device 320 can wirelessly communicate with one or more NFC devices within the “near field” of the wireless device 320 using the NFC radio 321 via magnetic field induction.
- wireless devices 310 , 320 are depicted in FIG. 3 as communicating with the same cellular base station 340 , in which case the WWAN links 341 , 345 may have a common endpoint, the wireless devices 310 , 320 may in fact be in communication with different cellular base stations via respective WWAN links 341 , 345 .
- the wireless devices 310 , 320 are depicted in FIG. 3 as communicating with the same Wi-Fi access point 360 , those skilled in the art will appreciate that the wireless devices 310 , 320 may in fact be in communication with different Wi-Fi access points via respective WLAN links 361 , 365 .
- the wireless devices 310 , 320 may communicate with one another directly over an out-of-band D2D connection 350 in the event that the wireless devices 310 , 320 are located in sufficient proximity to one another. For example, when the wireless devices 310 , 320 are within a range up to approximately 500 meters, the wireless devices 310 , 320 may use the WWAN radios 313 , 323 to form a D2D link over LTE-Direct.
- the wireless devices 310 , 320 may form a D2D link over Wi-Fi Direct.
- the wireless devices 310 , 320 may form a D2D link using the Bluetooth radios 317 , 327 if the wireless devices 310 , 320 are within an operating range ranging from a few meters to a few tens of meters or using the NFC radios 311 , 321 if the wireless devices 310 , 320 are within each other's near field (e.g., about ten centimeters or less).
- wireless devices 310 , 320 are both associated with the same user and run respective applications 318 , 328 (e.g., an email application) that are associated with the same user name and credentials
- existing synchronization algorithms and implementations typically involve each wireless device 310 , 320 individually performing a synchronization procedure with a corresponding application server 390 without utilizing or considering the fact that the latest account data 319 , 329 associated with the application 318 , 328 may be available on the other device in proximity, which tends to be an inefficient approach for several reasons.
- the wireless devices 310 , 320 may execute one or more service discovery protocols to discover one another and communicate directly over the out-of-band D2D connection 350 based on appropriate service data 319 , 329 that may be stored at each respective wireless device 310 , 320 .
- LTE-Direct LTE-D, sometimes referred to as “LTE-Advanced”
- LTE-Advanced 3 GPP (Release 12 ) D2D solution for proximate discovery, wherein LTE-D dispenses with location tracking and network calls by directly monitoring for services on other LTE-D devices within a large range ( ⁇ 500 m, line of sight) to concurrently detect services in proximity.
- LTE-D is a D2D solution that enables service layer discovery and D2D communication, wherein applications 318 , 328 on LTE-D wireless devices (e.g., wireless devices 310 , 320 ) can instruct LTE-D to monitor for application services on other devices and announce locally available services (for detection by services on other LTE-D devices) at the physical layer.
- the client application(s) 318 , 328 may be notified when a match to an establish “monitor” is detected.
- the application(s) 318 , 328 can establish a monitor for “synchronization events” and the LTE-D discovery layer can wake-up the application(s) 318 , 328 when a synchronization-related LTE-D expression is detected.
- LTE-D is thus a distributed discovery solution that may not require a centralized database to identify relevant matches, which are instead autonomously determined at the device level by transmitting and monitoring for relevant attributes.
- Wi-Fi Direct is a device-to-device (D2D) specification developed under the Wi-Fi Alliance (WFA), which provides a means that IEEE 802.11 devices can use to discover and communicate directly with each other without using a central node, such as an access point (AP) or a base station (BS).
- WFD may allow Wi-Fi devices, or peer wireless devices, to address usage models that are traditionally covered under Bluetooth and ad hoc networks, such as an independent basic service set (IBSS).
- IBSS independent basic service set
- WFD addresses device discovery, service discovery, security, user set-up, and cross-connection to the infrastructure network.
- WFD generally has a range substantially equivalent to standard Wi-Fi, security using WPA2 (e.g., Advanced Encryption Standard (AES) encryption), three 20 MHz channels in the 2.4 GHz band and twenty-five 20 MHz channels in the 5 GHz band, device authentication and enrollment with Wi-Fi Protected Setup (WPS) (or Wi-Fi Simple Configuration (WSC)), an IP-address-based protocol, service advertisement, power management allowing both devices to sleep, one-time or persistent connections, and concurrency with infrastructure networks (i.e., networks using a central node).
- WPS Wi-Fi Protected Setup
- WSC Wi-Fi Simple Configuration
- IP-address-based protocol IP-address-based protocol
- service advertisement i.e., service advertisement
- power management allowing both devices to sleep, one-time or persistent connections, and concurrency with infrastructure networks (i.e., networks using a central node).
- a group owner may act as a master peer device and may support connections
- the GO has functionality similar to an access point in a traditional system, except that the GO can enter a power saving state.
- a WFD peer group typically has a single basic service set identifier (BSSID), a single GO, one or more client peer devices, and a single group identifier, which may be a one-time group or a persistent group identifier.
- BSSID basic service set identifier
- FIG. 4 illustrates an exemplary wireless network architecture 400 in which two or more peer wireless devices may communicate over an out-of-band D2D connection according to one or more service discovery protocols.
- the wireless network architecture 400 shown in FIG. 4 will be described herein in relation to service discovery procedures used in Wi-Fi Direct (WFD).
- WFD Wi-Fi Direct
- those skilled in the art will appreciate that such description is for illustration purposes only and that the issues involved in the service discovery framework shown in FIG. 4 may likewise apply to service discovery procedures used in other D2D technologies.
- the wireless network architecture 400 shown in FIG. 4 may support service discovery protocols used in various application service platforms, where an application service platform (ASP) may generally refer to a software service or library that implements the functions that applications and services need to establish and communicate over a session between a service provider device 410 and a service consumer device 420 .
- ASP application service platform
- applications and/or use cases built on the one or more service discovery protocols may include mirroring (or screen sharing), streaming video, streaming audio, remote video and/or graphics rendition, remote audio and/or audio rendition, remote sensing, remote control, file transfer, and so on.
- the service provider device 410 may exchange various service discovery messages and other signaling messages to support announcements and inquiries, composition and mediation, control, presentation, group management, addressing control, quality of service (QoS) and/or quality of experience (QoE) with respect to various applications/use cases.
- QoS quality of service
- QoE quality of experience
- a service discovery broker 412 associated with the service provider device 410 may publish one or more service advertisements to provide information about the one or more P2P services such that a service seeker on another device (e.g., the service consumer device 420 ) can search for, find, and initiate an ASP session with the ASP on the service provider device 410 .
- the service advertisements may include a service name, an identifier associated with the service provider device 410 , and one or more pointers to more detailed information about the one or more services (e.g., a protocol-specific service description).
- the control point 430 may then discover and review the one or more service advertisements to learn about the service provider device 410 and the capabilities associated therewith, retrieve the appropriate device and service descriptions, send actions to the service discovery broker 412 , poll the service discovery broker 412 for service state variables, and receive events from the service discovery broker 412 .
- the control point 430 may be configured to provide a registry that maintains service descriptions, device information, and/or other suitable information to facilitate service-specific P2P sessions in the wireless network architecture 400 .
- a service discovery and registration agent 422 may periodically solicit information from the control point 430 to learn services that are available in the wireless network architecture 400 , while the service discovery broker 412 may expose controls and status associated with the available services.
- control point 430 may use one or more service descriptions to send control messages (or actions) to the service discovery broker 412 on the service provider device 410 and/or the service discovery and registration agent 422 on the service consumer device 420 , which may then return one or more action-specific corresponding values.
- control point 420 may subscribe to receive service descriptions or actions to change service variables that model service states, whereby the service provider device 410 and/or the service consumer device 420 may send event messages to update one or more state variables and current values associated with the state variables.
- management data and service data may be exchanged between a service distribution module 414 on the service provider device 410 and a service execution module 424 on the service consumer device 420 .
- the management data exchanged between the service distribution module 414 and the service execution module 424 may define the service invocation methods, input resolutions, and/or any additional dependencies needed to perform actual service work and return data.
- service discovery may generally refer to the system architecture, methods, algorithms, and protocols that enable the service consumer device 420 to discover one or more services that match one or more required conditions associated with a service to be consumed in the appropriate system architecture without prior configuration.
- service discovery architecture is Zero-configuration networking (Zeroconf), which resolves addressing, naming, service discovery, and automatic device and service configuration across heterogeneous networks without needing any centralized entity as in the Domain Name Service (DNS) and Dynamic Host Configuration Protocol (DHCP).
- DNS Domain Name Service
- DHCP Dynamic Host Configuration Protocol
- Zeroconf uses Multicast DNS (mDNS) to store service information in DNS resource records
- DSN-SD DNS Service Discovery
- DSN-SD DNS Service Discovery
- Zeroconf requires devices to support publication to expose a service, discovery to enable browsing for available services, and resolution to translate service name nomenclatures to actual logical addresses and port numbers.
- considerations applicable to any service discovery architecture may include the relevant service discovery objectives (e.g., providing a common description language, service information storage, and mechanisms to enable searching for services).
- the considerations may relate to how services are administered (e.g., updating service directories due to changes to service descriptions, network topologies, etc.), service information storage classification (e.g., centralized, unstructured distributed, structured distributed, flat, hierarchical, hybrid, etc.), as well as service description access and service discovery methods.
- service description access may be controlled through a directory node that may be identified and required to publish advertisements and requests, whereas structured distributed storage systems may have directory nodes relay service discovery messages to other directory nodes according to the applicable overlay structure.
- direct service access may be addressed to the directory nodes or disseminated in the network.
- passive (or push) models may allow agents and brokers to passively receive announcements about devices and available services, whereas agents and brokers may actively interrogate or inquire about devices and available services in architectures that employ active (or pull) models.
- functional issues may include, without limitation, service selection, usage and QoS/QoE, security/privacy (e.g., authentication, authorization, trust, confidentiality, integrity, non-repudiation, etc.), network type (e.g., wired, wireless, client density, size, bandwidth, etc.), and device capabilities.
- security/privacy e.g., authentication, authorization, trust, confidentiality, integrity, non-repudiation, etc.
- network type e.g., wired, wireless, client density, size, bandwidth, etc.
- device capabilities e.g., without limitation, service selection, usage and QoS/QoE, security/privacy (e.g., authentication, authorization, trust, confidentiality, integrity, non-repudiation, etc.), network type (e.g., wired, wireless, client density, size, bandwidth, etc.), and device capabilities.
- specific performance issues may include network scalability, group communication, load balancing and query efficiency (e.g., more directory nodes and service groupings, caching to minimize overloading nodes, load balancing and load distribution to new devices, hierarchical structures, distributed hash indexing, overlay structure optimization, and service description aggregation) as well as fault tolerance, timing and synchronization, mobility support, and resource-aware optimization (e.g., power and battery optimizations, network bandwidth optimizations, etc.).
- load balancing and query efficiency e.g., more directory nodes and service groupings, caching to minimize overloading nodes, load balancing and load distribution to new devices, hierarchical structures, distributed hash indexing, overlay structure optimization, and service description aggregation
- fault tolerance timing and synchronization
- mobility support e.g., mobility support, and resource-aware optimization (e.g., power and battery optimizations, network bandwidth optimizations, etc.).
- a wireless application datapath associated with a particular service can comprise many ad-hoc devices that can be expected to have unequal capabilities, processing densities, storage capacities, connection and power performance profiles, etc.
- any device can operate autonomously and without awareness of other devices, operational dependencies and required collaboration among different devices will typically be validated and resolved per-application and/or use case such that a collaborative and distributed (unstructured) service discovery framework may best enable all essential features.
- FIG. 5 illustrates an exemplary power profile at a wireless device that communicates over an out-of-band D2D connection to provide and/or consume one or more P2P services.
- the example power profile shown in FIG. 5 may apply to a wireless device that communicates using an 802.11ac Wi-Fi transceiver, where the vertical axis shows milliamps (mA) consumed at 4.0 volts DC as a function of time as shown on the horizontal axis.
- mA milliamps
- power consumed while the wireless device is on a home screen (and prior to establishing a wireless session) is approximately 800 milliamps (mA), wherein the home screen power consumption jumps to around 1000 mA after session establishment and power consumption stays at or above that level even during standby/idle periods when no wireless traffic exists, which amounts to ⁇ 1 W in static power consumption.
- mA milliamps
- service discovery messages may have relatively small payloads (e.g., only a few bytes), which may not require the substantial processing resources provided in the main wireless application datapath.
- the various aspects and embodiments described herein introduce a smart co-processor or other processing component(s) having a low-power profile into the main wireless application datapath such that the low-power co-processor can assume certain processing functions that the components in the wireless application datapath would typically perform and thereby reduce the overall power consumption associated with service discovery messaging.
- the low-power co-processor may be configured to selectively engage the components in the wireless application datapath when needed such that the components that consume more power are only utilized to perform more intensive processing tasks or when otherwise required.
- FIG. 6 illustrates an exemplary wireless device 600 that may have a low-power co-processor subsystem 660 disposed in a main wireless application datapath to assist with one or more service discovery processing tasks and thereby optimize service discovery power consumption and/or other service discovery processing tasks associated with a wireless service platform.
- the wireless device 600 shown in FIG. 6 may correspond to a service provider device, a service consumer device, or any other suitable device in a wireless application datapath associated with one or more services that are provided between peer devices.
- the wireless device 600 may include a display processor 670 that can encode or otherwise process video data to present on a local display 672 and/or an external display 674 on an external device.
- the display processor 670 may process the same video data to display on both the local display 672 and the external display 674 , or the display processor 670 may alternatively only process video data to display on the local display 672 or the external display 674 .
- the wireless device 600 may include a local audio subsystem 680 that can process audio data to present through local audio output mechanisms (e.g., internal speakers, a headphone interface, etc.) and/or an external audio subsystem 684 , wherein the local audio subsystem 680 may process the same audio data to present locally and through the external audio subsystem 684 or alternatively only process audio data to present locally or through the external audio subsystem 684 .
- the wireless device 600 may include a service discovery subsystem 650 configured to manage various aspects associated with providing and/or consuming services associated with one or more peer devices, which may involve coordination with the display processor 670 and associated components to support services that relate to mirroring, screen sharing, streaming video, remote video/graphics rendition, etc., coordination with the local audio subsystem 680 and associated components to support services that relate to streaming audio, remote audio rendition, coordination with a sensor platform 626 to support services that relate to remote sensing, and so on.
- a service discovery subsystem 650 configured to manage various aspects associated with providing and/or consuming services associated with one or more peer devices, which may involve coordination with the display processor 670 and associated components to support services that relate to mirroring, screen sharing, streaming video, remote video/graphics rendition, etc., coordination with the local audio subsystem 680 and associated components to support services that relate to streaming audio, remote audio rendition, coordination with a sensor platform 626 to support services that relate to remote sensing, and so on.
- the service discovery subsystem 650 may be configured to coordinate various tasks that relate to device discovery, which may include discovering or otherwise determining Media Access Control (MAC) addresses or other suitable identifying information associated with one or more discovered peer devices, location coordinates associated with such peer devices, P2P services available on the discovered peer devices, and/or other suitable configuration information pertaining to any discovered peer devices.
- the service discovery subsystem 650 may be configured to store the information pertaining to the discovered peer devices in local storage, a cache 622 , a memory associated with the low-power co-processor subsystem 660 , and/or any suitable combination thereof.
- the information pertaining to each discovered peer device may be stored in a table, which may include a peer device field to store a name associated with each discovered peer device, an address field to store the MAC address associated with each discovered peer device, a coordinate field to store the location coordinates associated with each discovered peer device, a service field to store information about the P2P services (if any) that are available on the discovered peer device, and one or more hash values that correspond to service query strings that identify the services available at each peer device.
- a table may include a peer device field to store a name associated with each discovered peer device, an address field to store the MAC address associated with each discovered peer device, a coordinate field to store the location coordinates associated with each discovered peer device, a service field to store information about the P2P services (if any) that are available on the discovered peer device, and one or more hash values that correspond to service query strings that identify the services available at each peer device.
- the service discovery subsystem 650 may further coordinate various tasks that relate to service discovery, which may include discovering or otherwise determining one or more service descriptions that are associated with services available on the wireless device 600 and/or the available services on any discovered peer devices.
- service discovery protocols generally rely on protocol-specific service descriptions (or specifications) that are passed between peer endpoints (e.g., according to a service_information parameter that provides detailed information about a specific individual service).
- a peer device may discover other peer devices via a Scan phase in which a scanning peer device seeks to discover existing P2P networks, which may have a group owner (GO) send out beacons that may be heard at a peer device listening to all available channels.
- GO group owner
- the Scan phase may include an Active Scan or a Passive Scan, wherein an Active Scan may involve the peer device sending probe requests on all available channels and soliciting probe responses from an access point or a GO, while a peer device conducting a Passive Scan may dwell on all channels and listen for beacons.
- a peer device may discover other peer devices via a Find phase in which the scanning peer device seeks to discover other peer devices that have not already formed a P2P group.
- the Find phase may include a Search state and a Listen state, wherein the Search state may comprise a peer device transmitting one or more probe request frames on each social channel (e.g., channel 1 , 6 , and 11 in the 2.4 GHz band).
- the peer device may wait on a specific social channel (e.g., the Listen channel) and listen for probe requests having a certain type (e.g., a specific requested service). The peer device may then filter the requests based on the desired device and/or service type to identify one or more matching probe responses that may be sent with the appropriate service description in addition to any other information suitable to consume the service.
- a specific social channel e.g., the Listen channel
- the peer device may then filter the requests based on the desired device and/or service type to identify one or more matching probe responses that may be sent with the appropriate service description in addition to any other information suitable to consume the service.
- SDP Bluetooth Service Description Protocol
- the service discovery subsystem 650 may be configured to store the service description(s) pertaining to any discovered services available on the wireless device 600 and/or one or more peer devices in local storage, the cache 622 , the memory associated with the low-power co-processor subsystem 660 , and/or any suitable combination thereof. As such, in various embodiments, the service discovery subsystem 650 may be configured to appropriately distribute the service description(s) among interested components on the wireless device 600 such that service-specific rules to define the processing tasks to be carried out on the low-power co-processor subsystem 660 and/or the application processor 620 in the main wireless application datapath can be determined, applied, and dynamically tuned to optimize performance associated with the wireless device 600 .
- the wireless device may include a host bridge 640 , which may be dedicated to communication purposes, included in a general-purpose processor associated with the wireless device 600 , or any suitable combination thereof.
- the host bridge 640 may be configured to manage a 3G/4G cellular modem 642 , a Bluetooth (BT) radio 644 , a global positioning system (GPS) 646 receiver, and a Wi-Fi radio 648 in addition to any other modules and/or units that the wireless device 600 may use to communicate over wired and/or wireless interfaces.
- BT Bluetooth
- GPS global positioning system
- the Wi-Fi radio 648 may include a Wi-Fi transceiver that operates according to conventional Wi-Fi protocols (e.g., an 802.11n/802.11ac transceiver) and/or an independent high performance Wi-Fi transceiver (e.g., an 802.11ad transceiver).
- the host bridge 640 may be configured to establish a session with one or more peer devices using one or more components in a main wireless application datapath, which may further include an interconnect and system memory 610 and an application processor 620 .
- the low-power co-processor subsystem 660 may be disposed in the wireless application datapath to detect service discovery messages, events, and signals in incoming packets, wherein the low-power co-processor subsystem 660 may have sufficient memory to store outgoing messages and related schedules to transmit the outgoing messages via the Wi-Fi radio 648 , the BT radio 644 , the 3G/4G cellular modem 642 , etc. As such, the low-power co-processor 660 may be used to offload various service discovery tasks from the high-power and high-bandwidth components in the wireless application datapath, which can therefore enter a low-power state until needed to carry out more intensive processing tasks.
- the wireless device 600 may further include a storage device 654 coupled to the interconnect and system memory 610 through a peripheral interface 652 .
- storage device 654 may comprise a flash drive, a Universal Serial Bus (USB) drive, an SD card, or any other suitable external storage device.
- data stored in the storage device 654 may be received from storage or in real-time from a private network or a public network (e.g., the Internet) via the host bridge 640 .
- the wireless device 600 may further include an application data mover 664 that may move data from the storage device 654 to local memory 614 such that the application processor 620 and/or the low-power co-processor subsystem 660 can access the data more easily when executing one or more appropriate applications.
- the application processor 620 may be coupled to the cache 622 , which may store frequently accessed data.
- the wireless device 600 may include a graphics processing unit 662 that can perform any suitable graphics processing that applications running on the application processor 620 may require.
- the wireless device 600 may include one or more multimedia processors 628 that can provide encoding, decoding, acceleration, and/or other multimedia processing on multimedia content obtained from network sources (e.g., the Internet), from sensors in the wireless device 600 (e.g., a built-in camera) and/or a sensor platform 626 , and/or any other suitable multimedia source.
- the wireless communication device 600 may include a security module 690 that may determine and apply any security information necessary to ensure that media data packets are securely transmitted to the external sink device.
- the wireless device 600 may include a battery subsystem 630 , which may be configured to monitor the status associated with a battery in the wireless device 600 .
- the battery subsystem 630 may store status information that reflects whether the wireless device 600 has a wall-plugged power source or is using an internal battery as well as the remaining power available on the internal battery (if in use).
- the status information relating to the battery may be presented on the local display 680 (e.g., using a small battery icon, lights or sounds to indicate different battery conditions, etc.) and used to configure the functions that are permitted on the wireless device 600 and/or the functions to be offloaded to the low-power co-processor system 660 .
- the service-specific rules mentioned above can be dynamically defined and/or subsequently redefined or otherwise tuned based on platform and application-specific use-case contexts to maximize battery life.
- the battery subsystem 630 may can negotiate and control the services that are to be supported on the wireless device 600 , the functions that are permitted on the wireless device 600 , etc. according to battery health, a battery charge state, and/or other suitable battery-related parameters (e.g., only tell time, show messages, provide speaker functions, etc. when battery health and/or available power is less than a threshold value, disable flash photography when battery health and/or available power is critically low such that a camera cannot be launched, etc.).
- suitable battery-related parameters e.g., only tell time, show messages, provide speaker functions, etc. when battery health and/or available power is less than a threshold value, disable flash photography when battery health and/or available power is critically low such that a camera cannot be launched, etc.
- the battery subsystem 630 may update the status information associated with the battery almost continuously to reflect an accurate battery status.
- the battery subsystem 630 may control a clock module that includes various clocks and/or other suitable circuitry used to control functions performed in the wireless device 600 .
- the Wi-Fi radio 648 may include multiple independent Wi-Fi transceivers that can offer different performance levels.
- the wireless device 600 may implement a demand-based Wi-Fi network control framework to ensure that the high-performance Wi-Fi transceiver will not be used while the low-power co-processor subsystem 660 is active in order to preserve the power optimizations provided therewith, as described in further detail herein.
- the low-power co-processor subsystem 660 may have capabilities to detect one or more service discovery events and signals (e.g., rules and alarms) in incoming packets and sufficient memory to store outgoing messages and related schedules such that the low-power co-processor subsystem 660 can assume functions typically performed with components that consume substantially more power (e.g., the host bridge 640 , the interconnect and system memory 610 , the main application processor 620 configured to execute a high-level operating system, etc.).
- the low-power co-processor subsystem 660 may independently inspect incoming packets that are received via the Wi-Fi radio 648 , the BT radio 64 , the 3G/4G modem 642 , etc.
- the low-power co-processor subsystem 660 may handle certain processing tasks that would otherwise be performed using the components in the main wireless application datapath. Furthermore, the low-power co-processor subsystem 660 may selectively engage the components in the main wireless application datapath as needed depending on whether the wake-up rules are triggered (e.g., where the inspected packets have a payload above a threshold level, an external message to wake-up the components in the main wireless application datapath is received, one or more packets include a binary string that matches one or more wake-up rules, etc.).
- the wireless device 600 may be expected to respond to service discovery inquiries and exchange ping and/or keep-alive messages with other peer devices in order to preserve connections/associations therewith and thereby maintain constant/stateful operations during standby/idle states
- the low-power co-processor subsystem 660 may terminate the sockets for such messaging. Accordingly, offloading various service discovery tasks to the low-power co-processor subsystem 660 may allow the more power-hungry components in the main wireless application datapath to remain in a low-power state (e.g., sleep mode) as much as possible.
- a low-power state e.g., sleep mode
- the low-power co-processor subsystem 660 may act as a proxy for the components in the main wireless application datapath to optimize processing efficiency (e.g., power consumption). Moreover, the low-power co-processor subsystem 660 may be configured to pre-process and/or trap certain commands and timing-critical messages (e.g., synchronization and interrupt look-ups) to expedite or otherwise optimize processing that may eventually be finished at the main application processor (once woken from the low-power state).
- processing efficiency e.g., power consumption
- the low-power co-processor subsystem 660 may be configured to pre-process and/or trap certain commands and timing-critical messages (e.g., synchronization and interrupt look-ups) to expedite or otherwise optimize processing that may eventually be finished at the main application processor (once woken from the low-power state).
- FIG. 7A and FIG. 7B illustrate exemplary device discovery and service discovery call flows in which a service provider device 710 and a service consumer device 720 may exchange various messages to establish an out-of-band D2D connection used to provide an available service 714 on the service provider device 710 to the service consumer device 720 .
- P2P Peer-to-Peer
- the service provider device 710 may execute an application 712 to make the service 714 on the service provider device 710 available to one or more peer devices, such as service consumer device 720 .
- the service consumer device 720 may execute an application 722 that may request a service 724 , which may correspond to the available service 714 on the service provider device 710 .
- the service provider device 710 and the service consumer device 720 may each have a local application service platform (ASP) 716 , 726 , which may refer to a software service or library that implements various functions needed to establish a session in which the service consumer device 720 utilizes the available service 714 on the service provider device 710 .
- ASP application service platform
- the functions implemented via the local ASPs 716 , 726 on the service provider device 710 and the service consumer device 720 may include device discovery, service discovery, session management, connection topology management, and security, among others.
- the call flow shown in FIG. 7A may generally be performed during a pre-association state where no device discovery and/or service discovery procedures have already been carried out between the service provider device 710 and the service consumer device 720 .
- the call flow shown in FIG. 7A may be used to make the service 714 provided on the service provider device 710 available to the service consumer device 720 and establish a direct wireless connection between the service provider device 710 and the service consumer device 720 such that the service consumer device 720 may utilize the service 714 available on the service provider device 710 .
- the ASP 716 on the service provider device 710 may receive an AdvertiseService( ) message from the available service 714 , wherein the AdvertiseService( ) message may provide information about the service 714 such that a service seeker on another device (e.g., service consumer device 720 ) may discover and initiate a session with the ASP 716 on the service provider device 710 .
- the AdvertiseService( ) message may provide information about the service 714 such that a service seeker on another device (e.g., service consumer device 720 ) may discover and initiate a session with the ASP 716 on the service provider device 710 .
- the AdvertiseService( ) message may include parameters to specify a name associated with the service 714 , detailed information about the specific service 714 that can be used during service discovery (e.g., a service description or service_information parameter), a status parameter to specify whether or not the service 714 is available for use at the time that the ASP 716 calls the AdvertiseService( ) method, any network configuration parameters associated with the service 714 , etc.
- the service 724 may send a SeekService( ) message to the ASP 726 , wherein the SeekService( ) message may provide information that the ASP 726 can use to search for services on peer devices (e.g., the service provider device 710 ).
- peer devices e.g., the service provider device 710
- the SeekService( ) message may include parameters to specify a service name to be searched (e.g., a full service name, a service name prefix, etc.), whether to conduct an exact search in which case the ASP 726 may send a hash value corresponding to the service name in a subsequent Probe Request frame (otherwise the ASP 726 may send a hash value corresponding to a service domain to search for all peer devices that support any services in the service domain), a network address parameter to indicate whether to limit the search to a device with a specific MAC address or search all peer devices in proximity, and/or an optional service information request parameter to request additional information typically used in a service discovery request/response exchange.
- a service name to be searched e.g., a full service name, a service name prefix, etc.
- the ASP 726 may send a hash value corresponding to the service name in a subsequent Probe Request frame (otherwise the ASP 726 may send a hash value corresponding to a service domain to search
- the ASP 726 on the service consumer device 720 may then transmit a P2P Probe Request frame, which may include one or more service hash(es) to indicate the desired service.
- the ASP 716 may determine whether the service hash(es) included therein match a hash associated with the service 714 (or any other services available on the service provider device 710 ).
- the ASP 716 may then transmit a P2P Probe Response with the name associated with the service 714 in addition to an advertisement ID that the ASP 716 assigns to uniquely identify the advertisement(s) on the service provider device 710 for manipulation by the service 724 that requested the advertisement, wherein the advertisement ID may also be used in subsequent messaging to indicate status changes associated with the service 714 , manage connections associated with the service 714 , and/or other events and controls associated with the service 714 .
- the ASPs 716 , 726 may then exchange P2P Service Discovery Request and P2P Service Discovery Response Frames to exchange the service name(s) and detailed service-specific information, at which time the ASP 726 may indicate the search result to the service 724 .
- the service 724 may then return a device list to the application 722 and a user input may select the service provider device 710 from the device list.
- the service 724 may then send a ConnectSessions( ) message to the ASP 726 , which may result in a P2P Provision Discovery Request and P2P Provision Discovery Response exchange between the ASPs 716 , 726 .
- the ASP 716 may return a success message along with session information to the ASP 726 at the service consumer device 720 , which may exchange connection capabilities with the service provider device 710 .
- the service consumer device 720 and the service provider device 710 may form a P2P group, or the service consumer device 720 may alternatively join an existing P2P group that the service provider device 710 previously formed.
- the call flow shown therein may generally be performed during a post-association state where the service provider device 710 and the service consumer device 720 have already formed an existing P2P connection and/or device and service discovery between the service provider device 710 and the service consumer device 720 has already been performed.
- the ASP 726 at the service consumer device 720 may send a Request_Session message to the ASP 716 at the service provider device 710 , wherein the Request_Session message may include a session-specific MAC address, a session ID, an advertisement ID, and session information.
- the ASP 716 may then send a SessionRequest to the local service 714 , which may present the session information to the application 712 .
- the service may confirm the session with the ASP 716 and indicate a session ready status to the ASP 716 .
- the ASP 716 may then respond to the ASP 726 at the service consumer device 720 to indicate the session-specific MAC address and the session ID, which the ASP 726 at the service consumer device 720 may acknowledge.
- the service 714 may then request a port from the ASP 716 and indicate the session MAC address, the session ID, an IP address, TCP/IP port number, and service-specific protocol to bind to the port.
- the ASP 716 may indicate the port status to the local service 714 and indicate the allowed port information to the ASP 726 at the service consumer device 720 .
- the service consumer device 720 may perform a similar procedure to bind a port to the service-specific session and indicate the same to the ASP 716 at the service provider device.
- the respective services 714 , 724 at the service provider device 710 and the service consumer device 720 may then connect an application socket such that service-specific application data can be exchanged between the respective applications 712 , 722 .
- the service provider device 710 and/or the service consumer device 720 may have a hardware architecture that includes a low-power low-bandwidth co-processor subsystem in addition to a high-power high-bandwidth main processing system, in which case various functions performed using the local ASP 716 , 726 may be offloaded to the low-power low-bandwidth co-processor subsystem such that the high-power high-bandwidth main processing system can be placed in a low-power state to optimize power consumption and performance on the service provider device 710 and/or the service consumer device 720 .
- the low-power low-bandwidth co-processor subsystem may have capabilities to detect one or more service discovery events and signals (e.g., rules and alarms) in incoming packets and sufficient memory to store outgoing messages and related schedules such that the low-power low-bandwidth co-processor subsystem can assume functions typically performed with the high-power high-bandwidth main processing system.
- service discovery events and signals e.g., rules and alarms
- the low-power low-bandwidth co-processor subsystem may inspect incoming packets received from the service consumer device 720 (and/or any other peer devices) according to various dynamically configurable “wake-up” rules such that the low-power low-bandwidth co-processor subsystem may independently respond to certain incoming messages and selectively engage the high-power high-bandwidth components in the main processing system as needed depending on whether the wake-up rules are triggered (e.g., where the incoming packets have a sufficiently large payload to indicate that the packets relate to service-specific application data rather than service discovery inquiries, where the incoming packets comprise an explicit signal to wake the components in the main processing system, etc.).
- the service provider device 710 and the service consumer device 720 may be expected to respond to service discovery inquiries and exchange ping and/or keep-alive messages with one another to preserve the connection/association therebetween (even during standby or idle states), the ASPs 716 , 726 may terminate the sockets for such messaging at the low-power low-bandwidth co-processor subsystem on the respective device 710 , 720 . Accordingly, offloading various device discovery and service discovery tasks to the low-power low-bandwidth co-processor subsystem may allow the service provider device 710 and/or the service consumer device 720 to keep the high-power high-bandwidth components in the main processing system in a low-power state (e.g., sleep mode) as much as possible.
- a low-power state e.g., sleep mode
- the low-power low-bandwidth co-processor subsystem may act as a proxy for the components in the high-power high-bandwidth main processing system to optimize performance. Moreover, the low-power low-bandwidth co-processor subsystem may pre-process and/or trap certain commands and timing-critical messages (e.g., synchronization and interrupt look-ups) to expedite or otherwise optimize processing that may be finished using the components in the high-power high-bandwidth main processing system (once woken from the low-power state).
- commands and timing-critical messages e.g., synchronization and interrupt look-ups
- FIG. 8A-8B illustrate an exemplary architecture associated with a wireless device 800 that may include a low-power low-bandwidth co-processor subsystem 830 disposed in a wireless application datapath, wherein the low-power low-bandwidth co-processor subsystem 830 may be referred to herein as the “co-processor subsystem” or the like for simplicity.
- the low-power low-bandwidth co-processor subsystem 830 may be referred to herein as the “co-processor subsystem” or the like for simplicity.
- the wireless device 800 may include at least one wireless radio 850 that support one or more peer-to-peer (P2P) and/or device-to-device (D2D) technologies (e.g., one or more 802.11 Wi-Fi radios, a Bluetooth radio, a cellular modem that supports LTE-Direct, etc.).
- P2P peer-to-peer
- D2D device-to-device
- the wireless radio(s) 850 may be coupled to a high-power high-bandwidth processing subsystem 810 , which may be alternatively referred to herein as the “main wireless processing subsystem” or the like, in addition to the co-processor subsystem 830 .
- the main wireless processing subsystem 810 may comprise a host bridge 822 that couples the wireless radio(s) 850 to an interconnect and system memory 824 and a host application processor and high-level operating system 826 .
- the co-processor subsystem 830 may comprise a synchronous host interface coupled to the wireless radio(s) 850 in addition to a local on-chip memory 837 configured to store one or more outgoing data packets associated with one or more service discovery tasks offloaded from the main wireless processing subsystem 810 and related schedules to send the one or more outgoing data packets.
- the co-processor subsystem 830 may include a packet acquisition (application data mover) module 833 that may be configured to move the outgoing data packets for transmission via the wireless radio(s) 850 according to the corresponding schedule(s) and further to move incoming data packets that are received via the wireless radio(s) 850 to the on-chip memory 837 .
- a packet acquisition (application data mover) module 833 may be configured to move the outgoing data packets for transmission via the wireless radio(s) 850 according to the corresponding schedule(s) and further to move incoming data packets that are received via the wireless radio(s) 850 to the on-chip memory 837 .
- the co-processor subsystem 830 may further comprise a programmable deep-packet inspection (DPI) module 835 configured with one or more dynamic rules to pre-process the incoming data packets that are received via the wireless radio(s) 850 , wherein the one or more dynamic rules may be based (at least in part) on a service description associated with one or more service discovery protocols that correspond to one or more services to provide or consume at the wireless device 800 .
- DPI deep-packet inspection
- criteria specified in the one or more dynamic rules may relate to one or more parameters or other information that relates to operating conditions or states associated with the wireless device 800 .
- the dynamic rules may specify criteria that relate to a battery health state, a battery charge state, synchronization accuracy between timing associated with one or more services provided and/or consumed at the wireless device 800 and a master clock on the wireless device 800 , available CPU capacity, available memory reserves, bandwidth requirements, latency requirements, etc.
- the dynamic rules may generally specify one or more conditions under which to wake one or more component(s) in the main wireless processing subsystem 810 or otherwise invoke processing in the main wireless processing subsystem 810 according to the particular semantics used in the service descriptions associated with the one or more services provided and/or consumed at the wireless device 800 .
- the dynamic rules may optionally further specify the conditions under which to wake one or more component(s) in the main wireless processing subsystem 810 or otherwise invoke processing in the main wireless processing subsystem 810 according to operating conditions or current states on with the wireless device 800 .
- the co-processor subsystem 830 may be configured to transmit scheduled outgoing messages to publish/advertise requirements associated with one or more services provided on the wireless device 800 and/or one or more desired services to be consumed at the wireless device 800 (e.g., whether the wireless device 800 , a service consumer peer device, and/or a service provider peer device has speaker(s) or merely display capabilities, whether the provided services and/or the desired services require the service consumer peer device and/or service provider peer device to report ambient temperature, etc.).
- publish/advertise requirements associated with one or more services provided on the wireless device 800 and/or one or more desired services to be consumed at the wireless device 800 e.g., whether the wireless device 800 , a service consumer peer device, and/or a service provider peer device has speaker(s) or merely display capabilities, whether the provided services and/or the desired services require the service consumer peer device and/or service provider peer device to report ambient temperature, etc.
- the co-processor subsystem 830 may be further configured to inspect any incoming data packets to determine whether any service requirements and/or device capabilities specified therein match the one or more available services provided on the wireless device 800 and/or the one or more desired services to be consumed at the wireless device 800 , whereby the co-processor subsystem 830 may only awaken or otherwise engage one or more component(s) in the main wireless processing subsystem 810 when one or more incoming packets received from a peer device specify service requirements and/or device capabilities that match an available service provided on the wireless device 800 and/or a desired service to be consumed at the wireless device 800 , depending on the service-specific use case(s) and the particular semantics used in the service description(s) associated with the service-specific use case(s).
- the programmable DPI module 835 may initially pre-process the incoming data packets, which may comprise inspecting headers, data parts, or other suitable contents associated with the incoming data packets to collect statistical information (e.g., payload size) and/or determine whether the one or more dynamic rules to invoke processing in the main wireless processing subsystem 810 have been triggered.
- statistical information e.g., payload size
- the programmable DPI module 835 may determine whether the pre-processed data packets include an “ok-to-sleep” command, in which case the programmable DPI module 835 may notify one or more components in the main wireless processing subsystem 810 that transitioning to a lower power state is permitted (e.g., from an idle/standby to a sleep/dormant state, from the sleep/dormant state to a deep sleep/hibernate state, etc.).
- a lower power state e.g., from an idle/standby to a sleep/dormant state, from the sleep/dormant state to a deep sleep/hibernate state, etc.
- the programmable DPI module 835 may notify the components in the main wireless processing subsystem 810 to transition to an active state and move any buffered data to a memory associated with the host application processor 826 .
- the programmable DPI module 835 may engage the components in the main wireless processing subsystem 810 and move the buffered data to the memory associated with the host application processor 826 , as the buffered data would exceed the available processing capacity within the co-processor subsystem 830 .
- the programmable DPI module 835 may perform pattern matching to compare one or more service requirements, capabilities, and/or other suitable information conveyed in the pre-processed data packets to the one or more dynamic rules and engage one or more components in the main wireless processing subsystem 810 in response to matching the information conveyed in the pre-processed data packets to any service-specific conditions that require processing in the main wireless processing subsystem 810 . Otherwise, in response to the pre-processed data packets passing all the filters implemented at the programmable DPI module 835 , the pre-processed ata packets may be stored in the buffer associated with the low-power co-processor 839 , which may then further process the incoming data packets.
- the low-power co-processor 839 may further process the incoming data packets to handle any service discovery tasks that were offloaded from the main wireless processing subsystem 810 .
- the offloaded service discovery tasks may comprise responding to the incoming data packets without invoking processing in the main wireless processing subsystem 810 where the criteria associated with the incoming data packets do not trigger the one or more dynamic rules and sending the outgoing messages (e.g., service announcements, advertisements, status changes, etc.).
- processing in the main wireless processing subsystem 810 may be invoked in response to the criteria associated with the incoming data packets meeting the one or more dynamic rules.
- the low-power co-processor 839 may perform pattern matching that involves more complex multi-string matching. Accordingly, the low-power co-processor 839 may consider one or more parameters or other information that relates to operating conditions or states associated with the wireless device 800 in combination with service-specific requirements and/or device capabilities to determine whether any dynamic rules that require processing in the main wireless processing system 810 have been triggered. For example, the co-processor 839 may respond to incoming data packets that comprise service discovery inquiries about available services provided on the wireless device 800 and/or desired services to be consumed at the wireless device 800 without waking the components in the main wireless processing subsystem 810 .
- the co-processor 839 may engage the components in the main wireless processing subsystem 810 where the incoming data packets have a payload size that exceeds a particular service-specific threshold (e.g., a payload size associated with service-specific application data, whereas service discovery inquiries and other similar messages may typically have a relatively small payload size).
- the co-processor 839 may engage the components in the main wireless processing subsystem 810 in the event that the incoming data packets specify one or more service requirements and/or device capabilities that match the available services provided on the wireless device 800 and/or the desired services to be consumed at the wireless device 800 to request appropriate assistance that may be needed to establish the service-specific session (e.g., binding ports, establishing sockets, etc.).
- the dynamic rules may specify one or more service-specific search strings to define conditions that may require processing at the components in the main wireless processing subsystem 810 , wherein the co-processor 839 may engage the components in the main wireless processing subsystem 810 in response to detecting one or more matching strings that indicate a need to utilize the higher power, higher bandwidth processing capabilities available therein.
- the bandwidth needed to achieve sufficient screen sharing performance may depend on screen size, resolution, and/or other relevant parameters.
- the resolution is approximately 640 ⁇ 480 pixels, little bandwidth may be needed, whereas Ultra HD 4K resolution at 3840 ⁇ 2160 lines requires large bandwidth.
- the dynamic rules in screen sharing use cases may depend on the frames per second processing resources available at the wireless device 800 and/or any peer devices involved in the screen sharing, in that Ultra HD 4K screen sharing may generally require a wall-plugged power source.
- the service-specific dynamic rules may require that peer endpoints exchange information relating to available power sources and capabilities to display data at the necessary frames per second, whereby the components in the main wireless processing subsystem 810 may be invoked in the event that the incoming data packets indicate that the co-processor subsystem 830 cannot meet the demanded performance.
- resolving audio in stereo may require relatively little throughput, as the more important issue instead pertains to maintaining synchronization between left and right channels.
- the dynamic rules may specify that the components in the main wireless processing subsystem 810 should be invoked if the peer device indicates that synchronization has been lost between the left and right channels.
- the dynamic rules may specify that the components in the main wireless processing subsystem 810 should be invoked if the wireless device 800 determines that synchronization has been lost between the left and right channels.
- the dynamic rules may define one or more search strings (e.g., binary search strings) to compare against parameters carried in protocol-specific and service-specific messages, wherein the components in the main wireless processing subsystem 810 may be invoked in response to the protocol-specific and service-specific messages including criteria that matches the search strings defined in the one or more dynamic rules. Otherwise, processing may continue to be offloaded to the co-processor subsystem 830 .
- search strings e.g., binary search strings
- the dynamic rules may be redefined or otherwise tuned in response to a determination that the components in the main wireless processing subsystem 810 were not required to achieve the necessary performance demands and thereby increase the time that the components in the main wireless processing subsystem 810 can remain in a low-power state.
- the architecture illustrated therein may operate the co-processor subsystem 830 in a look-aside mode. More particularly, in the look-aside mode, outgoing messages that relate to service announcements, service advertisements, service status changes, service inquiries, and responses to certain incoming messages (e.g., incoming service inquiries) may be buffered in the on-chip memory 837 .
- the packet acquisition module 833 may then move the outgoing messages from the on-chip memory 837 to the synchronous host interface 831 according to any applicable schedules related thereto (e.g., one or more schedules that define when to publish service announcements, service advertisements, service status changes, inquiries about desired services, etc.).
- the synchronous host interface 831 may then cause the outgoing messages to be transmitted via the wireless radio(s) 850 , whereby the outgoing messages may be transmitted via an outgoing data path 842 that bypasses the main wireless processing subsystem 810 altogether.
- incoming data packets may be received at the co-processor subsystem 830 via an incoming data path 844 that likewise bypasses the main wireless processing subsystem 810 .
- the incoming data path 844 may pass through the wireless radio(s) 850 to the synchronous host interface 831 , and the packet acquisition module 833 may then move the incoming packets to a receive queue on the on-chip memory 837 .
- the programmable DPI module 835 may then perform the above-mentioned pre-processing tasks on the incoming data packets stored in the receive queue and selectively engage the host bridge 822 to either further optimize power consumption or wake one or more components in the main wireless processing subsystem 810 depending on whether or not any incoming data packets do not pass the filters implemented therein
- the pre-processed incoming data packets may be provided to the co-processor 839 , which may further process the incoming data packets against the one or more dynamic rules using a local decision engine, as discussed in further detail above.
- the co-processor 839 may appropriately process the incoming data packets without utilizing any component(s) in the main wireless processing subsystem 810 (e.g., responding to service inquiries, distributing incoming data to service provider and/or service consumer entities on the wireless device 800 , etc.).
- the co-processor subsystem 830 may wake or otherwise engage one or more components in the main wireless processing subsystem 810 to invoke the processing capabilities associated therewith.
- any processing invoked in the main wireless processing subsystem 810 may be expedited or otherwise optimized in that the pre-processing may trap certain commands and/or other suitable messages to ensure that incoming data packets relating to synchronization, interrupt look-ups, or other suitable tasks having timing-critical aspects are processed with minimal latency.
- the components that are invoked in the main wireless processing subsystem 810 may determine whether or not the processing capabilities in the main wireless processing system 810 were actually necessary to deal with the conditions that resulted in the wakeup, whereby the dynamic rules may be redefined or otherwise tuned based on platform and the service-specific use-case context(s) in the event that the components in the main wireless processing subsystem 810 were not required to achieve the necessary performance demands. As such, the dynamic rules may be redefined or otherwise tuned to prevent subsequent unnecessary wakeups, which may therefore not occur if the same conditions arise such that the components in the main wireless processing subsystem 810 can spend more time in the low-power state(s).
- the architecture illustrated therein may operate the co-processor subsystem 830 in a bump-in-the-wire mode, which may alternatively be referred to as a bump-in-the-stack or flow-through mode. More particularly, in the bump-in-the-wire mode, one or more outgoing messages may be stored in the interconnect and system memory 824 in the main wireless processing subsystem 810 and then pass through to the on-chip memory 837 and the programmable DPI module 835 before returning to the interconnect and system memory 824 . The outgoing messages may then be transferred to the host bridge 822 and transmitted over a wireless network via the one or more wireless radios 850 .
- the programmable DPI module 835 may analyze the outgoing messages based on the dynamic rules and service-specific requirements and device capabilities to determine whether any outgoing messages need to be prioritized over other outgoing messages (e.g., prioritizing service-specific application data over device discovery inquiries, service discovery announcements/inquiries, etc.).
- the co-processor subsystem 830 may be utilized to classify outgoing packets according to service-specific flows (e.g., a source IP address and port, a destination IP address and port, service-specific protocols, etc.) and optimize outgoing transmissions to meet quality of service (QoS) and/or quality of experience (QoE) requirements, improve delivery through congestion points, or otherwise queue and shape the outgoing traffic to meet service-specific performance demands and optimize power consumption on the wireless device 800 .
- QoS quality of service
- QoE quality of experience
- the outgoing messages may travel via an outgoing data path 842 that partially traverses the main wireless processing subsystem 810 and the co-processor subsystem 830 .
- the incoming data path 844 may likewise traverse the host bridge 822 and the interconnect and system memory 824 and then flow through the on-chip memory 837 and the programmable DPI module 835 before returning to the interconnect and system memory 724 .
- the programmable DPI module 835 may perform substantially similar pre-processing tasks on the incoming data packets as described above with respect to the look-aside mode except that the incoming data packets may be received via the higher-bandwidth host bridge 822 and interconnect and system memory 824 .
- the bump-in-the-wire mode may therefore offer similar benefits as the look-aside mode in that the host application processor 826 can remain in a low-power state except that the bump-in-the-wire mode may offer greater performance at the cost of utilizing at least some high-power high-bandwidth components in the main wireless processing subsystem 810 . Accordingly, in various embodiments, the bump-in-the-wire mode may be better suited to service-specific use cases that have greater performance demands (e.g., the co-processor subsystem 830 may operate in the look-aside mode to handle simple file transfers or services that involve streaming low resolution VGA video, whereas the bump-in-the-wire mode may be utilized to handle sessions that involve services to stream high resolution HD video).
- FIG. 9 illustrates an exemplary method 900 that a low-power low-bandwidth co-processor subsystem disposed in a wireless application datapath may perform to optimize service discovery power consumption in a wireless service platform. More particularly, at block 910 , one or more components in a main wireless processing subsystem may enter a sleep state or another suitable low-power state and the co-processor subsystem may be configured to operate in either a look-aside mode or a bump-in-the-wire mode to offload one or more service discovery tasks from the components in the main wireless processing subsystem that entered the low-power state.
- the components that enter the low-power state may comprise a host bridge, a main interconnect and system memory, and a host application processor configured to run a high-level operating system.
- the host bridge and the main interconnect and system memory may remain active and only the host application processor enters the low-power state.
- the particular mode in which to operate the co-processor subsystem may be selected at block 910 based on the current operating conditions or states associated on a wireless device and any service-specific requirements and device capabilities.
- the co-processor subsystem may be operated in the look-aside mode to conserve more power.
- the co-processor subsystem may operate in the bump-in-the-wire to optimize performance.
- DPI deep packet inspection
- the service-specific wake-up rules may generally specify one or more conditions under which to wake one or more component(s) in the main wireless processing subsystem or under which to otherwise invoke processing in the main wireless processing subsystem, which may be expressed according to the particular semantics used in the service descriptions associated with one or more services provided and/or consumed at the wireless device.
- the service-specific wake-up rules may optionally further specify the conditions under which to wake one or more component(s) in the main wireless processing subsystem or otherwise invoke processing in the main wireless processing subsystem according to operating conditions or current states on with the wireless device.
- the co-processor subsystem may then determine whether any incoming packets have been received, in which case the incoming packets may be pre-pre-processed according to the service-specific wake-up rules and one or more parameters or other information that relate to the operating conditions and/or current state(s) associated with the wireless device.
- the co-processor subsystem may then determine whether one or more wake-up rules have been triggered at block 930 , in which case the main application processor may be woken from the low-power state and DPI may be disabled at block 935 .
- the host bridge and system interconnect and memory may be further woken from the low-power state.
- any buffered data associated with the incoming packets and any buffered data associated with outgoing messages that are pending transmission may then be moved to a memory associated with the main application processor at block 940 and the main wireless processing subsystem may resume performing the service discovery tasks that would otherwise have been offloaded to the co-processor subsystem.
- the components in the main wireless processing subsystem that entered the low-power state may remain in such a low-power state, as the co-processor subsystem may process/respond to the incoming packets at block 945 without utilizing the main wireless processing subsystem.
- the co-processor subsystem may transmit any scheduled outgoing data packets at block 950 .
- the scheduled outgoing data packets may comprise service announcements, service advertisements, service status changes, responses to service discovery inquiries, inquiries about services desired at the wireless device, etc.
- the co-processor subsystem may proceed directly to block 950 to transmit the scheduled outgoing data packets in response to determining that no incoming packets have been received or a receive queue is otherwise empty.
- FIG. 10 illustrates an exemplary method 1000 that may be performed at the main application processor disposed in a main wireless application datapath to optimize service discovery power consumption in a wireless service platform having a low-power low-bandwidth co-processor subsystem. More particularly, in various embodiments, the method 1000 shown in FIG. 10 may generally be carried out in response to a wake command received at one or more components in the main wireless application datapath, for example, because one or more incoming data packets triggered a service-specific wake-up rule as described in further detail above. As such, any buffered data relating to incoming data packets and/or outgoing messages pending transmission may then be processed at block 1015 .
- the main application processor may then determine whether the wake-up was actually necessary. For example, the wake-up may be deemed unnecessary in response to a determination that the co-processor subsystem could have suitably processed the incoming data packets that triggered the wake-up without compromising any power or other performance demands associated with one or more provided and/or consumed services to which the incoming data packets pertain. As such, in response to determining that the wake-up was unnecessary, the service-specific wake-up rules that resulted in the unnecessary wake-up may be tuned or otherwise adjusted at block 1025 such that subsequent unnecessary wakeups may not occur if the same conditions arise.
- the components in the main wireless application datapath may then determine whether conditions are such that the components in the main wireless application datapath can re-enter the sleep state at block 1030 , in which case the sleep state may be resumed until a subsequent wake command is received at block 1010 . Otherwise, if the wake-up was necessary and/or conditions are such that the processing capabilities associated with the main wireless application datapath are still needed, the wireless device may continue to utilize the components in the main wireless application datapath to process/respond to incoming data packets and transmit scheduled outgoing data packets until suitable conditions to enter a low-power state arise.
- DSP digital signal processor
- ASIC application specific integrated circuit
- FPGA field programmable gate array
- a general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
- a processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).
- a software module may reside in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
- An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium.
- the storage medium may be integral to the processor.
- the processor and the storage medium may reside in an ASIC.
- the ASIC may reside in a wireless device (e.g., an IoT device).
- the processor and the storage medium may reside as discrete components in a user terminal.
- the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as computer-executable instructions or code on a computer-readable medium.
- Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
- a storage media may be any available media that can be accessed by a computer.
- such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of computer-executable instructions or data structures accessible by a computer.
- any connection is properly termed a computer-readable medium.
- the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave
- the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.
- Disk and disc includes CD, laser disc, optical disc, DVD, floppy disk and Blu-ray disc where disks usually reproduce data magnetically and/or optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.
Abstract
Description
- Various aspects and embodiments described herein generally relate to a smart co-processor that may be provided in a wireless application processing datapath to optimize service discovery power consumption in wireless service platforms that employ out-of-band device-to-device (D2D) communication between peer wireless devices.
- Wireless communication systems are widely deployed to provide various types of communication content, including voice, video, packet data, messaging, and broadcast, among many others. Wireless communication systems (e.g., multiple-access networks that can share available network resources to support multiple users) have developed through various generations, including a first-generation analog wireless phone service (1G), a second-generation (2G) digital wireless phone service (including interim 2.5G and 2.75G networks) and third-generation (3G) and fourth-generation (4G) high speed data/Internet-capable wireless services. There are presently many different wireless communication systems in use, including Cellular and Personal Communications Service (PCS) systems. Example cellular systems include the cellular Analog Advanced Mobile Phone System (AMPS), digital cellular systems based on Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Orthogonal FDMA (OFDMA), Single-Carrier FDMA (SC-FDMA), the Global System for Mobile access (GSM) TDMA variation, and newer hybrid digital communication systems that use both TDMA and CDMA technologies. More recently, Long Term Evolution (LTE) has been developed as a wireless communication protocol for wireless communication of high-speed data for mobile phones and other data terminals. LTE is based on GSM, and includes contributions from various GSM-related protocols (e.g., Enhanced Data rates for GSM Evolution (EDGE)) and Universal Mobile Telecommunications System (UMTS) protocols (e.g., High-Speed Packet Access (HSPA)).
- In general, a wireless communication network may include various base stations (also referred to as evolved node Bs, eNBs, or access nodes) that can support communication for a user equipment (UE). In a WAN, a UE typically communicates via uplink/downlink channels between the UE and a base station to thereby communicate with the base station. However, if two or more UEs are in within sufficient proximity to one another, the UEs may be enabled to communicate directly, that is, without communicating through any base station. A UE may therefore support direct peer-to-peer (P2P) or device-to-device (D2D) communication with one or more other UEs.
- For example, LTE-Direct (LTE-D, sometimes also referred to as “LTE-Advanced”) is a proposed 3GPP (Release 12) D2D solution for proximate discovery. LTE-D dispenses with location tracking and network calls by directly monitoring for services on other LTE-Direct devices within a large range (˜500 m, line of sight). As such, among other advantages, LTE-D can directly monitor for services on other LTE-D devices in a synchronous system and concurrently detect many services in proximity in a continuous and battery efficient manner. In another example, the Wi-Fi Alliance Peer-to-Peer (P2P) Specification, also known as “Wi-Fi Direct” (WFD), supports pre-association service discovery among peer wireless devices. The WFD protocol enables a client wireless device or station (STA) to query peer STAs within Wi-Fi range to determine what services, if any, are available on the peer STAs. Determining the services that peer STAs provide typically involves a device discovery phase and a service discovery phase. During the device discovery phase, a client STA (e.g., a STA requesting a particular P2P service) determines the identity and/or availability associated with other STAs within Wi-Fi communication range via “scanning” the three social channels (e.g.,
channels 1, 6, and 11 in the 2.4 GHz band) to detect incoming beacon frames and/or broadcasting probe request frames to any client STAs that may be listening on the social channels. Thereafter, during the service discovery phase, the client STA queries any available peer STAs that may have been discovered during the device discovery phase about the services that the available peer STAs provide. For example, the client STA typically transmits one or more service discovery requests to each peer STA that supports the service discovery operation, one at a time, until the client STA identifies a suitable peer STA that provides the requested service. - Accordingly, service discovery messaging and signaling is the bedrock for many wireless use cases and application platforms, which may include mirroring, screen sharing, streaming video, streaming audio, remote video/graphics rendition, remote audio rendition, remote sensing, remote control, and file transfers, among many others. In general, service discovery messages and signaling can be used to support announcements and inquiries, composition and mediation, control and presentation, and can further be extended to group management and addressing control, quality of service (QoS) and/or quality of experience (QoE) management, and various other wireless use cases. In any particular wireless application and/or use case where service discovery messaging is used to support out-of-band P2P and/or D2D communication, a wireless application processing datapath can include many ad-hoc devices that will often have unequal capabilities, processing densities, storage capacities, connection and power performance profiles, etc. Furthermore, any device can operate autonomously and without awareness of other devices, whereby operational dependencies and required collaboration among different devices are typically validated and resolved per-application and/or use case. Hence, a collaborative and distributed (unstructured) service discovery framework typically requires regular service discovery messaging, which may require that each peer device maintain one or more components in a wireless application datapath in an always-on state (e.g., a host bridge, interconnect and system memory, host application processor and high-level operating system typically used to process service discovery messages and signaling).
- As such, the need to process and respond to occasional service discovery messages may cause components in the wireless application datapath to stay in an always-on state, which can consume substantial power even though service discovery messages typically have small payloads (e.g., a few bytes). Furthermore, because each client STA typically has no knowledge about whether or not the service(s) that other previously discovered peer STAs provide have changed unless the service discovery (and device discovery) operations are periodically repeated with each peer STA, establishing and maintaining out-of-band P2P and/or D2D connections can consume substantial time and resources, which may be especially problematic in battery-powered electronic devices.
- The following presents a simplified summary relating to one or more aspects disclosed herein. As such, the following summary should not be considered an extensive overview relating to all contemplated aspects, nor should the following summary be regarded to identify key or critical elements relating to all contemplated aspects or to delineate the scope associated with any particular aspect. Accordingly, the following summary has the sole purpose to present certain concepts relating to one or more aspects disclosed herein in a simplified form to precede the detailed description presented below.
- According to various aspects, a low-power co-processor may be used to optimize power consumption in a wireless service platform with a main wireless application datapath, wherein certain service discovery tasks may be offloaded from the main wireless application datapath to the low-power co-processor subsystem (e.g., such that components in the main wireless application datapath can transition to and/or remain in a low-power state as much as possible). For example, the service discovery tasks offloaded to the low-power co-processor subsystem may be determined according to protocol-specific service descriptions associated with one or more services to be provided and/or consumed at the wireless device. Furthermore, rules to wake the components in the main wireless application datapath may be dynamically defined and redefined or otherwise tuned to maximize the time that the components in the main wireless application datapath can spend in a low-power state and to determine conditions under which to selectively wake the components in the main wireless application datapath as needed.
- According to various aspects, a method for optimizing power consumption in a service discovery wireless services platform may comprise establishing a peer-to-peer wireless connection at a wireless device, transitioning one or more components in a main wireless application datapath associated with the wireless device (e.g., a main application processor) to a sleep state, and offloading one or more service discovery tasks from the one or more components transitioned to the sleep state to a low-power co-processor coupled to the one or more components in the main wireless application datapath, wherein the one or more service discovery tasks offloaded to the low-power co-processor may be determined at least in part according to a service description associated with a service discovery protocol used in the peer-to-peer wireless connection. Furthermore, according to various embodiments, the method may comprise defining one or more dynamic rules to wake the one or more components in the main wireless application datapath from the sleep state based at least in part on the service description associated with the service discovery protocol used in the peer-to-peer wireless connection. As such, in response to receiving one or more incoming data packets over the peer-to-peer wireless connection at the low-power co-processor, the one or more components in the main wireless application datapath may be selectively woken from the sleep state in response to the one or more incoming data packets having criteria that trigger the one or more dynamic rules.
- According to various aspects, an apparatus may comprise means for establishing a peer-to-peer wireless connection, means for transitioning one or more components in a main wireless application datapath to a sleep state, means for offloading one or more service discovery tasks from the one or more components transitioned to the sleep state, wherein the one or more offloaded service discovery tasks may be determined at least in part according to a service description associated with a service discovery protocol used in the peer-to-peer wireless connection, means for defining one or more dynamic rules to wake the one or more components in the main wireless application datapath from the sleep state based at least in part on the service description associated with the service discovery protocol used in the peer-to-peer wireless connection, means for receiving one or more incoming data packets over the peer-to-peer wireless connection, and means for selectively waking the one or more components in the main wireless application datapath from the sleep state in response to the one or more incoming data packets having criteria that trigger the one or more dynamic rules.
- According to various aspects, a computer-readable storage medium may have computer-executable instructions recorded thereon, wherein executing the computer-executable instructions on one or more processors may cause the one or more processors to establish a peer-to-peer wireless connection at a wireless device, transition one or more components in a main wireless application datapath associated with the wireless device to a sleep state, offload one or more service discovery tasks from the one or more components transitioned to the sleep state to a low-power co-processor coupled to the one or more components in the main wireless application datapath, define one or more dynamic rules to wake the one or more components in the main wireless application datapath from the sleep state based at least in part on a service description associated with the service discovery protocol used in the peer-to-peer wireless connection, receive, at the low-power co-processor, one or more incoming data packets over the peer-to-peer wireless connection, and selectively wake the one or more components in the main wireless application datapath from the sleep state in response to the one or more incoming data packets having criteria that trigger the one or more dynamic rules.
- According to various aspects, a wireless device may comprise a main wireless application datapath that includes a host bridge, an interconnect, system memory, and a host application processor in addition to a low-power hardware processor coupled to the main wireless application datapath. For example, according to various embodiments, the low-power hardware processor may comprise a local memory configured to store one or more outgoing data packets associated with one or more service discovery tasks offloaded from the main wireless application datapath and a schedule to send the one or more outgoing data packets, a programmable deep-packet inspection module configured with one or more dynamic rules to invoke processing in main wireless application datapath and to determine whether criteria associated with one or more incoming data packets received at the wireless device trigger the one or more dynamic rules, wherein the one or more dynamic rules may be based at least in part on a service description associated with a service discovery protocol. In addition, according to various embodiments, the low-power hardware processor may comprise a low-power host processor configured to perform the one or more offloaded service discovery tasks, to respond to the one or more incoming data packets without invoking processing in the main wireless application datapath in response to the criteria associated with the one or more incoming data packets not triggering the one or more dynamic rules, and to invoke the processing in the main wireless application datapath in response to the criteria associated with the one or more incoming data packets triggering the one or more dynamic rules.
- Other objects and advantages associated with the various aspects disclosed herein will be apparent to those skilled in the art based on the accompanying drawings and detailed description.
- A more complete appreciation of aspects of the disclosure and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings which are presented solely for illustration and not limitation of the disclosure, and in which:
-
FIG. 1 illustrates an exemplary wireless network architecture that may support out-of-band device-to-device (D2D) communication, according to various aspects. -
FIG. 2 illustrates another exemplary wireless network architecture supporting out-of-band device-to-device (D2D) communication, according to various aspects. -
FIG. 3 illustrates an exemplary wireless environment in which two wireless devices may communicate over an out-of-band D2D connection, according to various aspects. -
FIG. 4 illustrates an exemplary wireless network architecture in which two or more peer wireless devices may communicate over an out-of-band D2D connection according to one or more service discovery protocols, according to various aspects. -
FIG. 5 illustrates an exemplary power profile at a wireless device configured to communicate over an out-of-band D2D connection, according to various aspects. -
FIG. 6 illustrates an exemplary wireless device that has a low-power co-processor disposed in a main wireless application datapath to support one or more service discovery processing tasks, according to various aspects. -
FIG. 7A andFIG. 7B illustrate exemplary device discovery and service discovery call flows between service provider and service consumer peer devices to establish an out-of-band D2D connection between the peer devices, according to various aspects. -
FIG. 8A illustrates an exemplary architecture associated with a wireless device that may operate a low-power low-bandwidth co-processor subsystem disposed in a wireless application datapath according to a look-aside mode, according to various aspects. -
FIG. 8B illustrates an exemplary architecture associated with a wireless device that may operate a low-power low-bandwidth co-processor subsystem disposed in a wireless application datapath according to a bump-in-the-wire mode, according to various aspects. -
FIG. 9 illustrates an exemplary method that a low-power low-bandwidth co-processor subsystem may perform to optimize service discovery power consumption in a wireless service platform, according to various aspects. -
FIG. 10 illustrates an exemplary method that an application processor disposed in a main wireless application datapath may perform to optimize service discovery power consumption in a wireless service platform having a low-power low-bandwidth co-processor subsystem, according to various aspects. - Various aspects are disclosed in the following description and related drawings to show specific examples relating to exemplary embodiments. Alternate embodiments will be apparent to those skilled in the pertinent art upon reading this disclosure, and may be constructed and practiced without departing from the scope or spirit of the disclosure. Additionally, well-known elements will not be described in detail or may be omitted so as to not obscure the relevant details of the aspects and embodiments disclosed herein.
- The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. Likewise, the term “embodiments” does not require that all embodiments include the discussed feature, advantage or mode of operation.
- The terminology used herein describes particular embodiments only and should not be construed to limit any embodiments disclosed herein. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Those skilled in the art will further appreciate that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof
- Further, many aspects are described in terms of sequences of actions to be performed by, for example, elements of a computing device. Those skilled in the art will recognize that various actions described herein can be performed by specific circuits (e.g., an application specific integrated circuit (ASIC)), by computer-executable instructions being executed by one or more processors, or a combination thereof. Additionally, these sequence of actions described herein can be considered to be embodied entirely within any form of computer readable storage medium having stored therein a corresponding set of computer-executable instructions that upon execution would cause an associated processor to perform the functionality described herein. Thus, the various aspects of the disclosure may be embodied in a number of different forms, all of which have been contemplated to be within the scope of the claimed subject matter. In addition, for each of the aspects described herein, the corresponding form of any such aspects may be described herein as, for example, “logic configured to” perform the described action.
- The techniques described herein may be used in connection with various wireless communication systems such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA systems. The terms “system” and “network” are often used interchangeably. A CDMA system may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), CDMA2000, etc. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. CDMA2000 covers IS-2000, IS-95, and IS-856 standards. A TDMA system may implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA system may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM™, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) is a release of UMTS that uses E-UTRA, which employs OFDMA on the downlink and SC-FDMA on the uplink UTRA, E-UTRA, UMTS, LTE, and GSM are described in documents from an organization named “3rd Generation Partnership Project” (3GPP). CDMA2000 and UMB are described in documents from an organization named “3rd
Generation Partnership Project 2” (3GPP2). For clarity, certain aspects are described below for LTE, and LTE terminology may be used in much of the description below. - According to various aspects,
FIG. 1 illustrates an exemplarywireless network architecture 100 that may support out-of-band device-to-device (D2D) communication, wherein thewireless network architecture 100 may comprise a Long Term Evolution (LTE) (or Evolved Packet System (EPS))network architecture 100. In various embodiments, thenetwork architecture 100 may include a first user equipment (UE1) 102, a second user equipment (UE2) 104, an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) 110, an Evolved Packet Core (EPC) 120, a Home Subscriber Server (HSS) 135, and Internet Protocol (IP)Services 140 associated with an operator (e.g., a mobile network operator (MNO)). TheEPS network architecture 100 can interconnect with other access networks and core networks (not shown), such as a UMTS access network or an IP core network. As shown, theEPS network architecture 100 provides packet-switched services; however, those skilled in the art will readily appreciate that the various concepts disclosed herein may be extended to networks that provide circuit-switched services. - According to various embodiments, the E-UTRAN 110 may include a first evolved
- Node B (eNB1) 112 in communication with
UE 1 102 and a second eNB (eNB2) 114 in communication withUE 2 104. TheeNBs UEs eNBs eNBs EPC 120 for therespective UEs Example UEs UE 1 102 and/orUE 2 104 may also be referred to as a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, etc. - The
eNBs EPC 120 via an Si interface, wherein theEPC 120 may include a Mobility Management Entity (MME) 122,other MMEs 124, aServing Gateway 126, a Multimedia Broadcast Multicast Service (MBMS)Gateway 130, a Broadcast Multicast Service Center (BM-SC) 132, and a Packet Data Network (PDN)Gateway 128. TheMME 122 is a control node that may process signaling between theUEs EPC 120. Generally, theMME 122 provides bearer and connection management, while all user IP packets are transferred through theServing Gateway 126, which may be connected to thePDN Gateway 128. ThePDN Gateway 128 may provide UE IP address allocation as well as other functions. ThePDN Gateway 128 is connected to the Operator IP Services 140, which may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), a PS Streaming Service (PSS), and/or other suitable services. The BM-SC 132 may provide functions for MBMS user service provisioning and delivery and serve as an entry point for content provider MBMS transmission. Furthermore, according to various aspects, the BM-SC 132 may authorize and initiate MBMS Bearer Services within a PLMN, schedule and deliver MBMS transmissions, and/or provide other similar functions. TheMBMS Gateway 130 may be used to distribute MBMS traffic to one or more eNBs that belong to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service (e.g.,eNBs 112, 114), and may be responsible for session management (start/stop) and collecting eMBMS related charging information. - In various embodiments, a UE pair (e.g.,
UE 1 102 and UE2 104) may establish an out-of-band device-to-device (D2D) connection to communicate directly without utilizing therespective eNB 1 112 andeNB 2 114 and subsequently transfer data traffic over the out-of-band D2D connection. In general, one or more entities in the network infrastructure (e.g.,eNBs EPC 120, etc.) may coordinate the out-of-band D2D communication between theUE pair more UEs eNBs 112, 114). In various embodiments, theUE pair UEs UEs UEs - Returning to
FIG. 1 , in another aspect, the network may assist the two ormore UEs UEs 102, 104). In another aspect, the network (e.g., one or more network entities) may control entry to the D2D mode and support handover between the D2D mode and legacy mode. - According to various aspects,
FIG. 2 illustrates another exemplarywireless network architecture 200 supporting out-of-band D2D communication (e.g., using LTE-Direct (LTE-D), Wi-Fi Direct (WFD), or another suitable D2D radio access technology). In particular, thewireless network architecture 200 shown inFIG. 2 may comprise abase station 202 that may include multiple antenna groups (e.g., one antenna group may includeantennas antennas antennas FIG. 2 illustrates thebase station 202 with two antennas for each antenna group, those skilled in the art will appreciate that more or fewer antennas may be utilized for each group. In various embodiments, thebase station 202 may additionally include a transmitter chain and a receiver chain (not shown), which may each in turn comprise a various components associated with signal transmission and reception (e.g., processors, modulators, multiplexers, demodulators, demultiplexers, antennas, and so forth), as will be apparent to those skilled in the art. Additionally, thebase station 202 may be a home base station, a femto base station, a wireless local area network (WLAN) access point, and/or the like. - According to various aspects, the
base station 202 may communicate with one or more devices, such asdevice 216. However, those skilled in the art will appreciate that in various embodiments, thebase station 202 may communicate with substantially any number of devices similar to thedevice 216. As depicted inFIG. 2 , thedevice 216 is in communication with thebase station 202 viaantennas antennas device 216 over aforward link 218 and receive information from thedevice 216 over areverse link 220. In a frequency division duplex (FDD) system, theforward link 218 may utilize a different frequency band than that thereverse link 220, for example. Further, in a time division duplex (TDD) system, theforward link 218 and thereverse link 220 may utilize a common frequency band. - In addition, according to various aspects,
FIG. 2 illustrates afirst peer device 222 and asecond peer device 224 that are in direct communication with one another, such as in a D2D (or peer-to-peer (P2P)) configuration using LTE-Direct, Wi-Fi Direct, etc. Moreover, thefirst peer device 222 is in communication with thesecond peer device 224 usinglinks devices intermediate base station 202 and/or a wired infrastructure to relay communication therebetween. Additionally, the peer devices (or nodes) 222, 224 may relay traffic, whereby thepeer devices wireless network architecture 200 that communicate over an out-of-band D2D connection may provide functionality otherwise similar to thebase station 202 and relay traffic or communications to other devices, until the traffic reaches the ultimate destination associated therewith. Thepeer devices - According to various aspects, the
wireless network architecture 200 may include various devices (or nodes) that are in wireless (or wired) communication, wherein each node may be within sufficient range to one or more other nodes to communicate with the other nodes or utilize the other nodes, such as in a multi-hop topology (e.g., communications may hop from node to node until reaching a final destination). For example, thesecond peer device 224 may comprise a sender node that wishes to communicate withdevice 216 as a receiver node. To enable packet transfer between thesender node 224 and thereceiver node 216, one or more intermediate nodes may be utilized (e.g., thefirst peer device 222 may act as an intermediate node to relay communications from thesender node 224 to thebase station 202, which may also act as an intermediate node to relay the communications to the receiver node 216). However, those skilled in the art will appreciate that any node may be a sender node and/or a receiver node and may perform functions to either send and/or receive information at substantially the same time (e.g., a particular node may broadcast or communicate information at about the same time as receiving information, at different times, etc.). Furthermore, according to various aspects, thewireless network architecture 200 may be configured to allow nodes that have initiated a communication session over a network (e.g., via the base station 202) to move the session to a direct D2D connection in which directly connected nodes may exchange packets natively without any encapsulation. In accordance with various aspects, a “homeless” node may switch to a wireless network without losing an ongoing session, wherein a “homeless” may refer to a node that does not have any home agent entity to assist with keeping ongoing sessions alive while switching to foreign networks and/or to forward any new incoming request(s) to establish new sessions to the node's current location. According to various aspects, nodes may be mobile (e.g., wireless), static (e.g., wired), or any suitable combination thereof - According to various aspects,
FIG. 3 illustrates anexemplary wireless environment 300 in which twowireless devices band D2D connection 350 in the event that the twowireless devices band D2D connection 350. More particularly, as shown inFIG. 3 , thewireless device 310 may have a near-field communication (NFC)radio 311, a wireless wide area network (WWAN)radio 313, a wireless local area network (WLAN)radio 315, and aBluetooth radio 317 that thewireless device 310 can use to communicate within thewireless environment 300. For example, as depicted inFIG. 3 , thewireless device 310 can wirelessly communicate with acellular base station 340 over aWWAN link 341 using theWWAN radio 313. Thewireless device 310 can also wirelessly communicate with a Wi-Fi access point 360 over aWLAN link 361 using theWLAN radio 315. Furthermore, thewireless device 310 can wirelessly communicate with aBluetooth headset 380 and Bluetooth-enabledwearable device 382 over Bluetooth links 381, 383 using theBluetooth radio 317, wherein theBluetooth headset 380 and the Bluetooth-enabledwearable device 382 may be in further wireless communication with each other over aBluetooth link 384. Further still, thewireless device 310 can wirelessly communicate with one or more NFC devices within the “near field” of thewireless device 310 using theNFC radio 311 via magnetic field induction. - Furthermore, according to various aspects, the
second wireless device 320 may likewise have multiple radios that each operate in accordance with a different radio access technology. For example, as shown inFIG. 3 , thesecond wireless device 320 may also have anNFC radio 321, aWWAN radio 323, aWLAN radio 325, and aBluetooth radio 327, wherein thewireless device 320 can use theradios wireless environment 300. For example, as depicted inFIG. 3 , thewireless device 320 can wirelessly communicate with acellular base station 340 over aWWAN link 345 using theWWAN radio 323, with a Wi-Fi access point 360 over aWLAN link 365 using theWLAN radio 325, with aBluetooth headset 385 and a Bluetooth-enabledwearable device 387 over Bluetooth links 386, 388 using theBluetooth radio 327, wherein theBluetooth headset 385 and the Bluetooth-enabledwearable device 387 may be in further wireless communication with each other over aBluetooth link 389. Further still, thewireless device 320 can wirelessly communicate with one or more NFC devices within the “near field” of thewireless device 320 using theNFC radio 321 via magnetic field induction. Furthermore, those skilled in the art will appreciate that although thewireless devices FIG. 3 as communicating with the samecellular base station 340, in which case the WWAN links 341, 345 may have a common endpoint, thewireless devices respective WWAN links wireless devices FIG. 3 as communicating with the same Wi-Fi access point 360, those skilled in the art will appreciate that thewireless devices respective WLAN links - According to various aspects, in addition to the communicating with the
cellular base station 340 viaWWAN links Fi access point 360 via the WLAN links 361, 365, thewireless devices band D2D connection 350 in the event that thewireless devices wireless devices wireless devices WWAN radios wireless devices WLAN radios wireless devices wireless devices Bluetooth radios wireless devices NFC radios wireless devices wireless devices respective applications 318, 328 (e.g., an email application) that are associated with the same user name and credentials, existing synchronization algorithms and implementations typically involve eachwireless device latest account data application wireless devices wireless devices band D2D connection 350 based onappropriate service data respective wireless device - For example, LTE-Direct (LTE-D, sometimes referred to as “LTE-Advanced”) is a proposed 3GPP (Release 12) D2D solution for proximate discovery, wherein LTE-D dispenses with location tracking and network calls by directly monitoring for services on other LTE-D devices within a large range (˜500 m, line of sight) to concurrently detect services in proximity. Accordingly, LTE-D is a D2D solution that enables service layer discovery and D2D communication, wherein
applications wireless devices 310, 320) can instruct LTE-D to monitor for application services on other devices and announce locally available services (for detection by services on other LTE-D devices) at the physical layer. As such, the client application(s) 318, 328 may be notified when a match to an establish “monitor” is detected. For example, the application(s) 318, 328 can establish a monitor for “synchronization events” and the LTE-D discovery layer can wake-up the application(s) 318, 328 when a synchronization-related LTE-D expression is detected. LTE-D is thus a distributed discovery solution that may not require a centralized database to identify relevant matches, which are instead autonomously determined at the device level by transmitting and monitoring for relevant attributes. - In another example, Wi-Fi Direct (WFD) is a device-to-device (D2D) specification developed under the Wi-Fi Alliance (WFA), which provides a means that IEEE 802.11 devices can use to discover and communicate directly with each other without using a central node, such as an access point (AP) or a base station (BS). WFD may allow Wi-Fi devices, or peer wireless devices, to address usage models that are traditionally covered under Bluetooth and ad hoc networks, such as an independent basic service set (IBSS). WFD addresses device discovery, service discovery, security, user set-up, and cross-connection to the infrastructure network. WFD generally has a range substantially equivalent to standard Wi-Fi, security using WPA2 (e.g., Advanced Encryption Standard (AES) encryption), three 20 MHz channels in the 2.4 GHz band and twenty-five 20 MHz channels in the 5 GHz band, device authentication and enrollment with Wi-Fi Protected Setup (WPS) (or Wi-Fi Simple Configuration (WSC)), an IP-address-based protocol, service advertisement, power management allowing both devices to sleep, one-time or persistent connections, and concurrency with infrastructure networks (i.e., networks using a central node). Accordingly, in WFD, a group owner (GO) may act as a master peer device and may support connections with multiple client peer devices. The GO has functionality similar to an access point in a traditional system, except that the GO can enter a power saving state. A WFD peer group typically has a single basic service set identifier (BSSID), a single GO, one or more client peer devices, and a single group identifier, which may be a one-time group or a persistent group identifier.
- Accordingly,
FIG. 4 illustrates an exemplarywireless network architecture 400 in which two or more peer wireless devices may communicate over an out-of-band D2D connection according to one or more service discovery protocols. In general, thewireless network architecture 400 shown inFIG. 4 will be described herein in relation to service discovery procedures used in Wi-Fi Direct (WFD). However, those skilled in the art will appreciate that such description is for illustration purposes only and that the issues involved in the service discovery framework shown inFIG. 4 may likewise apply to service discovery procedures used in other D2D technologies. - According to various aspects, the
wireless network architecture 400 shown inFIG. 4 may support service discovery protocols used in various application service platforms, where an application service platform (ASP) may generally refer to a software service or library that implements the functions that applications and services need to establish and communicate over a session between aservice provider device 410 and aservice consumer device 420. For example, applications and/or use cases built on the one or more service discovery protocols may include mirroring (or screen sharing), streaming video, streaming audio, remote video and/or graphics rendition, remote audio and/or audio rendition, remote sensing, remote control, file transfer, and so on. In various embodiments, as will be described in further detail herein, theservice provider device 410, theservice consumer device 420, and acontrol point 430 may exchange various service discovery messages and other signaling messages to support announcements and inquiries, composition and mediation, control, presentation, group management, addressing control, quality of service (QoS) and/or quality of experience (QoE) with respect to various applications/use cases. - More particularly, assuming that the
service provider device 410 supports one or more peer-to-peer (P2P) services, aservice discovery broker 412 associated with theservice provider device 410 may publish one or more service advertisements to provide information about the one or more P2P services such that a service seeker on another device (e.g., the service consumer device 420) can search for, find, and initiate an ASP session with the ASP on theservice provider device 410. For example, according to various embodiments, the service advertisements may include a service name, an identifier associated with theservice provider device 410, and one or more pointers to more detailed information about the one or more services (e.g., a protocol-specific service description). Thecontrol point 430 may then discover and review the one or more service advertisements to learn about theservice provider device 410 and the capabilities associated therewith, retrieve the appropriate device and service descriptions, send actions to theservice discovery broker 412, poll theservice discovery broker 412 for service state variables, and receive events from theservice discovery broker 412. As such, thecontrol point 430 may be configured to provide a registry that maintains service descriptions, device information, and/or other suitable information to facilitate service-specific P2P sessions in thewireless network architecture 400. For example, in various embodiments, a service discovery andregistration agent 422 may periodically solicit information from thecontrol point 430 to learn services that are available in thewireless network architecture 400, while theservice discovery broker 412 may expose controls and status associated with the available services. - As such, according to various aspects, the
control point 430 may use one or more service descriptions to send control messages (or actions) to theservice discovery broker 412 on theservice provider device 410 and/or the service discovery andregistration agent 422 on theservice consumer device 420, which may then return one or more action-specific corresponding values. With respect to events, thecontrol point 420 may subscribe to receive service descriptions or actions to change service variables that model service states, whereby theservice provider device 410 and/or theservice consumer device 420 may send event messages to update one or more state variables and current values associated with the state variables. Accordingly, when theservice consumer device 420 finds and uses the one or more services offered at theservice provider device 410, management data and service data may be exchanged between aservice distribution module 414 on theservice provider device 410 and aservice execution module 424 on theservice consumer device 420. For example, once a service session has been bound or otherwise established between theservice discovery broker 412 and the service discovery andregistration agent 422, the management data exchanged between theservice distribution module 414 and theservice execution module 424 may define the service invocation methods, input resolutions, and/or any additional dependencies needed to perform actual service work and return data. - Accordingly, in the description provided herein, service discovery may generally refer to the system architecture, methods, algorithms, and protocols that enable the
service consumer device 420 to discover one or more services that match one or more required conditions associated with a service to be consumed in the appropriate system architecture without prior configuration. For example, one known service discovery architecture is Zero-configuration networking (Zeroconf), which resolves addressing, naming, service discovery, and automatic device and service configuration across heterogeneous networks without needing any centralized entity as in the Domain Name Service (DNS) and Dynamic Host Configuration Protocol (DHCP). In particular, devices that support Zeroconf use Multicast DNS (mDNS) to store service information in DNS resource records, whereby Zeroconf employs DNS Service Discovery (DSN-SD) such that standard DNS programming interfaces, servers, and packet formats can be used to browse the network and find available services. To that end, Zeroconf requires devices to support publication to expose a service, discovery to enable browsing for available services, and resolution to translate service name nomenclatures to actual logical addresses and port numbers. In that sense, considerations applicable to any service discovery architecture may include the relevant service discovery objectives (e.g., providing a common description language, service information storage, and mechanisms to enable searching for services). In addition, the considerations may relate to how services are administered (e.g., updating service directories due to changes to service descriptions, network topologies, etc.), service information storage classification (e.g., centralized, unstructured distributed, structured distributed, flat, hierarchical, hybrid, etc.), as well as service description access and service discovery methods. For example, in centralized and structured distributed storage environments, service description access may be controlled through a directory node that may be identified and required to publish advertisements and requests, whereas structured distributed storage systems may have directory nodes relay service discovery messages to other directory nodes according to the applicable overlay structure. In another example, direct service access may be addressed to the directory nodes or disseminated in the network. With respect to service discovery methods, passive (or push) models may allow agents and brokers to passively receive announcements about devices and available services, whereas agents and brokers may actively interrogate or inquire about devices and available services in architectures that employ active (or pull) models. - Furthermore, with respect to performance, various additional service discovery considerations may exist. For example, functional issues may include, without limitation, service selection, usage and QoS/QoE, security/privacy (e.g., authentication, authorization, trust, confidentiality, integrity, non-repudiation, etc.), network type (e.g., wired, wireless, client density, size, bandwidth, etc.), and device capabilities. In the QoS/QoE context, specific performance issues may include network scalability, group communication, load balancing and query efficiency (e.g., more directory nodes and service groupings, caching to minimize overloading nodes, load balancing and load distribution to new devices, hierarchical structures, distributed hash indexing, overlay structure optimization, and service description aggregation) as well as fault tolerance, timing and synchronization, mobility support, and resource-aware optimization (e.g., power and battery optimizations, network bandwidth optimizations, etc.). Accordingly, depending on the application(s) and/or use case(s) supported in the service discovery architecture, a wireless application datapath associated with a particular service can comprise many ad-hoc devices that can be expected to have unequal capabilities, processing densities, storage capacities, connection and power performance profiles, etc. Furthermore, because any device can operate autonomously and without awareness of other devices, operational dependencies and required collaboration among different devices will typically be validated and resolved per-application and/or use case such that a collaborative and distributed (unstructured) service discovery framework may best enable all essential features.
- However, in order to support such a collaborative and distributed (unstructured) service discovery framework, each peer device would have to be maintained in an always-on state, which can lead to significant performance issues. For example,
FIG. 5 illustrates an exemplary power profile at a wireless device that communicates over an out-of-band D2D connection to provide and/or consume one or more P2P services. In particular, the example power profile shown inFIG. 5 may apply to a wireless device that communicates using an 802.11ac Wi-Fi transceiver, where the vertical axis shows milliamps (mA) consumed at 4.0 volts DC as a function of time as shown on the horizontal axis. As shown inFIG. 5 , power consumed while the wireless device is on a home screen (and prior to establishing a wireless session) is approximately 800 milliamps (mA), wherein the home screen power consumption jumps to around 1000 mA after session establishment and power consumption stays at or above that level even during standby/idle periods when no wireless traffic exists, which amounts to ˜1 W in static power consumption. As such, depending on the service information storage type, service description access, and service discovery methods, occasional service discovery messaging causes the wireless device to maintain various components in a main wireless application datapath in an always-on state, leading to substantial unnecessary power consumption. For example, many service discovery messages have relatively small payloads (e.g., only a few bytes), which may not require the substantial processing resources provided in the main wireless application datapath. As such, the various aspects and embodiments described herein introduce a smart co-processor or other processing component(s) having a low-power profile into the main wireless application datapath such that the low-power co-processor can assume certain processing functions that the components in the wireless application datapath would typically perform and thereby reduce the overall power consumption associated with service discovery messaging. Furthermore, as will be described in further detail herein, the low-power co-processor may be configured to selectively engage the components in the wireless application datapath when needed such that the components that consume more power are only utilized to perform more intensive processing tasks or when otherwise required. - More particularly, according to various aspects,
FIG. 6 illustrates anexemplary wireless device 600 that may have a low-power co-processor subsystem 660 disposed in a main wireless application datapath to assist with one or more service discovery processing tasks and thereby optimize service discovery power consumption and/or other service discovery processing tasks associated with a wireless service platform. As such, thewireless device 600 shown inFIG. 6 may correspond to a service provider device, a service consumer device, or any other suitable device in a wireless application datapath associated with one or more services that are provided between peer devices. For example, in various embodiments, thewireless device 600 may include adisplay processor 670 that can encode or otherwise process video data to present on alocal display 672 and/or anexternal display 674 on an external device. In certain use cases, thedisplay processor 670 may process the same video data to display on both thelocal display 672 and theexternal display 674, or thedisplay processor 670 may alternatively only process video data to display on thelocal display 672 or theexternal display 674. In a similar respect, thewireless device 600 may include alocal audio subsystem 680 that can process audio data to present through local audio output mechanisms (e.g., internal speakers, a headphone interface, etc.) and/or anexternal audio subsystem 684, wherein thelocal audio subsystem 680 may process the same audio data to present locally and through theexternal audio subsystem 684 or alternatively only process audio data to present locally or through theexternal audio subsystem 684. Accordingly, in various embodiments, thewireless device 600 may include aservice discovery subsystem 650 configured to manage various aspects associated with providing and/or consuming services associated with one or more peer devices, which may involve coordination with thedisplay processor 670 and associated components to support services that relate to mirroring, screen sharing, streaming video, remote video/graphics rendition, etc., coordination with thelocal audio subsystem 680 and associated components to support services that relate to streaming audio, remote audio rendition, coordination with asensor platform 626 to support services that relate to remote sensing, and so on. - Furthermore, in various embodiments, the
service discovery subsystem 650 may be configured to coordinate various tasks that relate to device discovery, which may include discovering or otherwise determining Media Access Control (MAC) addresses or other suitable identifying information associated with one or more discovered peer devices, location coordinates associated with such peer devices, P2P services available on the discovered peer devices, and/or other suitable configuration information pertaining to any discovered peer devices. In various embodiments, theservice discovery subsystem 650 may be configured to store the information pertaining to the discovered peer devices in local storage, acache 622, a memory associated with the low-power co-processor subsystem 660, and/or any suitable combination thereof. For example, in various embodiments, the information pertaining to each discovered peer device may be stored in a table, which may include a peer device field to store a name associated with each discovered peer device, an address field to store the MAC address associated with each discovered peer device, a coordinate field to store the location coordinates associated with each discovered peer device, a service field to store information about the P2P services (if any) that are available on the discovered peer device, and one or more hash values that correspond to service query strings that identify the services available at each peer device. - According to various embodiments, the
service discovery subsystem 650 may further coordinate various tasks that relate to service discovery, which may include discovering or otherwise determining one or more service descriptions that are associated with services available on thewireless device 600 and/or the available services on any discovered peer devices. For example, service discovery protocols generally rely on protocol-specific service descriptions (or specifications) that are passed between peer endpoints (e.g., according to a service_information parameter that provides detailed information about a specific individual service). As such, in various embodiments, a peer device may discover other peer devices via a Scan phase in which a scanning peer device seeks to discover existing P2P networks, which may have a group owner (GO) send out beacons that may be heard at a peer device listening to all available channels. In that context, the Scan phase may include an Active Scan or a Passive Scan, wherein an Active Scan may involve the peer device sending probe requests on all available channels and soliciting probe responses from an access point or a GO, while a peer device conducting a Passive Scan may dwell on all channels and listen for beacons. Alternatively, in various embodiments, a peer device may discover other peer devices via a Find phase in which the scanning peer device seeks to discover other peer devices that have not already formed a P2P group. In that context, the Find phase may include a Search state and a Listen state, wherein the Search state may comprise a peer device transmitting one or more probe request frames on each social channel (e.g.,channel 1, 6, and 11 in the 2.4 GHz band). In the Listen state, the peer device may wait on a specific social channel (e.g., the Listen channel) and listen for probe requests having a certain type (e.g., a specific requested service). The peer device may then filter the requests based on the desired device and/or service type to identify one or more matching probe responses that may be sent with the appropriate service description in addition to any other information suitable to consume the service. For example, many service discovery protocols use an attribute-value structure to format the service description according to a human-readable and machine-readable template document, while the Bluetooth Service Description Protocol (SDP) contains all information about a service is within a service record (e.g., an attribute list) and others use hierarchical attribute-value pairs, XML-based ontologies, object-oriented paradigms, etc. In any case, theservice discovery subsystem 650 may be configured to store the service description(s) pertaining to any discovered services available on thewireless device 600 and/or one or more peer devices in local storage, thecache 622, the memory associated with the low-power co-processor subsystem 660, and/or any suitable combination thereof. As such, in various embodiments, theservice discovery subsystem 650 may be configured to appropriately distribute the service description(s) among interested components on thewireless device 600 such that service-specific rules to define the processing tasks to be carried out on the low-power co-processor subsystem 660 and/or theapplication processor 620 in the main wireless application datapath can be determined, applied, and dynamically tuned to optimize performance associated with thewireless device 600. - According to various aspects, the wireless device may include a
host bridge 640, which may be dedicated to communication purposes, included in a general-purpose processor associated with thewireless device 600, or any suitable combination thereof. In various embodiments, thehost bridge 640 may be configured to manage a 3G/4G cellular modem 642, a Bluetooth (BT) radio 644, a global positioning system (GPS) 646 receiver, and a Wi-Fi radio 648 in addition to any other modules and/or units that thewireless device 600 may use to communicate over wired and/or wireless interfaces. Furthermore, in various embodiments, the Wi-Fi radio 648 may include a Wi-Fi transceiver that operates according to conventional Wi-Fi protocols (e.g., an 802.11n/802.11ac transceiver) and/or an independent high performance Wi-Fi transceiver (e.g., an 802.11ad transceiver). In various embodiments, thehost bridge 640 may be configured to establish a session with one or more peer devices using one or more components in a main wireless application datapath, which may further include an interconnect andsystem memory 610 and anapplication processor 620. However, as will be described in further detail below, the low-power co-processor subsystem 660 may be disposed in the wireless application datapath to detect service discovery messages, events, and signals in incoming packets, wherein the low-power co-processor subsystem 660 may have sufficient memory to store outgoing messages and related schedules to transmit the outgoing messages via the Wi-Fi radio 648, the BT radio 644, the 3G/4G cellular modem 642, etc. As such, the low-power co-processor 660 may be used to offload various service discovery tasks from the high-power and high-bandwidth components in the wireless application datapath, which can therefore enter a low-power state until needed to carry out more intensive processing tasks. - According to various embodiments, the
wireless device 600 may further include astorage device 654 coupled to the interconnect andsystem memory 610 through a peripheral interface 652. For example,storage device 654 may comprise a flash drive, a Universal Serial Bus (USB) drive, an SD card, or any other suitable external storage device. In addition, data stored in thestorage device 654 may be received from storage or in real-time from a private network or a public network (e.g., the Internet) via thehost bridge 640. In one embodiment, thewireless device 600 may further include anapplication data mover 664 that may move data from thestorage device 654 tolocal memory 614 such that theapplication processor 620 and/or the low-power co-processor subsystem 660 can access the data more easily when executing one or more appropriate applications. Furthermore, theapplication processor 620 may be coupled to thecache 622, which may store frequently accessed data. In addition, thewireless device 600 may include agraphics processing unit 662 that can perform any suitable graphics processing that applications running on theapplication processor 620 may require. Furthermore, thewireless device 600 may include one ormore multimedia processors 628 that can provide encoding, decoding, acceleration, and/or other multimedia processing on multimedia content obtained from network sources (e.g., the Internet), from sensors in the wireless device 600 (e.g., a built-in camera) and/or asensor platform 626, and/or any other suitable multimedia source. Furthermore, to present media data on an external sink device, thewireless communication device 600 may include asecurity module 690 that may determine and apply any security information necessary to ensure that media data packets are securely transmitted to the external sink device. - Additionally, the
wireless device 600 may include abattery subsystem 630, which may be configured to monitor the status associated with a battery in thewireless device 600. For example, according to various embodiments, thebattery subsystem 630 may store status information that reflects whether thewireless device 600 has a wall-plugged power source or is using an internal battery as well as the remaining power available on the internal battery (if in use). In various embodiments, the status information relating to the battery may be presented on the local display 680 (e.g., using a small battery icon, lights or sounds to indicate different battery conditions, etc.) and used to configure the functions that are permitted on thewireless device 600 and/or the functions to be offloaded to the low-power co-processor system 660. As such, in various embodiments, the service-specific rules mentioned above can be dynamically defined and/or subsequently redefined or otherwise tuned based on platform and application-specific use-case contexts to maximize battery life. For example, if thewireless device 600 corresponds to a wrist-wearable device, thebattery subsystem 630 may can negotiate and control the services that are to be supported on thewireless device 600, the functions that are permitted on thewireless device 600, etc. according to battery health, a battery charge state, and/or other suitable battery-related parameters (e.g., only tell time, show messages, provide speaker functions, etc. when battery health and/or available power is less than a threshold value, disable flash photography when battery health and/or available power is critically low such that a camera cannot be launched, etc.). In general, thebattery subsystem 630 may update the status information associated with the battery almost continuously to reflect an accurate battery status. In addition, thebattery subsystem 630 may control a clock module that includes various clocks and/or other suitable circuitry used to control functions performed in thewireless device 600. Furthermore, as noted above, the Wi-Fi radio 648 may include multiple independent Wi-Fi transceivers that can offer different performance levels. However, because the different performance levels may have different impacts on the internal battery, wherein the high-performance Wi-Fi transceiver may generally consume more power, thewireless device 600 may implement a demand-based Wi-Fi network control framework to ensure that the high-performance Wi-Fi transceiver will not be used while the low-power co-processor subsystem 660 is active in order to preserve the power optimizations provided therewith, as described in further detail herein. - According to various aspects, the low-
power co-processor subsystem 660 may have capabilities to detect one or more service discovery events and signals (e.g., rules and alarms) in incoming packets and sufficient memory to store outgoing messages and related schedules such that the low-power co-processor subsystem 660 can assume functions typically performed with components that consume substantially more power (e.g., thehost bridge 640, the interconnect andsystem memory 610, themain application processor 620 configured to execute a high-level operating system, etc.). For example, according to various aspects, the low-power co-processor subsystem 660 may independently inspect incoming packets that are received via the Wi-Fi radio 648, the BT radio 64, the 3G/4G modem 642, etc. according to various dynamically configurable “wake-up” rules such that the low-power co-processor subsystem 660 may handle certain processing tasks that would otherwise be performed using the components in the main wireless application datapath. Furthermore, the low-power co-processor subsystem 660 may selectively engage the components in the main wireless application datapath as needed depending on whether the wake-up rules are triggered (e.g., where the inspected packets have a payload above a threshold level, an external message to wake-up the components in the main wireless application datapath is received, one or more packets include a binary string that matches one or more wake-up rules, etc.). Furthermore, because thewireless device 600 may be expected to respond to service discovery inquiries and exchange ping and/or keep-alive messages with other peer devices in order to preserve connections/associations therewith and thereby maintain constant/stateful operations during standby/idle states, the low-power co-processor subsystem 660 may terminate the sockets for such messaging. Accordingly, offloading various service discovery tasks to the low-power co-processor subsystem 660 may allow the more power-hungry components in the main wireless application datapath to remain in a low-power state (e.g., sleep mode) as much as possible. Similarly, because thewireless device 600 may be expected to announce/advertise services available thereon and publish real-time events and signals with minimum latency in certain use cases (e.g., remote control and remote sensing applications), the low-power co-processor subsystem 660 may act as a proxy for the components in the main wireless application datapath to optimize processing efficiency (e.g., power consumption). Moreover, the low-power co-processor subsystem 660 may be configured to pre-process and/or trap certain commands and timing-critical messages (e.g., synchronization and interrupt look-ups) to expedite or otherwise optimize processing that may eventually be finished at the main application processor (once woken from the low-power state). - According to various aspects,
FIG. 7A andFIG. 7B illustrate exemplary device discovery and service discovery call flows in which aservice provider device 710 and aservice consumer device 720 may exchange various messages to establish an out-of-band D2D connection used to provide anavailable service 714 on theservice provider device 710 to theservice consumer device 720. In general, the following description with respect toFIG. 7A-7B may use certain terminology defined in the Wi-Fi Alliance Peer-to-Peer (P2P) Specification. However, those skilled in the art will appreciate that such description is for illustration purposes only and that the concepts described herein may suitably apply to device discovery and service discovery procedures that are used in other D2D technologies. For example, according to various aspects, theservice provider device 710 may execute anapplication 712 to make theservice 714 on theservice provider device 710 available to one or more peer devices, such asservice consumer device 720. In a similar respect, theservice consumer device 720 may execute anapplication 722 that may request aservice 724, which may correspond to theavailable service 714 on theservice provider device 710. Accordingly, theservice provider device 710 and theservice consumer device 720 may each have a local application service platform (ASP) 716, 726, which may refer to a software service or library that implements various functions needed to establish a session in which theservice consumer device 720 utilizes theavailable service 714 on theservice provider device 710. For example, in various embodiments, the functions implemented via thelocal ASPs service provider device 710 and theservice consumer device 720 may include device discovery, service discovery, session management, connection topology management, and security, among others. - According to various aspects, the call flow shown in
FIG. 7A may generally be performed during a pre-association state where no device discovery and/or service discovery procedures have already been carried out between theservice provider device 710 and theservice consumer device 720. As such, the call flow shown inFIG. 7A may be used to make theservice 714 provided on theservice provider device 710 available to theservice consumer device 720 and establish a direct wireless connection between theservice provider device 710 and theservice consumer device 720 such that theservice consumer device 720 may utilize theservice 714 available on theservice provider device 710. In particular, theASP 716 on theservice provider device 710 may receive an AdvertiseService( ) message from theavailable service 714, wherein the AdvertiseService( ) message may provide information about theservice 714 such that a service seeker on another device (e.g., service consumer device 720) may discover and initiate a session with theASP 716 on theservice provider device 710. For example, in various embodiments, the AdvertiseService( ) message may include parameters to specify a name associated with theservice 714, detailed information about thespecific service 714 that can be used during service discovery (e.g., a service description or service_information parameter), a status parameter to specify whether or not theservice 714 is available for use at the time that theASP 716 calls the AdvertiseService( ) method, any network configuration parameters associated with theservice 714, etc. As such, in response to theapplication 722 on theservice consumer device 722 indicating a request to useservice 724, theservice 724 may send a SeekService( ) message to theASP 726, wherein the SeekService( ) message may provide information that theASP 726 can use to search for services on peer devices (e.g., the service provider device 710). For example, in various embodiments, the SeekService( ) message may include parameters to specify a service name to be searched (e.g., a full service name, a service name prefix, etc.), whether to conduct an exact search in which case theASP 726 may send a hash value corresponding to the service name in a subsequent Probe Request frame (otherwise theASP 726 may send a hash value corresponding to a service domain to search for all peer devices that support any services in the service domain), a network address parameter to indicate whether to limit the search to a device with a specific MAC address or search all peer devices in proximity, and/or an optional service information request parameter to request additional information typically used in a service discovery request/response exchange. - According to various aspects, the
ASP 726 on theservice consumer device 720 may then transmit a P2P Probe Request frame, which may include one or more service hash(es) to indicate the desired service. In response to theASP 716 at theservice provider device 710 detecting the P2P Probe Request frame, theASP 716 may determine whether the service hash(es) included therein match a hash associated with the service 714 (or any other services available on the service provider device 710). Assuming that the service hash(es) in the P2P Probe Request match the hash associated with theservice 714, theASP 716 may then transmit a P2P Probe Response with the name associated with theservice 714 in addition to an advertisement ID that theASP 716 assigns to uniquely identify the advertisement(s) on theservice provider device 710 for manipulation by theservice 724 that requested the advertisement, wherein the advertisement ID may also be used in subsequent messaging to indicate status changes associated with theservice 714, manage connections associated with theservice 714, and/or other events and controls associated with theservice 714. TheASPs ASP 726 may indicate the search result to theservice 724. Theservice 724 may then return a device list to theapplication 722 and a user input may select theservice provider device 710 from the device list. Theservice 724 may then send a ConnectSessions( ) message to theASP 726, which may result in a P2P Provision Discovery Request and P2P Provision Discovery Response exchange between theASPs service provider device 710 confirming the session, theASP 716 may return a success message along with session information to theASP 726 at theservice consumer device 720, which may exchange connection capabilities with theservice provider device 710. At that point, theservice consumer device 720 and theservice provider device 710 may form a P2P group, or theservice consumer device 720 may alternatively join an existing P2P group that theservice provider device 710 previously formed. - Referring now to
FIG. 7B , the call flow shown therein may generally be performed during a post-association state where theservice provider device 710 and theservice consumer device 720 have already formed an existing P2P connection and/or device and service discovery between theservice provider device 710 and theservice consumer device 720 has already been performed. Accordingly, theASP 726 at theservice consumer device 720 may send a Request_Session message to theASP 716 at theservice provider device 710, wherein the Request_Session message may include a session-specific MAC address, a session ID, an advertisement ID, and session information. TheASP 716 may then send a SessionRequest to thelocal service 714, which may present the session information to theapplication 712. In response to the user accepting the session, the service may confirm the session with theASP 716 and indicate a session ready status to theASP 716. TheASP 716 may then respond to theASP 726 at theservice consumer device 720 to indicate the session-specific MAC address and the session ID, which theASP 726 at theservice consumer device 720 may acknowledge. Theservice 714 may then request a port from theASP 716 and indicate the session MAC address, the session ID, an IP address, TCP/IP port number, and service-specific protocol to bind to the port. In response to theASP 716 allowing the port, theASP 716 may indicate the port status to thelocal service 714 and indicate the allowed port information to theASP 726 at theservice consumer device 720. Accordingly, theservice consumer device 720 may perform a similar procedure to bind a port to the service-specific session and indicate the same to theASP 716 at the service provider device. Therespective services service provider device 710 and theservice consumer device 720 may then connect an application socket such that service-specific application data can be exchanged between therespective applications - According to various aspects, referring to the call flows shown in
FIG. 7A-7B and described in further detail above, theservice provider device 710 and/or theservice consumer device 720 may have a hardware architecture that includes a low-power low-bandwidth co-processor subsystem in addition to a high-power high-bandwidth main processing system, in which case various functions performed using thelocal ASP service provider device 710 and/or theservice consumer device 720. For example, as mentioned above, the low-power low-bandwidth co-processor subsystem may have capabilities to detect one or more service discovery events and signals (e.g., rules and alarms) in incoming packets and sufficient memory to store outgoing messages and related schedules such that the low-power low-bandwidth co-processor subsystem can assume functions typically performed with the high-power high-bandwidth main processing system. As such, in various embodiments, the low-power low-bandwidth co-processor subsystem may inspect incoming packets received from the service consumer device 720 (and/or any other peer devices) according to various dynamically configurable “wake-up” rules such that the low-power low-bandwidth co-processor subsystem may independently respond to certain incoming messages and selectively engage the high-power high-bandwidth components in the main processing system as needed depending on whether the wake-up rules are triggered (e.g., where the incoming packets have a sufficiently large payload to indicate that the packets relate to service-specific application data rather than service discovery inquiries, where the incoming packets comprise an explicit signal to wake the components in the main processing system, etc.). Furthermore, because theservice provider device 710 and theservice consumer device 720 may be expected to respond to service discovery inquiries and exchange ping and/or keep-alive messages with one another to preserve the connection/association therebetween (even during standby or idle states), theASPs respective device service provider device 710 and/or theservice consumer device 720 to keep the high-power high-bandwidth components in the main processing system in a low-power state (e.g., sleep mode) as much as possible. Similarly, because theservice provider device 710 and theservice consumer device 720 may be expected to announce/advertise theservices - According to various aspects,
FIG. 8A-8B illustrate an exemplary architecture associated with awireless device 800 that may include a low-power low-bandwidth co-processor subsystem 830 disposed in a wireless application datapath, wherein the low-power low-bandwidth co-processor subsystem 830 may be referred to herein as the “co-processor subsystem” or the like for simplicity. In various embodiments, referring toFIG. 8A andFIG. 8B , thewireless device 800 may include at least onewireless radio 850 that support one or more peer-to-peer (P2P) and/or device-to-device (D2D) technologies (e.g., one or more 802.11 Wi-Fi radios, a Bluetooth radio, a cellular modem that supports LTE-Direct, etc.). As such, the wireless radio(s) 850 may be coupled to a high-power high-bandwidth processing subsystem 810, which may be alternatively referred to herein as the “main wireless processing subsystem” or the like, in addition to theco-processor subsystem 830. In various embodiments, the mainwireless processing subsystem 810 may comprise ahost bridge 822 that couples the wireless radio(s) 850 to an interconnect andsystem memory 824 and a host application processor and high-level operating system 826. Furthermore, theco-processor subsystem 830 may comprise a synchronous host interface coupled to the wireless radio(s) 850 in addition to a local on-chip memory 837 configured to store one or more outgoing data packets associated with one or more service discovery tasks offloaded from the mainwireless processing subsystem 810 and related schedules to send the one or more outgoing data packets. Furthermore, theco-processor subsystem 830 may include a packet acquisition (application data mover)module 833 that may be configured to move the outgoing data packets for transmission via the wireless radio(s) 850 according to the corresponding schedule(s) and further to move incoming data packets that are received via the wireless radio(s) 850 to the on-chip memory 837. - According to various embodiments, the
co-processor subsystem 830 may further comprise a programmable deep-packet inspection (DPI)module 835 configured with one or more dynamic rules to pre-process the incoming data packets that are received via the wireless radio(s) 850, wherein the one or more dynamic rules may be based (at least in part) on a service description associated with one or more service discovery protocols that correspond to one or more services to provide or consume at thewireless device 800. In addition, criteria specified in the one or more dynamic rules may relate to one or more parameters or other information that relates to operating conditions or states associated with thewireless device 800. For example, in various embodiments, the dynamic rules may specify criteria that relate to a battery health state, a battery charge state, synchronization accuracy between timing associated with one or more services provided and/or consumed at thewireless device 800 and a master clock on thewireless device 800, available CPU capacity, available memory reserves, bandwidth requirements, latency requirements, etc. As such, the dynamic rules may generally specify one or more conditions under which to wake one or more component(s) in the mainwireless processing subsystem 810 or otherwise invoke processing in the mainwireless processing subsystem 810 according to the particular semantics used in the service descriptions associated with the one or more services provided and/or consumed at thewireless device 800. Moreover, in various embodiments, the dynamic rules may optionally further specify the conditions under which to wake one or more component(s) in the mainwireless processing subsystem 810 or otherwise invoke processing in the mainwireless processing subsystem 810 according to operating conditions or current states on with thewireless device 800. - In that sense, the
co-processor subsystem 830 may be configured to transmit scheduled outgoing messages to publish/advertise requirements associated with one or more services provided on thewireless device 800 and/or one or more desired services to be consumed at the wireless device 800 (e.g., whether thewireless device 800, a service consumer peer device, and/or a service provider peer device has speaker(s) or merely display capabilities, whether the provided services and/or the desired services require the service consumer peer device and/or service provider peer device to report ambient temperature, etc.). Accordingly, theco-processor subsystem 830 may be further configured to inspect any incoming data packets to determine whether any service requirements and/or device capabilities specified therein match the one or more available services provided on thewireless device 800 and/or the one or more desired services to be consumed at thewireless device 800, whereby theco-processor subsystem 830 may only awaken or otherwise engage one or more component(s) in the mainwireless processing subsystem 810 when one or more incoming packets received from a peer device specify service requirements and/or device capabilities that match an available service provided on thewireless device 800 and/or a desired service to be consumed at thewireless device 800, depending on the service-specific use case(s) and the particular semantics used in the service description(s) associated with the service-specific use case(s). - Accordingly, in various embodiments, the
programmable DPI module 835 may initially pre-process the incoming data packets, which may comprise inspecting headers, data parts, or other suitable contents associated with the incoming data packets to collect statistical information (e.g., payload size) and/or determine whether the one or more dynamic rules to invoke processing in the mainwireless processing subsystem 810 have been triggered. For example, in various embodiments, theprogrammable DPI module 835 may determine whether the pre-processed data packets include an “ok-to-sleep” command, in which case theprogrammable DPI module 835 may notify one or more components in the mainwireless processing subsystem 810 that transitioning to a lower power state is permitted (e.g., from an idle/standby to a sleep/dormant state, from the sleep/dormant state to a deep sleep/hibernate state, etc.). In other examples, where the pre-processed data packets include a “no-sleep” command (e.g., an explicit wake signal), theprogrammable DPI module 835 may notify the components in the mainwireless processing subsystem 810 to transition to an active state and move any buffered data to a memory associated with thehost application processor 826. In still other examples, if the pre-processed data packets have a payload size above a threshold value such that a buffer associated with the low-power co-processor 839 would become full if stored therein, theprogrammable DPI module 835 may engage the components in the mainwireless processing subsystem 810 and move the buffered data to the memory associated with thehost application processor 826, as the buffered data would exceed the available processing capacity within theco-processor subsystem 830. Furthermore, as noted above, theprogrammable DPI module 835 may perform pattern matching to compare one or more service requirements, capabilities, and/or other suitable information conveyed in the pre-processed data packets to the one or more dynamic rules and engage one or more components in the mainwireless processing subsystem 810 in response to matching the information conveyed in the pre-processed data packets to any service-specific conditions that require processing in the mainwireless processing subsystem 810. Otherwise, in response to the pre-processed data packets passing all the filters implemented at theprogrammable DPI module 835, the pre-processed ata packets may be stored in the buffer associated with the low-power co-processor 839, which may then further process the incoming data packets. - More particularly, after the appropriate pre-processing has been performed at the
programmable DPI module 835, the low-power co-processor 839 may further process the incoming data packets to handle any service discovery tasks that were offloaded from the mainwireless processing subsystem 810. For example, the offloaded service discovery tasks may comprise responding to the incoming data packets without invoking processing in the mainwireless processing subsystem 810 where the criteria associated with the incoming data packets do not trigger the one or more dynamic rules and sending the outgoing messages (e.g., service announcements, advertisements, status changes, etc.). Furthermore, processing in the mainwireless processing subsystem 810 may be invoked in response to the criteria associated with the incoming data packets meeting the one or more dynamic rules. However, whereas the pattern matching performed at theprogrammable DPI module 835 may generally comprise comparing strings from individual packets to the service-specific dynamic rules, the low-power co-processor 839 may perform pattern matching that involves more complex multi-string matching. Accordingly, the low-power co-processor 839 may consider one or more parameters or other information that relates to operating conditions or states associated with thewireless device 800 in combination with service-specific requirements and/or device capabilities to determine whether any dynamic rules that require processing in the mainwireless processing system 810 have been triggered. For example, theco-processor 839 may respond to incoming data packets that comprise service discovery inquiries about available services provided on thewireless device 800 and/or desired services to be consumed at thewireless device 800 without waking the components in the mainwireless processing subsystem 810. However, theco-processor 839 may engage the components in the mainwireless processing subsystem 810 where the incoming data packets have a payload size that exceeds a particular service-specific threshold (e.g., a payload size associated with service-specific application data, whereas service discovery inquiries and other similar messages may typically have a relatively small payload size). Alternatively, theco-processor 839 may engage the components in the mainwireless processing subsystem 810 in the event that the incoming data packets specify one or more service requirements and/or device capabilities that match the available services provided on thewireless device 800 and/or the desired services to be consumed at thewireless device 800 to request appropriate assistance that may be needed to establish the service-specific session (e.g., binding ports, establishing sockets, etc.). - Furthermore, as noted above, the dynamic rules may specify one or more service-specific search strings to define conditions that may require processing at the components in the main
wireless processing subsystem 810, wherein the co-processor 839 may engage the components in the mainwireless processing subsystem 810 in response to detecting one or more matching strings that indicate a need to utilize the higher power, higher bandwidth processing capabilities available therein. For example, in a service-specific screen sharing use case, the bandwidth needed to achieve sufficient screen sharing performance may depend on screen size, resolution, and/or other relevant parameters. In particular, in a VGA screen sharing use case, where the resolution is approximately 640×480 pixels, little bandwidth may be needed, whereas Ultra HD 4K resolution at 3840×2160 lines requires large bandwidth. As such, the dynamic rules in screen sharing use cases may depend on the frames per second processing resources available at thewireless device 800 and/or any peer devices involved in the screen sharing, in that Ultra HD 4K screen sharing may generally require a wall-plugged power source. In that sense, the service-specific dynamic rules may require that peer endpoints exchange information relating to available power sources and capabilities to display data at the necessary frames per second, whereby the components in the mainwireless processing subsystem 810 may be invoked in the event that the incoming data packets indicate that theco-processor subsystem 830 cannot meet the demanded performance. In another example use case, resolving audio in stereo may require relatively little throughput, as the more important issue instead pertains to maintaining synchronization between left and right channels. As such, in a use case where thewireless device 800 is streaming stereo audio to another peer device, the dynamic rules may specify that the components in the mainwireless processing subsystem 810 should be invoked if the peer device indicates that synchronization has been lost between the left and right channels. Similarly, where thewireless device 800 is receiving stereo audio streamed from a peer device, the dynamic rules may specify that the components in the mainwireless processing subsystem 810 should be invoked if thewireless device 800 determines that synchronization has been lost between the left and right channels. - As such, in these and other service-specific use cases, the dynamic rules may define one or more search strings (e.g., binary search strings) to compare against parameters carried in protocol-specific and service-specific messages, wherein the components in the main
wireless processing subsystem 810 may be invoked in response to the protocol-specific and service-specific messages including criteria that matches the search strings defined in the one or more dynamic rules. Otherwise, processing may continue to be offloaded to theco-processor subsystem 830. Furthermore, in the event that the components in the mainwireless processing subsystem 810 may be invoked, the dynamic rules may be redefined or otherwise tuned in response to a determination that the components in the mainwireless processing subsystem 810 were not required to achieve the necessary performance demands and thereby increase the time that the components in the mainwireless processing subsystem 810 can remain in a low-power state. - With specific reference to
FIG. 8A , the architecture illustrated therein may operate theco-processor subsystem 830 in a look-aside mode. More particularly, in the look-aside mode, outgoing messages that relate to service announcements, service advertisements, service status changes, service inquiries, and responses to certain incoming messages (e.g., incoming service inquiries) may be buffered in the on-chip memory 837. Thepacket acquisition module 833 may then move the outgoing messages from the on-chip memory 837 to thesynchronous host interface 831 according to any applicable schedules related thereto (e.g., one or more schedules that define when to publish service announcements, service advertisements, service status changes, inquiries about desired services, etc.). Thesynchronous host interface 831 may then cause the outgoing messages to be transmitted via the wireless radio(s) 850, whereby the outgoing messages may be transmitted via anoutgoing data path 842 that bypasses the mainwireless processing subsystem 810 altogether. Furthermore, in the look-aside mode, incoming data packets may be received at theco-processor subsystem 830 via anincoming data path 844 that likewise bypasses the mainwireless processing subsystem 810. For example, theincoming data path 844 may pass through the wireless radio(s) 850 to thesynchronous host interface 831, and thepacket acquisition module 833 may then move the incoming packets to a receive queue on the on-chip memory 837. Theprogrammable DPI module 835 may then perform the above-mentioned pre-processing tasks on the incoming data packets stored in the receive queue and selectively engage thehost bridge 822 to either further optimize power consumption or wake one or more components in the mainwireless processing subsystem 810 depending on whether or not any incoming data packets do not pass the filters implemented therein - According to various aspects, in the event that the incoming data packet passes the filters implemented in the
programmable DPI module 835, the pre-processed incoming data packets may be provided to theco-processor 839, which may further process the incoming data packets against the one or more dynamic rules using a local decision engine, as discussed in further detail above. As such, where the co-processor 839 further determines that the incoming data packets do not trigger any dynamic rules that define conditions under which to engage the component(s) in the mainwireless processing subsystem 810, theco-processor 839 may appropriately process the incoming data packets without utilizing any component(s) in the main wireless processing subsystem 810 (e.g., responding to service inquiries, distributing incoming data to service provider and/or service consumer entities on thewireless device 800, etc.). Alternatively, where the incoming data packets trigger one or more dynamic rules, theco-processor subsystem 830 may wake or otherwise engage one or more components in the mainwireless processing subsystem 810 to invoke the processing capabilities associated therewith. However, because the incoming data packets have already been pre-processed at theco-processor subsystem 830, any processing invoked in the mainwireless processing subsystem 810 may be expedited or otherwise optimized in that the pre-processing may trap certain commands and/or other suitable messages to ensure that incoming data packets relating to synchronization, interrupt look-ups, or other suitable tasks having timing-critical aspects are processed with minimal latency. Furthermore, according to various aspects, the components that are invoked in the mainwireless processing subsystem 810 may determine whether or not the processing capabilities in the mainwireless processing system 810 were actually necessary to deal with the conditions that resulted in the wakeup, whereby the dynamic rules may be redefined or otherwise tuned based on platform and the service-specific use-case context(s) in the event that the components in the mainwireless processing subsystem 810 were not required to achieve the necessary performance demands. As such, the dynamic rules may be redefined or otherwise tuned to prevent subsequent unnecessary wakeups, which may therefore not occur if the same conditions arise such that the components in the mainwireless processing subsystem 810 can spend more time in the low-power state(s). - According to various aspects, with specific reference to
FIG. 8B , the architecture illustrated therein may operate theco-processor subsystem 830 in a bump-in-the-wire mode, which may alternatively be referred to as a bump-in-the-stack or flow-through mode. More particularly, in the bump-in-the-wire mode, one or more outgoing messages may be stored in the interconnect andsystem memory 824 in the mainwireless processing subsystem 810 and then pass through to the on-chip memory 837 and theprogrammable DPI module 835 before returning to the interconnect andsystem memory 824. The outgoing messages may then be transferred to thehost bridge 822 and transmitted over a wireless network via the one or morewireless radios 850. In that sense, theprogrammable DPI module 835 may analyze the outgoing messages based on the dynamic rules and service-specific requirements and device capabilities to determine whether any outgoing messages need to be prioritized over other outgoing messages (e.g., prioritizing service-specific application data over device discovery inquiries, service discovery announcements/inquiries, etc.). Accordingly, in the bump-in-the-wire mode, theco-processor subsystem 830 may be utilized to classify outgoing packets according to service-specific flows (e.g., a source IP address and port, a destination IP address and port, service-specific protocols, etc.) and optimize outgoing transmissions to meet quality of service (QoS) and/or quality of experience (QoE) requirements, improve delivery through congestion points, or otherwise queue and shape the outgoing traffic to meet service-specific performance demands and optimize power consumption on thewireless device 800. As such, in the bump-in-the-wire mode, the outgoing messages may travel via anoutgoing data path 842 that partially traverses the mainwireless processing subsystem 810 and theco-processor subsystem 830. - According to various aspects, in the bump-in-the-wire mode, the
incoming data path 844 may likewise traverse thehost bridge 822 and the interconnect andsystem memory 824 and then flow through the on-chip memory 837 and theprogrammable DPI module 835 before returning to the interconnect andsystem memory 724. As such, theprogrammable DPI module 835 may perform substantially similar pre-processing tasks on the incoming data packets as described above with respect to the look-aside mode except that the incoming data packets may be received via the higher-bandwidth host bridge 822 and interconnect andsystem memory 824. The bump-in-the-wire mode may therefore offer similar benefits as the look-aside mode in that thehost application processor 826 can remain in a low-power state except that the bump-in-the-wire mode may offer greater performance at the cost of utilizing at least some high-power high-bandwidth components in the mainwireless processing subsystem 810. Accordingly, in various embodiments, the bump-in-the-wire mode may be better suited to service-specific use cases that have greater performance demands (e.g., theco-processor subsystem 830 may operate in the look-aside mode to handle simple file transfers or services that involve streaming low resolution VGA video, whereas the bump-in-the-wire mode may be utilized to handle sessions that involve services to stream high resolution HD video). - According to various aspects,
FIG. 9 illustrates anexemplary method 900 that a low-power low-bandwidth co-processor subsystem disposed in a wireless application datapath may perform to optimize service discovery power consumption in a wireless service platform. More particularly, atblock 910, one or more components in a main wireless processing subsystem may enter a sleep state or another suitable low-power state and the co-processor subsystem may be configured to operate in either a look-aside mode or a bump-in-the-wire mode to offload one or more service discovery tasks from the components in the main wireless processing subsystem that entered the low-power state. For example, in the look-aside mode, the components that enter the low-power state may comprise a host bridge, a main interconnect and system memory, and a host application processor configured to run a high-level operating system. Alternatively, in the bump-in-the-wire mode, the host bridge and the main interconnect and system memory may remain active and only the host application processor enters the low-power state. Accordingly, in various embodiments, the particular mode in which to operate the co-processor subsystem may be selected atblock 910 based on the current operating conditions or states associated on a wireless device and any service-specific requirements and device capabilities. For example, if the wireless device has a low battery charge state and does not have a wall-plugged power source, the co-processor subsystem may be operated in the look-aside mode to conserve more power. In another example, if the wireless device is actively providing and/or consuming a service that has substantial performance demands and the battery charge state is above a threshold level and/or a wall-plugged power source is available, the co-processor subsystem may operate in the bump-in-the-wire to optimize performance. - In various embodiments, once the components in the main wireless processing subsystem enter the low-power state, deep packet inspection (DPI) may be turned on within the co-processor subsystem and one or more service-specific wake-up rules may be retrieved at
block 915. For example, as discussed in further detail above, the service-specific wake-up rules may generally specify one or more conditions under which to wake one or more component(s) in the main wireless processing subsystem or under which to otherwise invoke processing in the main wireless processing subsystem, which may be expressed according to the particular semantics used in the service descriptions associated with one or more services provided and/or consumed at the wireless device. Moreover, in various embodiments, the service-specific wake-up rules may optionally further specify the conditions under which to wake one or more component(s) in the main wireless processing subsystem or otherwise invoke processing in the main wireless processing subsystem according to operating conditions or current states on with the wireless device. - In various embodiments, at
block 920, the co-processor subsystem may then determine whether any incoming packets have been received, in which case the incoming packets may be pre-pre-processed according to the service-specific wake-up rules and one or more parameters or other information that relate to the operating conditions and/or current state(s) associated with the wireless device. The co-processor subsystem may then determine whether one or more wake-up rules have been triggered atblock 930, in which case the main application processor may be woken from the low-power state and DPI may be disabled atblock 935. Furthermore, in the event that the co-processor subsystem was configured to operate in the bump-in-the-wire mode, the host bridge and system interconnect and memory may be further woken from the low-power state. In various embodiments, any buffered data associated with the incoming packets and any buffered data associated with outgoing messages that are pending transmission may then be moved to a memory associated with the main application processor atblock 940 and the main wireless processing subsystem may resume performing the service discovery tasks that would otherwise have been offloaded to the co-processor subsystem. - According to various embodiments, in response to the co-processor subsystem determining that the pre-processed incoming data packets did not trigger any service-specific wake-up rules at
block 930, the components in the main wireless processing subsystem that entered the low-power state may remain in such a low-power state, as the co-processor subsystem may process/respond to the incoming packets atblock 945 without utilizing the main wireless processing subsystem. Furthermore, in various embodiments, the co-processor subsystem may transmit any scheduled outgoing data packets atblock 950. For example, in various embodiments, the scheduled outgoing data packets may comprise service announcements, service advertisements, service status changes, responses to service discovery inquiries, inquiries about services desired at the wireless device, etc. Furthermore, returning to block 920, the co-processor subsystem may proceed directly to block 950 to transmit the scheduled outgoing data packets in response to determining that no incoming packets have been received or a receive queue is otherwise empty. - According to various aspects,
FIG. 10 illustrates anexemplary method 1000 that may be performed at the main application processor disposed in a main wireless application datapath to optimize service discovery power consumption in a wireless service platform having a low-power low-bandwidth co-processor subsystem. More particularly, in various embodiments, themethod 1000 shown inFIG. 10 may generally be carried out in response to a wake command received at one or more components in the main wireless application datapath, for example, because one or more incoming data packets triggered a service-specific wake-up rule as described in further detail above. As such, any buffered data relating to incoming data packets and/or outgoing messages pending transmission may then be processed atblock 1015. In various embodiments, atblock 1020, the main application processor may then determine whether the wake-up was actually necessary. For example, the wake-up may be deemed unnecessary in response to a determination that the co-processor subsystem could have suitably processed the incoming data packets that triggered the wake-up without compromising any power or other performance demands associated with one or more provided and/or consumed services to which the incoming data packets pertain. As such, in response to determining that the wake-up was unnecessary, the service-specific wake-up rules that resulted in the unnecessary wake-up may be tuned or otherwise adjusted atblock 1025 such that subsequent unnecessary wakeups may not occur if the same conditions arise. The components in the main wireless application datapath may then determine whether conditions are such that the components in the main wireless application datapath can re-enter the sleep state atblock 1030, in which case the sleep state may be resumed until a subsequent wake command is received atblock 1010. Otherwise, if the wake-up was necessary and/or conditions are such that the processing capabilities associated with the main wireless application datapath are still needed, the wireless device may continue to utilize the components in the main wireless application datapath to process/respond to incoming data packets and transmit scheduled outgoing data packets until suitable conditions to enter a low-power state arise. - Those skilled in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, computer-executable instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
- Further, those skilled in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations thereof. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted to depart from the scope of the present disclosure.
- The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).
- The methods, sequences and/or algorithms described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination thereof. A software module may reside in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a wireless device (e.g., an IoT device). In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.
- In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as computer-executable instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of computer-executable instructions or data structures accessible by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes CD, laser disc, optical disc, DVD, floppy disk and Blu-ray disc where disks usually reproduce data magnetically and/or optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.
- While the foregoing disclosure shows illustrative aspects of the disclosure, those skilled in the art will appreciate that various changes and modifications could be made herein without departing from the scope of the disclosure as defined by the appended claims. The functions, steps and/or actions of the method claims in accordance with the aspects of the disclosure described herein need not be performed in any particular order. Furthermore, although elements of the disclosure may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.
Claims (30)
Priority Applications (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/850,793 US9591582B1 (en) | 2015-09-10 | 2015-09-10 | Smart co-processor for optimizing service discovery power consumption in wireless service platforms |
CN201680052595.2A CN108029078A (en) | 2015-09-10 | 2016-08-15 | For optimizing the intelligent coordinated processor of the service discovery power consumption in wireless service platform |
JP2018512390A JP2018532312A (en) | 2015-09-10 | 2016-08-15 | A smart coprocessor for optimizing service discovery power consumption in wireless service platforms |
EP16758013.3A EP3348097A1 (en) | 2015-09-10 | 2016-08-15 | Smart co-processor for optimizing service discovery power consumption in wireless service platforms |
PCT/US2016/046959 WO2017044253A1 (en) | 2015-09-10 | 2016-08-15 | Smart co-processor for optimizing service discovery power consumption in wireless service platforms |
KR1020187009801A KR20180050389A (en) | 2015-09-10 | 2016-08-15 | A smart co-processor for optimizing service discovery power consumption in wireless service platforms |
TW105129054A TW201713137A (en) | 2015-09-10 | 2016-09-08 | Smart co-processor for optimizing service discovery power consumption in wireless service platforms |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/850,793 US9591582B1 (en) | 2015-09-10 | 2015-09-10 | Smart co-processor for optimizing service discovery power consumption in wireless service platforms |
Publications (2)
Publication Number | Publication Date |
---|---|
US9591582B1 US9591582B1 (en) | 2017-03-07 |
US20170078961A1 true US20170078961A1 (en) | 2017-03-16 |
Family
ID=56843020
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/850,793 Active US9591582B1 (en) | 2015-09-10 | 2015-09-10 | Smart co-processor for optimizing service discovery power consumption in wireless service platforms |
Country Status (7)
Country | Link |
---|---|
US (1) | US9591582B1 (en) |
EP (1) | EP3348097A1 (en) |
JP (1) | JP2018532312A (en) |
KR (1) | KR20180050389A (en) |
CN (1) | CN108029078A (en) |
TW (1) | TW201713137A (en) |
WO (1) | WO2017044253A1 (en) |
Cited By (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200336439A1 (en) * | 2019-04-19 | 2020-10-22 | Marvell Asia Pte, Ltd. | Control of ethernet link-partner gpio using oam |
US20210167977A1 (en) * | 2016-08-02 | 2021-06-03 | Samsung Electronics Co., Ltd. | Electronic device and power control method of electronic device |
US11140218B2 (en) | 2019-10-30 | 2021-10-05 | Vmware, Inc. | Distributed service chain across multiple clouds |
US11153406B2 (en) | 2020-01-20 | 2021-10-19 | Vmware, Inc. | Method of network performance visualization of service function chains |
US11194610B2 (en) | 2019-02-22 | 2021-12-07 | Vmware, Inc. | Service rule processing and path selection at the source |
US11212356B2 (en) | 2020-04-06 | 2021-12-28 | Vmware, Inc. | Providing services at the edge of a network using selected virtual tunnel interfaces |
US11223494B2 (en) * | 2020-01-13 | 2022-01-11 | Vmware, Inc. | Service insertion for multicast traffic at boundary |
JP2022504859A (en) * | 2018-11-01 | 2022-01-13 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | Application processor wake-up methods and devices applied to mobile terminals |
US11265187B2 (en) | 2018-01-26 | 2022-03-01 | Nicira, Inc. | Specifying and utilizing paths through a network |
US11283717B2 (en) | 2019-10-30 | 2022-03-22 | Vmware, Inc. | Distributed fault tolerant service chain |
US11296930B2 (en) | 2014-09-30 | 2022-04-05 | Nicira, Inc. | Tunnel-enabled elastic service model |
US11405431B2 (en) | 2015-04-03 | 2022-08-02 | Nicira, Inc. | Method, apparatus, and system for implementing a content switch |
US11438267B2 (en) | 2013-05-09 | 2022-09-06 | Nicira, Inc. | Method and system for service switching using service tags |
US11595250B2 (en) | 2018-09-02 | 2023-02-28 | Vmware, Inc. | Service insertion at logical network gateway |
US11611625B2 (en) | 2020-12-15 | 2023-03-21 | Vmware, Inc. | Providing stateful services in a scalable manner for machines executing on host computers |
US11659061B2 (en) | 2020-01-20 | 2023-05-23 | Vmware, Inc. | Method of adjusting service function chains to improve network performance |
US11722367B2 (en) | 2014-09-30 | 2023-08-08 | Nicira, Inc. | Method and apparatus for providing a service with a plurality of service nodes |
US11734043B2 (en) | 2020-12-15 | 2023-08-22 | Vmware, Inc. | Providing stateful services in a scalable manner for machines executing on host computers |
US11750476B2 (en) | 2017-10-29 | 2023-09-05 | Nicira, Inc. | Service operation chaining |
US11805036B2 (en) | 2018-03-27 | 2023-10-31 | Nicira, Inc. | Detecting failure of layer 2 service using broadcast messages |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104734826B (en) * | 2013-12-20 | 2020-08-11 | 中兴通讯股份有限公司 | Ultra-large bandwidth data sending control method and ultra-large bandwidth data sending equipment |
JP6524912B2 (en) * | 2013-12-26 | 2019-06-05 | 日本電気株式会社 | Communication terminal connection control method |
JP6376109B2 (en) * | 2015-11-19 | 2018-08-22 | 京セラドキュメントソリューションズ株式会社 | Information processing apparatus and program |
US10299310B2 (en) * | 2016-02-02 | 2019-05-21 | Lg Electronics Inc. | Wireless device including first platform for local area and second platform for remote area and method for wireless device |
KR20170098576A (en) * | 2016-02-22 | 2017-08-30 | 삼성전자주식회사 | Electronic device and method for processing data in electronic device |
US10873637B2 (en) * | 2016-05-02 | 2020-12-22 | Microsoft Technology Licensing, Llc | Controlling service discovery and activation among peers |
JP6992258B2 (en) * | 2017-02-21 | 2022-01-13 | ブラザー工業株式会社 | Computer programs for communication and terminal equipment |
US10459517B2 (en) * | 2017-03-31 | 2019-10-29 | Qualcomm Incorporated | System and methods for scheduling software tasks based on central processing unit power characteristics |
MX2020003738A (en) * | 2017-09-26 | 2020-08-03 | Guangdong Oppo Mobile Telecommunications Corp Ltd | Data processing method and terminal device. |
CN109600720B (en) * | 2017-09-30 | 2021-10-08 | 成都鼎桥通信技术有限公司 | Multicast data processing method and device |
US10412671B2 (en) * | 2017-12-14 | 2019-09-10 | Nokia Technologies Oy | Proxy service and power savings in wireless device |
EP3837809A1 (en) * | 2018-08-14 | 2021-06-23 | Nokia Solutions and Networks Oy | Mutual 3gpp-tsn qos adaption and shaping |
KR20200056548A (en) * | 2018-11-14 | 2020-05-25 | 에스케이하이닉스 주식회사 | Memory system having cache system and method of controlling caching operation in the memory system |
US10944801B1 (en) * | 2019-02-25 | 2021-03-09 | Amazon Technologies, Inc. | Serverless signaling in peer-to-peer session initialization |
US11005894B2 (en) * | 2019-04-11 | 2021-05-11 | Netapp, Inc. | Methods for demultiplexing services over ports and devices thereof |
US11074184B2 (en) * | 2019-04-15 | 2021-07-27 | International Business Machines Corporation | Maintaining data order between buffers |
US11184833B2 (en) * | 2019-06-19 | 2021-11-23 | Citrix Systems, Inc. | Bandwidth sharing amongst trusted peers |
US11133698B2 (en) | 2019-09-01 | 2021-09-28 | Wen Cai | Wireless charging systems and methods for controlling the same |
US11416435B2 (en) | 2019-09-03 | 2022-08-16 | Pensando Systems Inc. | Flexible datapath offload chaining |
CN112995108B (en) * | 2019-12-17 | 2023-03-10 | 恒为科技(上海)股份有限公司 | Network data recovery system |
CN111918338B (en) * | 2020-08-12 | 2023-04-18 | 深圳蓝奥声科技有限公司 | Wireless cooperative agent method, device and network system |
US11803493B2 (en) * | 2020-11-30 | 2023-10-31 | Dell Products L.P. | Systems and methods for management controller co-processor host to variable subsystem proxy |
US20220004354A1 (en) * | 2021-09-22 | 2022-01-06 | Intel Corporation | Audio stack power control based on latency |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7038687B2 (en) | 2003-06-30 | 2006-05-02 | Intel Corporation | System and method for high-speed communications between an application processor and coprocessor |
US7809386B2 (en) | 2005-06-29 | 2010-10-05 | Nokia Corporation | Local network proxy for a remotely connected mobile device operating in reduced power mode |
WO2007081218A1 (en) | 2006-01-10 | 2007-07-19 | Cupp Computing As | Dual mode power-saving computing system |
EP2263137A1 (en) | 2008-04-07 | 2010-12-22 | ST-Ericsson SA | Mobile phone with low-power media rendering sub-system |
US8498229B2 (en) | 2008-12-30 | 2013-07-30 | Intel Corporation | Reduced power state network processing |
US8335937B2 (en) * | 2009-12-24 | 2012-12-18 | Intel Corporation | Method and system for discoverability of power saving P2P devices |
CN102685786B (en) * | 2011-03-18 | 2017-05-03 | 中兴通讯股份有限公司 | Method and system for accessing wireless sensor network (WSN) to telecommunication network |
WO2013035999A1 (en) * | 2011-08-26 | 2013-03-14 | 엘지전자 주식회사 | Method and device for discovering neighbors for wireless fidelity direct (wfd) peer to peer (p2p) communication |
EP2862377B1 (en) * | 2012-06-19 | 2016-04-06 | Telefonaktiebolaget LM Ericsson (publ) | Method and arrangement for d2d discovery |
US9049578B2 (en) * | 2012-10-24 | 2015-06-02 | Qualcomm Incorporated | Profile based discovery engine configurations for neighborhood aware wi-fi networks |
US9329667B2 (en) | 2012-11-21 | 2016-05-03 | Completecover, Llc | Computing device employing a proxy processor to learn received patterns |
US9107164B1 (en) | 2013-03-08 | 2015-08-11 | Amazon Technologies, Inc. | Wake on one-to-many communication |
CN104754691B (en) | 2013-12-26 | 2018-08-07 | 电信科学技术研究院 | A kind of method and apparatus sending message |
US10091625B2 (en) * | 2014-09-25 | 2018-10-02 | Intel Corporation | Systems and methods for establishing a personal basic service set (PBSS) over a wireless network to facilitate peer-to-peer group communication |
-
2015
- 2015-09-10 US US14/850,793 patent/US9591582B1/en active Active
-
2016
- 2016-08-15 WO PCT/US2016/046959 patent/WO2017044253A1/en active Application Filing
- 2016-08-15 KR KR1020187009801A patent/KR20180050389A/en unknown
- 2016-08-15 CN CN201680052595.2A patent/CN108029078A/en active Pending
- 2016-08-15 JP JP2018512390A patent/JP2018532312A/en active Pending
- 2016-08-15 EP EP16758013.3A patent/EP3348097A1/en not_active Withdrawn
- 2016-09-08 TW TW105129054A patent/TW201713137A/en unknown
Cited By (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11438267B2 (en) | 2013-05-09 | 2022-09-06 | Nicira, Inc. | Method and system for service switching using service tags |
US11805056B2 (en) | 2013-05-09 | 2023-10-31 | Nicira, Inc. | Method and system for service switching using service tags |
US11296930B2 (en) | 2014-09-30 | 2022-04-05 | Nicira, Inc. | Tunnel-enabled elastic service model |
US11496606B2 (en) | 2014-09-30 | 2022-11-08 | Nicira, Inc. | Sticky service sessions in a datacenter |
US11722367B2 (en) | 2014-09-30 | 2023-08-08 | Nicira, Inc. | Method and apparatus for providing a service with a plurality of service nodes |
US11405431B2 (en) | 2015-04-03 | 2022-08-02 | Nicira, Inc. | Method, apparatus, and system for implementing a content switch |
US20210167977A1 (en) * | 2016-08-02 | 2021-06-03 | Samsung Electronics Co., Ltd. | Electronic device and power control method of electronic device |
US11743060B2 (en) * | 2016-08-02 | 2023-08-29 | Samsung Electronics Co., Ltd. | Electronic device and power control method of electronic device |
US11750476B2 (en) | 2017-10-29 | 2023-09-05 | Nicira, Inc. | Service operation chaining |
US11265187B2 (en) | 2018-01-26 | 2022-03-01 | Nicira, Inc. | Specifying and utilizing paths through a network |
US11805036B2 (en) | 2018-03-27 | 2023-10-31 | Nicira, Inc. | Detecting failure of layer 2 service using broadcast messages |
US11595250B2 (en) | 2018-09-02 | 2023-02-28 | Vmware, Inc. | Service insertion at logical network gateway |
JP2022504859A (en) * | 2018-11-01 | 2022-01-13 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | Application processor wake-up methods and devices applied to mobile terminals |
JP7207838B2 (en) | 2018-11-01 | 2023-01-18 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | Application processor wake-up method applied to mobile terminal, mobile terminal and computer program |
US11907041B2 (en) | 2018-11-01 | 2024-02-20 | Huawei Technologies Co., Ltd. | Application processor wakeup method and apparatus applied to mobile terminal |
US11249784B2 (en) | 2019-02-22 | 2022-02-15 | Vmware, Inc. | Specifying service chains |
US11301281B2 (en) | 2019-02-22 | 2022-04-12 | Vmware, Inc. | Service control plane messaging in service data plane |
US11354148B2 (en) | 2019-02-22 | 2022-06-07 | Vmware, Inc. | Using service data plane for service control plane messaging |
US11360796B2 (en) | 2019-02-22 | 2022-06-14 | Vmware, Inc. | Distributed forwarding for performing service chain operations |
US11321113B2 (en) | 2019-02-22 | 2022-05-03 | Vmware, Inc. | Creating and distributing service chain descriptions |
US11397604B2 (en) | 2019-02-22 | 2022-07-26 | Vmware, Inc. | Service path selection in load balanced manner |
US11288088B2 (en) | 2019-02-22 | 2022-03-29 | Vmware, Inc. | Service control plane messaging in service data plane |
US11604666B2 (en) | 2019-02-22 | 2023-03-14 | Vmware, Inc. | Service path generation in load balanced manner |
US11194610B2 (en) | 2019-02-22 | 2021-12-07 | Vmware, Inc. | Service rule processing and path selection at the source |
US11467861B2 (en) | 2019-02-22 | 2022-10-11 | Vmware, Inc. | Configuring distributed forwarding for performing service chain operations |
US11294703B2 (en) | 2019-02-22 | 2022-04-05 | Vmware, Inc. | Providing services by using service insertion and service transport layers |
US11609781B2 (en) | 2019-02-22 | 2023-03-21 | Vmware, Inc. | Providing services with guest VM mobility |
US20200336439A1 (en) * | 2019-04-19 | 2020-10-22 | Marvell Asia Pte, Ltd. | Control of ethernet link-partner gpio using oam |
US11863468B2 (en) * | 2019-04-19 | 2024-01-02 | Marvell Asia Pte Ltd | Control of ethernet link-partner GPIO using OAM |
US11283717B2 (en) | 2019-10-30 | 2022-03-22 | Vmware, Inc. | Distributed fault tolerant service chain |
US11140218B2 (en) | 2019-10-30 | 2021-10-05 | Vmware, Inc. | Distributed service chain across multiple clouds |
US11722559B2 (en) | 2019-10-30 | 2023-08-08 | Vmware, Inc. | Distributed service chain across multiple clouds |
US11223494B2 (en) * | 2020-01-13 | 2022-01-11 | Vmware, Inc. | Service insertion for multicast traffic at boundary |
US11659061B2 (en) | 2020-01-20 | 2023-05-23 | Vmware, Inc. | Method of adjusting service function chains to improve network performance |
US11153406B2 (en) | 2020-01-20 | 2021-10-19 | Vmware, Inc. | Method of network performance visualization of service function chains |
US11743172B2 (en) | 2020-04-06 | 2023-08-29 | Vmware, Inc. | Using multiple transport mechanisms to provide services at the edge of a network |
US11528219B2 (en) | 2020-04-06 | 2022-12-13 | Vmware, Inc. | Using applied-to field to identify connection-tracking records for different interfaces |
US11368387B2 (en) | 2020-04-06 | 2022-06-21 | Vmware, Inc. | Using router as service node through logical service plane |
US11277331B2 (en) | 2020-04-06 | 2022-03-15 | Vmware, Inc. | Updating connection-tracking records at a network edge using flow programming |
US11792112B2 (en) | 2020-04-06 | 2023-10-17 | Vmware, Inc. | Using service planes to perform services at the edge of a network |
US11212356B2 (en) | 2020-04-06 | 2021-12-28 | Vmware, Inc. | Providing services at the edge of a network using selected virtual tunnel interfaces |
US11438257B2 (en) | 2020-04-06 | 2022-09-06 | Vmware, Inc. | Generating forward and reverse direction connection-tracking records for service paths at a network edge |
US11734043B2 (en) | 2020-12-15 | 2023-08-22 | Vmware, Inc. | Providing stateful services in a scalable manner for machines executing on host computers |
US11611625B2 (en) | 2020-12-15 | 2023-03-21 | Vmware, Inc. | Providing stateful services in a scalable manner for machines executing on host computers |
Also Published As
Publication number | Publication date |
---|---|
WO2017044253A1 (en) | 2017-03-16 |
EP3348097A1 (en) | 2018-07-18 |
JP2018532312A (en) | 2018-11-01 |
US9591582B1 (en) | 2017-03-07 |
TW201713137A (en) | 2017-04-01 |
KR20180050389A (en) | 2018-05-14 |
CN108029078A (en) | 2018-05-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9591582B1 (en) | Smart co-processor for optimizing service discovery power consumption in wireless service platforms | |
EP2497286B1 (en) | Peer discovery in a wireless communication network | |
US9001693B2 (en) | Enhanced discovery procedures in peer-to-peer wireless local area networks (WLANs) | |
EP3849224B1 (en) | Persistent network negotiation for peer to peer devices | |
US10531269B2 (en) | Network assisted device-to-device discovery for peer-to-peer applications | |
US8577999B2 (en) | Method for WLAN network and device role activation | |
US20130148643A1 (en) | Enhanced discovery procedures in peer-to-peer wireless local area networks (wlans) | |
US20130166759A1 (en) | Apparatus, systems, and methods of ip address discovery for tunneled direct link setup | |
US20110161697A1 (en) | Method and system for discoverability of power saving p2p devices | |
EP3499979B1 (en) | Proxy service and power savings in wireless device | |
JP6563416B2 (en) | System and method for improving the user experience of applications for proximity-based peer-to-peer mobile computing | |
US11218961B2 (en) | Power saving for wireless device | |
US8848701B2 (en) | Split usage of radio access networks with IMS | |
CN111587591B (en) | Service discovery in wireless networks | |
KR102208987B1 (en) | Communication device, communication method, and program | |
TWI809626B (en) | Methods and user equipment for mobile communications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: QUALCOMM INCORPORATED, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RABII, KHOSRO MOHAMMAD;SUBRAMANIAM, VIJAY NAICKER;LIOY, MARCELLO VINCENZO;AND OTHERS;SIGNING DATES FROM 20151022 TO 20151216;REEL/FRAME:037412/0733 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |