Some content of this application is unavailable at the moment.
If this situation persist, please contact us atFeedback&Contact
1. (WO2017184141) BASE STATION POWER CONSERVATION VIA DEVICE OPERATION COORDINATION
Note: Text based on automatic Optical Character Recognition processes. Please use the PDF version for legal matters

BASE STATION POWER CONSERVATION VIA DEVICE OPERATION

COORDINATION

TECHNICAL FIELD

The present disclosure relates to wireless communication, and more particularly, to a system to coordinate the operation of devices coupled to the base station to conserve power.

BACKGROUND

As wireless communication technology continues to evolve, the utilization of wireless technology continues to expand. Not only are new wireless applications being developed, but wireless communication is also being incorporated into existing applications that did not rely upon wireless interaction. It is estimated that with the deployment of the next-generation of wireless communications system (e.g., 5G) around 2020, billions of devices will be added to the Internet. To service this proliferation of wireless-enabled devices, millions of additional base stations such as, for example, evolved node B (eNB) base stations utilized in existing third generation partnership project (3GPP) Long Term Evolution (LTE) or LTE- Advanced (LTE-A) networks, will need to be implemented. It is expected that emerging 5G networks will comprise a much more dense deployment of base stations than that in existing networks.

While the prospect of improved wireless communication is promising, the logistics of this expansion are problematic. Each base station forms a cell within the network, and must constantly consume power to support wireless communication activity for the linked devices, or in terms of 3GPP user equipment (UE), in the cell. Thus, the higher base station density in future networks is expected to result in significantly increased power consumption. In view of worldwide concerns about energy, a mechanism is needed to reduce or at least moderate base station power consumption. Reduced base station power consumption may facilitate network expansion in both densely populated areas where energy infrastructure burden may be a concern, as well as in less-developed locations where energy availability may be scarcer.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of various embodiments of the claimed subject matter will become apparent as the following Detailed Description proceeds, and upon reference to the Drawings, wherein like numerals designate like parts, and in which:

FIG. 1 illustrates an example system for base station power conservation via device operation coordination in accordance with at least one embodiment of the present disclosure;

FIG. 2 illustrates example configurations for a base station and user equipment usable in accordance with at least one embodiment of the present disclosure; and

FIG. 3 illustrates example operations to coordinate device operation in accordance with at least one embodiment of the present disclosure.

Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications and variations thereof will be apparent to those skilled in the art.

DETAILED DESCRIPTION

This disclosure is directed to base station power conservation via device operation coordination. A base station (BS) may interact with user equipment (UE) within its cell. During interaction the BS may identify certain UEs based on operational characteristics of the UEs. For example, the BS may determine that certain UEs are Internet of Things (IoT) devices whose operation may conform to a predictable pattern that may be controlled by the BS. The BS may then perform various operations to coordinate the operation of the certain UE devices to propagate periods of wireless inactivity during which the BS may operate in a low power mode to conserve energy. The operations may include, for example, determining the wireless behavior of each certain UE, determining a pattern of operation for each certain UE and configuring each certain UE device based on the corresponding pattern of operation.

In at least one embodiment, an apparatus for a base station (BS) may comprise, for example, at least processing circuitry. The processing circuitry may be to identify a first user equipment (UE) from a plurality of UEs based, at least in part, on operational characteristics of the first UE, determine wireless traffic behavior for the first UE to identify at least one pattern of operation of the first UE and generate at least one configuration signal for the first UE based on the at least one pattern of operation.

In at least one embodiment, example operational characteristics may comprise at least one of the first UE initiating a majority of wireless traffic, the first UE being delay tolerant, the first UE remaining linked to the apparatus, the first UE having determinable wireless traffic periodicity or the first UE having determinable wireless traffic data rate requirements. The processing circuitry may further be to identify the first UE based on the first UE being a member of a group of UEs running a common application that is serviced by the apparatus. The processing circuitry may further be to at least one of identify the first UE or determine the wireless traffic behavior during a LTE Radio Resource Control (RRC) Connection Establishment procedure performed when the first UE connects to the apparatus. For example, the processing circuitry may further be to determine identification information from an RRC Connection Request message received from the first UE during the RRC Connection Establishment procedure, cause the apparatus to forward at least the identification information to a mobility management engine (MME) in an LTE core network supporting the apparatus, analyze data related to a subscription profile of the first UE received from the MME and at least one of identify the first UE or determine the wireless traffic behavior based on the data related to the subscription profile. In another example, the processing circuitry may further be to determine an RRC Establishment Cause information element (IE) from an RRC Connection Request message received from the first UE during the RRC Connection Establishment procedure, determine that the IE is set to a value of "delay tolerant" and at least one of identify the first UE or determine the wireless traffic behavior based on the IE value being set to "delay tolerant." In another example, the processing circuitry may further be to determine an Attach Request message from an RRC Connection Setup Complete message received from the first UE during the RRC Connection Establishment procedure, the Attach Request message including fields having data indicating at least one of expected traffic type, periodicity or maximum latency tolerated for the first IE and at least one of identify the first UE or determine the wireless traffic behavior based on the data in fields of the Attach Request Message.

In at least one embodiment, in determining wireless traffic behavior for the first UE the processing circuitry may further be to determine at least one of a number of bytes sent during a communication session, a length of a communication session or a periodicity of communication sessions. The processing circuitry may further be to determine a traffic pattern of the first UE and determine all of the UEs having a traffic pattern similar to the first UE. In generating the at least one configuration signal, the processing circuitry may further be to cause the apparatus to transmit at least one signal to the first UE, the at least one signal configuring a coordinated power saving (CPS) cycle in the first UE. The processing circuitry may further be to cause the apparatus to transmit at least one LTE RRC Connection

Reconfiguration Message indicating at least apparatus availability for supporting wireless communication. The processing circuitry may further be to cause the apparatus to transmit at least one LTE System Information Block (SIB) message over an LTE Physical Downlink Shared Channel (PDSCH) including at least a Base Station (BS) On/Off cycle. The processing circuitry may further be to cause the apparatus to enter a mode including at least one period of low power operation corresponding to at least one period of inactivity in the at least one pattern of operation.

In at least one embodiment, an apparatus for a user equipment (UE) may comprise, for example, at least processing circuitry to process at least one downlink signal received from a base station (BS), wherein the at least one downlink signal includes at least a pattern of operation and reconfigure the apparatus based on the pattern of operation. The processing circuitry may further be to determine a BS On/Off cycle based on the pattern of operation; and modify wireless operation of the apparatus to be active during the BS On cycles. In at least one embodiment, an example method for coordinating user equipment (UE) wireless traffic behavior may comprise identifying, at a base station (BS), a first UE from a plurality of UEs based, at least in part, on operational characteristics of the first UE, determining, at the BS, wireless traffic behavior for the first UE to identify at least one pattern of operation of the first UE and generating, at the BS, at least one configuration signal for the first UE based on the at least one pattern of operation.

FIG. 1 illustrates an example system for BS power conservation via device operation coordination in accordance with at least one embodiment of the present disclosure. When describing embodiments consistent with the present disclosure, some reference may be made to technological components (e.g., eNBs, UEs, etc.) of 3GPP Long Term Evolution (LTE) or LTE- Advanced (LTE-A)-based wireless network standards, including current, previous and future versions of the standards. The standards may include, for example, 3GPP TS 36.300, VI 1.2.0, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 11)". The various references to components and functional aspects of known wireless standards have been employed herein to provide a readily comprehensible perspective from which to understand the disclosed embodiments, and are not meant to limit implementations to only employing the referenced technologies. Moreover, the inclusion of an apostrophe after an item number (e.g., 100') in the disclosure may indicate that an example embodiment of the particular item is being illustrated merely for the sake of explanation herein.

As referenced herein, an IoT device may generally comprise an addressable connected apparatus or system that does not operate primarily as a data processor but that is still capable of communicating utilizing a local area network (LAN), a wide area network (WAN) like the Internet, etc. IoT devices may comprise electronic circuitry to perform data processing but exclude devices that may be deemed "computing" devices such as desktops, laptops, tablets, smart phones, etc. The term "smart" may generally indicate that a device has some ability to

process data. As referenced herein, an IoT device may be an example of a smart device. The use of "IoT" herein is interchangeable with the terminology machine-type communication device (MTC). Example IoT devices may include, but are not limited to, smart apparatuses such as home appliances, heating, ventilation and air conditioning (HVAC) equipment, office equipment, manufacturing equipment, smart vehicles and systems employed within vehicles, smart video capture equipment such as cameras (e.g., security cameras, standalone cameras based on RealSense depth sensing technology, etc.), smart environmental monitors such as thermometers, smoke detectors, security/motion/intrusion detectors, leak detectors, etc.

Example system 100 is illustrated in FIG. 1. System 100 may comprise at least BS 102 (e.g., an eNB) to form one "cell" 104 in a wireless network existing now (e.g., a 3GPP Long Term Evolution (LTE) or LTE- Advanced (LTE-A)-based wireless network) or in the future. In general, BS 102 may facilitate the transmission and reception of wireless data for wireless-enabled devices within communication range (e.g., in cell 104). Wireless-enabled devices may commonly include, but are not limited to, mobile communication devices such as a cellular handset or a smartphone based on the Android® OS from the Google

Corporation, iOS® or Mac OS® from the Apple Corporation, Windows® OS from the Microsoft Corporation, Tizen OS™ from the Linux Foundation, Firefox® OS from the Mozilla Project, Blackberry® OS from the Blackberry Corporation, Palm® OS from the Hewlett-Packard Corporation, Symbian® OS from the Symbian Foundation, etc., mobile computing devices such as a tablet computer like an iPad® from the Apple Corporation, Surface® from the Microsoft Corporation, Galaxy Tab® from the Samsung Corporation, Kindle® from the Amazon Corporation, etc., an Ultrabook® including a low-power chipset from the Intel Corporation, a netbook, a notebook, a laptop, a palmtop, etc., wearable devices such as a wristwatch form factor computing device like the Galaxy Gear® from Samsung, an eyewear form factor computing device/user interface like Google Glass® from the Google Corporation, a virtual reality (VR) headset device like the Gear VR® from the Samsung Corporation, the Oculus Rift® from the Oculus VR Corporation, etc., typically stationary computing devices such as a desktop computer, server, a group of computing devices in a high performance computing (HPC) architecture, a smart television or other "smart" device, small form factor computing solutions (e.g., for space-limited applications, TV set-top boxes, etc.) like the Next Unit of Computing (NUC) platform from the Intel Corporation, etc.

Consistent with the present disclosure, certain categories or types of UE may include certain operational characteristics that make the UE more appropriate candidates for use in coordination. Coordination, as referenced herein, may comprise altering the wireless

behavior of UEs within cell 104 so that wireless activity occurs within the same timeframe. While the duration of the timeframe may be variable, timeframe size impacts the amount of wireless activity that may occur within the timeframe. In at least one embodiment, activity scheduling may be centralized in BS 102. For BS 102 to implement flexible scheduling in system 100 enough capacity is required to compress all of the wireless activity for cell 104 into smaller time periods, leaving available time periods remaining with no wireless activity. Coordinating wireless behavior to occur within the same timeframe may create inactivity periods during which BS 102 may sleep (e.g., enter a low power mode to conserve power).

Certain operational characteristics may make UEs more suitable for coordination. For example, if the UE engages in mainly device-originated traffic, if the UE is delay-tolerant while still supporting device-terminated data communication, if the UE is expected to remain within cell 104 due to, for example, the UE being substantially stationary (e.g., having zero or low mobility), if applications that execute on the UE comprise known or determinable traffic characteristics in terms of at least traffic periodicity and required data rates, etc. An example category of UE that commonly includes these operational characteristics is IoT devices. For example, IoT device 106, IoT device 108 and IoT device 110 (collectively, "IoT devices 106-110") are shown in FIG. 1. While three IoT devices 106-110 are illustrated as an example, the actual number of IoT devices 106-110 may depend on, for example, the capabilities of system 100, the application intended for system 100, etc. Moreover, while IoT devices 106-110 are presented as an example, other types of UEs may be implemented in system 100.

For example, IoT devices 106-110 may perform wide-scale sensing and reporting of data for various purposes such as parking meters, parking occupancy devices, utility meters etc. At least one objective consistent with the present disclosure is how to optimize network, and more specifically BS energy efficiency given a dense BS-deployment designed to support IoT or MTC devices. In at least one embodiment, BS energy may be conserved by learning wireless traffic characteristics of IoT devices 106-110 in cell 104, and then using that information to coordinate their power cycles such as to conserve power at BS 102. IoT devices in next generation (e.g., 5G) networks may configure ON/OFF cycles similar to the Discontinuous Reception (DRX) cycles used in existing LTE networks. A UE is available during DRX ON periods and unavailable to the network during the OFF periods. However, existing DRX cycle configuration is based solely on inactivity in each UE, and is triggered whenever each UE is inactive for a certain given period of time. An example of existing operation is illustrated in FIG. 1 at 112 wherein activity for BS 102 and IoT devices 106-110 is shown. The wireless traffic behavior of IoT devices 106-110 is completely dependent on

the activity occurring in each individual device without consideration of the behavior of the other devices, and so a period of wireless activity as shown at 114 may occur randomly and may then be followed by a period of inactivity as shown at 116. As a result, in current LTE, BS 102 must remain always available as shown at 118, and is thus unable to save any power.

Consistent with the present disclosure, a mechanism may be employed whereby the

UE is scheduled to be ON based on the BS learning the wireless connectivity needs of the UE to perform data transmission/reception activities and then power down until the next interval. An example "Coordinated Power Saving" (CPS) cycle may comprise two intervals including ON and OFF intervals. During an example ON interval, a UE may perform coordination, initial connectivity procedures and data transmission. During an example OFF interval, the UE may then power down until the next ON interval and may not listen to the channel at all. When BS 102 configures each of IoT devices 106-110 with cycle, BS 102 does not guarantee its own availability during CPS cycle OFF period. An example of coordination 120 is illustrated at 122 in FIG. 1. As shown in example 122, ON intervals for each of IoT devices 106-110 now fall within a certain period of time, followed by a period of inactivity. During the period of inactivity, BS 102 may enter a low power mode to save energy as shown at 124.

For BS 102 to configure IoT devices 106-110 in CPS cycle mode, BS 102 may first operate in a mode where it is available at all times. After a period of learning, during which BS 102 learns the traffic characteristics of IoT devices 106-110 within cell 104 in terms of, for example, a number of bytes sent during each wireless communication session, a length of each session, a periodicity for the sessions, etc. It may be assumed that the wireless traffic characteristics of IoT devices 106-110 follow a deterministic pattern, such that once BS 102 learns the wireless traffic behavior of any of IoT devices 106-110, BS 102 may then predict when a UE would be connecting to BS 102 for its next session. BS 102 may then accumulate the wireless behavior information for all UEs within cell 104 (e.g., IoT devices 106-110) and may then configure the UE such as to coordinate their CPS cycles to be aligned to generate the longest period of wireless inactivity during which BS 102 may enter a low power mode.

For the sake of example, operation in terms of an LTE system (e.g., existing now or in the future) will be presented. BS 102 (e.g., an eNB) may determine commonality in wireless behavior based on IoT devices 106-110 (e.g., UEs) being members of a group performing the same IoT application. For example, IoT devices 106-110 may include smart parking meters, smart gas meters or other smart devices, and grouping may be determined based on various factors such as device identification (ID), group ID, IoT devices 106-110 always performing the same or similar actions (e.g., always requesting or providing the same information), etc.

Moreover, different ways exist for BS 102 to at least one of identify IoT devices 106-110 that may be grouped or determine the operational characteristics of IoT devices 106-110. For example, BS 102 may be part of a LTE network that may further comprise core network functionality. Initial connection to BS 102 by IoT devices 106-110 may be conducted via an RRC Connection Establishment procedure. During RRC connection establishment, BS IoT devices 106-110 may include identification information and a RRC Establishment Cause set to "delay tolerant" in an RRC Connection Request message. The identification information may then be provided to, for example, a Mobility Management Engine (MME) within the core network to determine subscription information corresponding to IoT devices 106-110. The subscription information may comprise data that BS 102 may use to determine wireless behavior for IoT device 106-110, whether the wireless behavior can be coordinated, etc. In an alternative mode of operation, IoT devices 106-110 may also transmit RRC Connection Complete messages during RRC Connection Establishment, the RRC Connection Complete messages including Attach Request messages that may be forwarded by BS 102 to the MME. The MME may use identification information in the Attach Request message to then locate subscription profiles and capability information for each of IoT 106-110 from which traffic characteristics may be determined. The MME may forward the subscription profiles and/or capability information to BS 102 when responding with an Attach Accept message. Another method usable for determining wireless behavior may comprise the Attach Request Message in the RRC Connection Complete Message including operational information for IoT devices 106-110 such as delay-tolerance information. For example, the Attach Request Message may comprise a new field such as "Traffic type" (e.g., set to a value of "periodic") and may also include periodicity data to indicate to the MME the type of wireless traffic IoT devices 106-110 are expecting to generate. In at least one embodiment, the Attach Request Message may also comprise a maximum latency tolerated value to be considered when BS 102 determines the maximum length of its OFF cycle so as to remain within the maximum latency tolerated. BS 102 may also learn information regarding the traffic characteristics of IoT devices 106-110 using built-in circuitry that detects the traffic pattern of at least one IoT device 106-110, and then determines all IoT devices 106-110 that have the same pattern. BS 102 may then generate a coordination pattern to align the different DRX cycles of IoT devices 106- 110 for its own power savings benefit.

After IoT devices 106-110 are identified and/or their wireless behavior is determined, BS 102 may generate a pattern of operation for IoT devices 106-110 to follow to allow for at least one period of low power operation for BS 102 to conserve power. For example, BS 102

may transmit a RRC message such as RRC Connection Reconfiguration message including parameters regarding the availability of BS 102 to service the wireless requirements of IoT devices 106-110. The RRC Connection Reconfiguration message is a unicast message (e.g., single sender to single receiver), and may cause BS 102 to expend substantial resources due to the requirement of interacting with each IoT device 106-110 individually. More optimally, once BS 102 determines the type (e.g., including wireless traffic characteristics) of devices in cell 104, a new System Information Block (SIB) message may be transmitted. The new SIB message may include parameters such as, for example, a BS ON/OFF cycle, cycle duration, an offset (e.g., from current time in terms of radio frames), etc. that may indicate when BS 102 plans to start executing the ON/OFF cycle, etc. In at least one embodiment, the SIB message may be sent over the Physical Downlink Shared Channel (PDSCH) channel. Upon receiving the SIB message, IoT devices 106-110 may then, for example, analyze the new ON/OFF cycle of BS 102 and reset their timers (e.g., for paging or cell selection/reselection) so that IoT devices 106-110 also remains powered down during the OFF cycles of BS 102.

In at least one embodiment, BS 102 may stay active during the CPS OFF cycle. For example, BS 102 may be active in a low power mode and transmit synchronization signals similar to signals currently sent in LTE (e.g., the primary and secondary synchronization signals) but at a lower frequency than during the CPS ON cycle. The lower transmission frequency allows BS 102 to conserve power. Moreover, this mode of operation may also enable newly entering IoT devices, or IoT devices that have an aperiodic event trigger to transmit UL data, to continue to transmit data during OFF periods, though at a higher delay (e.g., equivalent to the lowered frequency of base station coordination signals). The lower frequency for transmitting synchronization signals during the CPS OFF cycle may be known to IoT devices, or may be extracted from the system information messages sent by BS 102.

An example use scenario may comprise parking garage sensors (e.g., corresponding to

IoT devices 106-110) needing to be updated every 1 minute to report parking spot occupancy. The data sent by each sensor device is only about 100 bytes long and there may be a 10,000 of such devices deployed within the cell radius of BS 102. If the average data transmission speed is about 100kbps for each of the parking sensors, and system 100 is able to support about 100 simultaneous users within a single frame lasting 10ms, then to support 10,000 users the system may require only about 1 second if every parking sensor was efficiently scheduled within the first second. The remainder of the time BS 102 may be powered off, may be partitioned to wait for downlink traffic, etc. However, it may not be possible for BS 102 to simply turn on and off at the same periodicity since data from each device may be

transmitted sporadically. In at least one embodiment, BS 102 may align ON/OFF cycles of the parking sensors to be coordinated with each other and an availability period of BS 102. BS 102 may then be unavailable during the coordinated OFF period of all of the parking sensors. BS 102 doesn't have to be OFF, but it also does not guarantee availability to the parking sensors. Although embodiments of the present disclosure are discussed in use with IoT devices 106-110, the embodiments may be implemented with all types of wireless traffic for which BS 102 may determine wireless traffic behavior via a learning mechanism, and then configure the UEs based on a schedule to coordinate their operation. Note, in this scheme UE power consumption may not be affected while BS energy efficiency is increased.

FIG. 2 illustrates example configurations for a BS and UE usable in accordance with at least one embodiment of the present disclosure. Example BS 102' and IOT devices 106'-110' may be capable of performing any of the activities described above with respect to FIG. 1. However, BS 102' and IOT devices 106'-110' have been presented only as examples of apparatuses that are usable in embodiments consistent with the present disclosure, and are not intended to limit any of the various embodiments to any particular manner of implementation.

BS 102' may comprise system circuitry 200 to manage device operations. System circuitry 200 may include, for example, processing circuitry 202, memory circuitry 204, power circuitry 206, user interface circuitry 208 and communication interface circuitry 210. BS 102' may further include communication circuitry 212 and coordination circuitry 214. While communication circuitry 212 and coordination circuitry 214 have been shown as separate from system circuitry 200, the example shown FIG. 2 has been provided merely for explanation. Some or all of the functionality associated with communication circuitry 212 and/or coordination circuitry 214 may also be incorporated into system circuitry 200.

In BS 102', processing circuitry 202 may comprise one or more processors situated in separate components, or alternatively one or more cores in a single component (e.g., a system-on-a-chip (SoC)), along with processor-related support circuitry (e.g., bridging interfaces, etc.). Example processors may include, but are not limited to, various x86-based microprocessors available from the Intel Corporation including those in the Pentium®, Xeon®, Itanium®, Celeron®, Atom™, Quark™, Core i-series, Core M-series product families, Advanced RISC (e.g., Reduced Instruction Set Computing) Machine or "ARM" processors, etc. Examples of support circuitry may include chipsets (e.g., Northbridge, Southbridge, etc. available from the Intel Corporation) configured to provide an interface through which processing circuitry 202 may interact with other system components that may be operating at different speeds, on different buses, etc. in BS 102'. Moreover, some or all of the functionality commonly associated with the support circuitry may also be included in the same physical package as the processor (e.g., such as in the Sandy Bridge, Broadwell and Skylake families of processors available from the Intel Corporation).

Processing circuitry 202 may be configured to execute various instructions in BS 102'. Instructions may include program code configured to cause processing circuitry 202 to perform activities related to reading data, writing data, processing data, formulating data, converting data, transforming data, etc. Information (e.g., instructions, data, etc.) may be stored in memory circuitry 204. Memory circuitry 204 may comprise random access memory (RAM) and/or read-only memory (ROM) in a fixed or removable format. RAM may include volatile memory configured to hold information during the operation of BS 102' such as, for example, static RAM (SRAM) or Dynamic RAM (DRAM). ROM may include non- volatile (NV) memory circuitry configured based on BIOS, UEFI, etc. to provide instructions when BS 102' is activated, programmable memories such as electronic programmable ROMs (EPROMS), Flash, etc. Other fixed/removable memory may include, but are not limited to, example magnetic memories such as hard disk (HD) drives, etc., example electronic memories such as solid state flash memory (e.g., embedded multimedia card (eMMC), etc.), removable memory cards or sticks (e.g., micro storage device (uSD), USB, etc.), example optical memories such as compact disc-based ROM (CD-ROM), Digital Video Disks (DVD), Blu-Ray Disks, etc.

Power circuitry 206 may include internal power sources (e.g., a battery, fuel cell, etc.) and/or external power sources (e.g., electromechanical or solar generator, power grid, external fuel cell, etc.), and related circuitry configured to supply BS 102' with the power needed to operate. User interface circuitry 208 may include hardware and/or software to allow users to interact with BS 102' such as, for example, various input mechanisms (e.g., microphones, switches, buttons, knobs, keyboards, speakers, touch- sensitive surfaces, one or more sensors configured to capture images and/or sense proximity, distance, motion, gestures, orientation, biometric data, etc.) and various output mechanisms (e.g., speakers, displays, lighted/flashing indicators, electromechanical components for vibration, motion, etc.). The hardware in user interface circuitry 208 may be incorporated within BS 102' and/or may be coupled to BS 102' via a wired or wireless communication medium. User interface circuitry 208 may be optional in certain circumstances such as, for example, a situation wherein BS 102' comprises at least one server (e.g., rack server, blade server, etc.) that does not include user interface circuitry 204, and instead relies on another device (e.g., a management terminal) for user interface functionality.

Communication interface circuitry 210 may be configured to manage packet routing and other control functions for communication circuitry 212, which may be configured to support wired and/or wireless communications. In some instances, BS 102' may comprise more than one set of communication circuitry 212 (e.g., including separate physical interface circuitry for wired protocols and/or wireless radios) managed by communication interface circuitry 210. Wired communications may include serial and parallel wired mediums such as, for example, Ethernet, USB, Fire Wire®, Thunderbolt™, Digital Video Interface (DVI), High-Definition Multimedia Interface (HDMI), Display Port™, etc. Wireless communications may include, for example, close-proximity wireless mediums (e.g., radio frequency (RF) such as based on the RF Identification (RFID)or Near Field Communications (NFC) standards, infrared (IR), etc.), short-range wireless mediums (e.g., Bluetooth®, WLAN, Wi-Fi, etc.), long range wireless mediums (e.g., cellular wide-area radio communication technology, satellite-based communications, etc.), electronic communications via sound waves, long-range optical communications, etc. In one embodiment, communication interface circuitry 210 may be configured to prevent wireless communications that are active in communication circuitry 212 from interfering with each other. In performing this function, communication interface circuitry 210 may schedule activities for communication circuitry 212 based on, for example, the relative priority of messages awaiting transmission. While the embodiment disclosed in FIG. 2 illustrates communication interface circuitry 210 being separate from communication circuitry 212, it may also be possible for the functionality of communication interface circuitry 210 and communication circuitry 212 to be incorporated into the same circuitry.

Consistent with the present disclosure, coordination circuitry 214 may comprise hardware or a combination of hardware and software. For example, processing circuitry 202 may execute the program code stored in memory circuitry 204 that may transform processing circuitry 202 from general purpose data processing circuitry (e.g., a general microprocessor) into specialized circuitry to perform various operations associated with BS 102', and more specifically with coordination circuitry 214. Coordination circuitry 214 may interact with any or all of processing circuitry 202, memory circuitry 204 and/or communication circuitry 212. In at least one embodiment, coordination circuitry 214 may receive wireless signals from IoT devices 106'-110' via communication circuitry 110', may utilize processing circuitry 202 and/or memory circuitry 204 to determine wireless behavior and determine operational patterns for IoT devices 106'-110', and may configure IoT devices 106'-! 10' based on the operational patterns through signals transmitted to IoT devices 106'-110' via communication circuitry 212.

Consistent with the present disclosure, IoT devices 106'-110' may comprise circuitry similar to BS 102', but have been shown in FIG. 2 as having reduced circuitry that may be characteristic of an IoT device. While typically lower power and lower complexity than in BS 102', communication circuitry 212' may operate in a manner that is similar to

communication circuitry 212. SoC circuitry 216 may comprise data processing, memory, I/O, interface, etc. resources combined in an integrated circuit (IC), chipset, multi-chip module (MCM), etc. Application-specific circuitry 218 may comprise circuitry that is specific to the usage of IoT devices 106'-110'. In the above example of a parking garage sensor, application-specific circuitry 218 may comprise sensors such as visual, electronic or magnetic sensors to determine whether a vehicle is occupying a particular parking space. Other examples may include data monitors or interfaces that allow IoT devices 106'-110' to interact with a collocated apparatus such as an appliance, machine, meter, etc. In an example of operation, SoC circuitry 216 may receive data from application-specific circuitry 218 and may transmit the data via communication circuitry 212'. SoC circuitry 216 may also perform coordination operations consistent with the present disclosure comprising, for example, receiving at least one signal from BS 102' via communication circuitry 212', wherein the at least one signal includes at least a pattern of operation, and reconfiguring the IoT device 106'-110' in which SOC circuitry 216 resides device based on the pattern of operation.

In at least one embodiment, BS 102' may interact with MME 222 in core network 220 when, for example, identifying IoT devices 106'-110' in cell 104, determining wireless traffic behavior for IoT devices 106'-110', etc. In example implementations, core network 220 may be a System Architecture Evolution (SAE) Evolved Packet Core (EPC) network. MME 222 may comprise at least one apparatus (e.g., a server) accessible to at least BS 102'. MME 222 may generally process signaling between the UEs in cell 104 (e.g., IoT device 106'-110') and core network 220, and in this capacity may support BS 102' in configuring communications with IoT devices 106'-110' (e.g., utilizing the RRC Connection Establishment procedure).

FIG. 3 illustrates example operations to coordinate device operation in accordance with at least one embodiment of the present disclosure. In operation 300, a BS may listen for IoT devices within its cell. A determination may then be made in operation 302 as to whether any IoT devices are currently operating within the cell. If in operation 302 it is determined that no IoT devices are currently operating within the cell, then in operation 304 the BS may continue operation and may optionally return to operation 300 (e.g., periodically, based on a request, based on a triggering event, etc.) to check for IoT devices within the cell.

If in operation 302 it is determined that IoT devices are operating within the cell, then in operation 306 the BS may learn the wireless traffic behavior of the IoT devices. This may occur over an extended period (e.g., a series of communication sessions) so that the BS may determine if the IoT devices are operating with certain invariable behavioral characteristics. In operation 308 the BS may then determine patterns of traffic to coordinate IoT device behavior. For example, the BS may determine a schedule of operation for each IoT device so that the wireless activity of the IoT devices all happens within the same period of time without affecting performance of the device or of the overall system. The BS may then configure the IoT devices to coordinate wireless traffic in operation 310. The configuration may comprise the BS transmitting at least one signal to each IoT device, the signal including at least a pattern of traffic determined in operation 308. BS lower power periods may then be set in the BS based on the coordinated traffic in operation 312. For example, the BS may set a schedule to enter a low power mode during periods of wireless inactivity predicted to occur in the coordinated traffic. Operation 312 may be followed by a return to operation 304 to continue operation of the BS.

While FIG. 3 illustrates operations according to an embodiment, it is to be understood that not all of the operations depicted in FIG. 3 are necessary for other embodiments. Indeed, it is fully contemplated herein that in other embodiments of the present disclosure, the operations depicted in FIG. 3, and/or other operations described herein, may be combined in a manner not specifically shown in any of the drawings, but still fully consistent with the present disclosure. Thus, claims directed to features and/or operations that are not exactly shown in one drawing are deemed within the scope and content of the present disclosure.

As used in this application and in the claims, a list of items joined by the term

"and/or" can mean any combination of the listed items. For example, the phrase "A, B and/or C" can mean A; B; C; A and B; A and C; B and C; or A, B and C. As used in this application and in the claims, a list of items joined by the term "at least one of can mean any combination of the listed terms. For example, the phrases "at least one of A, B or C" can mean A; B; C; A and B; A and C; B and C; or A, B and C.

As used in any embodiment herein, the term "module" may refer to software, firmware and/or circuitry configured to perform any of the aforementioned operations.

Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage mediums. Firmware may be

embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in memory devices. "Circuitry", as used in any embodiment herein, may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry such as computer processors comprising one or more individual instruction processing cores, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry. The circuitry may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), system on-chip (SoC), desktop computers, laptop computers, tablet computers, servers, smartphones, etc.

Any of the operations described herein may be implemented in a system that includes one or more storage mediums (e.g., non- transitory storage mediums) having stored thereon, individually or in combination, instructions that when executed by one or more processors perform the methods. Here, the processor may include, for example, a server CPU, a mobile device CPU, and/or other programmable circuitry. Also, it is intended that operations described herein may be distributed across a plurality of physical devices, such as processing structures at more than one different physical location. The storage medium may include any type of tangible medium, for example, any type of disk including hard disks, floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic and static RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, Solid State Disks (SSDs), embedded multimedia cards (eMMCs), secure digital input/output (SDIO) cards, magnetic or optical cards, or any type of media suitable for storing electronic instructions. Other embodiments may be implemented as software executed by a programmable control device.

Thus, this disclosure is directed to base station power conservation via device operation coordination. A base station (BS) may interact with user equipment (UE) within its cell. During interaction the BS may identify certain UEs based on operational

characteristics of the UEs. For example, the BS may determine that certain UEs are Internet of Things (IoT) devices whose operation may conform to a predictable pattern that may be controlled by the BS. The BS may then perform various operations to coordinate the operation of the certain UE devices to propagate periods of wireless inactivity during which the BS may operate in a low power mode to conserve energy. The operations may include, for example, determining the wireless behavior of each certain UE, determining a pattern of operation for each certain UE and configuring each certain UE device based on the corresponding pattern of operation.

The following examples pertain to further embodiments. The following examples of the present disclosure may comprise subject material such as a device, a method, at least one machine -readable medium for storing instructions that when executed cause a machine to perform acts based on the method, means for performing acts based on the method and/or a system for base station power conservation via device operation coordination.

According to example 1 there is provided an apparatus for a base station (BS). The apparatus may comprise processing circuitry to identify a first user equipment (UE) from a plurality of UEs based, at least in part, on operational characteristics of the first UE, determine wireless traffic behavior for the first UE to identify at least one pattern of operation of the first UE and generate at least one configuration signal for the first UE based on the at least one pattern of operation.

Example 2 may include the elements of example 1 , wherein the operational characteristics comprise at least one of the first UE initiating a majority of wireless traffic, the first UE being delay tolerant, the first UE remaining linked to the apparatus, the first UE having determinable wireless traffic periodicity or the first UE having determinable wireless traffic data rate requirements.

Example 3 may include the elements of example 2, wherein the processing circuitry is to identify the first UE based on the first UE being a member of a group of UEs running a common application that is serviced by the apparatus.

Example 4 may include the elements of any of examples 1 to 3, wherein the processing circuitry is to at least one of identify the first UE or determine the wireless traffic behavior during a Long Term Evolution (LTE) Radio Resource Control (RRC) Connection Establishment procedure performed when the first UE connects to the apparatus.

Example 5 may include the elements of example 4, wherein the processing circuitry is to determine identification information from an RRC Connection Request message received from the first UE during the RRC Connection Establishment procedure, cause the apparatus to forward at least the identification information to a mobility management engine (MME) in an LTE core network supporting the apparatus, analyze data related to a subscription profile of the first UE received from the MME and at least one of identify the first UE or determine the wireless traffic behavior based on the data related to the subscription profile.

Example 6 may include the elements of example 5, wherein the MME comprises at least one server accessible to the BS.

Example 7 may include the elements of any of examples 5 to 6, wherein the core network is an LTE System Architecture Evolution (SAE) Evolved Packet Core (EPC) network.

Example 8 may include the elements of any of examples 4 to 7, wherein the processing circuitry is to determine an RRC Establishment Cause information element (IE) from an RRC Connection Request message received from the first UE during the RRC Connection Establishment procedure, determine that the IE is set to a value of "delay tolerant" and at least one of identify the first UE or determine the wireless traffic behavior based on the IE value being set to "delay tolerant."

Example 9 may include the elements of any of examples 4 to 8, wherein the processing circuitry is to determine an Attach Request message from an RRC Connection Setup Complete message received from the first UE during the RRC Connection

Establishment procedure, the Attach Request message including fields having data indicating at least one of expected traffic type, periodicity or maximum latency tolerated for the first IE and at least one of identify the first UE or determine the wireless traffic behavior based on the data in fields of the Attach Request Message.

Example 10 may include the elements of any of examples 1 to 9, wherein, in determining wireless traffic behavior for the first UE, the processing circuitry is to determine at least one of a number of bytes sent during a communication session, a length of a communication session or a periodicity of communication sessions.

Example 11 may include the elements of example 10, wherein the processing circuitry is to determine a traffic pattern of the first UE and determine all of the UEs having a traffic pattern similar to the first UE.

Example 12 may include the elements of any of examples 1 to 11, wherein, in generating the at least one configuration signal, the processing circuitry is to cause the apparatus to transmit at least one signal to the first UE, the at least one signal configuring a coordinated power saving (CPS) cycle in the first UE.

Example 13 may include the elements of example 12, wherein the processing circuitry is to cause the apparatus to transmit at least one LTE RRC Connection Reconfiguration Message indicating at least apparatus availability for supporting wireless communication.

Example 14 may include the elements of any of examples 12 to 13, wherein the processing circuitry is to cause the apparatus to transmit at least one LTE System Information Block (SIB) message over an LTE Physical Downlink Shared Channel (PDSCH) including at least a Base Station (BS) On/Off cycle.

Example 15 may include the elements of any of examples 1 to 14, wherein the processing circuitry is to cause the apparatus to enter a mode including at least one period of low power operation corresponding to at least one period of inactivity in the at least one pattern of operation.

Example 16 may include the elements of example 15, wherein the processing circuitry is to cause the apparatus to transmit synchronization signals at a reduced frequency during the at least one period of low power operation to conserve power in the base station.

Example 17 may include the elements of any of examples 1 to 16, wherein the UE is an Internet of Things (IoT) device.

According to example 18 there is provided an apparatus for a user equipment (UE).

The apparatus may comprise processing circuitry to process at least one downlink signal received from a base station (BS), wherein the at least one downlink signal includes at least a pattern of operation and reconfigure the apparatus based on the pattern of operation.

Example 19 may include the elements of example 18, wherein the processing circuitry is to determine a BS On/Off cycle based on the pattern of operation and modify wireless operation of the apparatus to be active during the BS On cycles.

Example 20 may include the elements of any of examples 18 to 19, wherein the apparatus is an Internet of Things (IoT) device.

According to example 21 there is provided a method for coordinating user equipment (UE) wireless traffic behavior. The method may comprise identifying, at a base station (BS), a first UE from a plurality of UEs based, at least in part, on operational characteristics of the first UE, determining, at the BS, wireless traffic behavior for the first UE to identify at least one pattern of operation of the first UE and generating, at the BS, at least one configuration signal for the first UE based on the at least one pattern of operation.

Example 22 may include the elements of example 21, wherein at least one of identifying the first UE or determining the wireless traffic behavior comprises determining identification information from a Long Term Evolution (LTE) Radio Resource Control (RRC) Connection Request message received at the BS from the first UE during an RRC Connection Establishment procedure, causing the BS to forward at least the identification information to a mobility management engine (MME) in an LTE core network supporting the BS, analyzing data related to a subscription profile of the first UE received at the BS from the MME and at least one of identifying the first UE or determining the wireless traffic behavior, at the BS, based on the data related to the subscription profile.

Example 23 may include the elements of any of examples 21 to 22, wherein at least one of identifying the first UE or determining the wireless traffic behavior comprises determining a Long Term Evolution (LTE) Radio Resource Control (RRC) Establishment Cause information element (IE) from an RRC Connection Request message received at the BS from the first UE during an RRC Connection Establishment procedure, determining, at the BS, that the IE is set to a value of "delay tolerant" and at least one of identifying the first UE or determining the wireless traffic behavior, at the BS, based on based on the IE value being set to "delay tolerant."

Example 24 may include the elements of any of examples 21 to 23, wherein at least one of identifying the first UE or determining the wireless traffic behavior comprises determining an Attach Request message from a Long Term Evolution (LTE) Radio Resource Control (RRC) Connection Setup Complete message received at the BS from the first UE during an RRC Connection Establishment procedure, the Attach Request message including fields having data indicating at least one of expected traffic type, periodicity or maximum latency tolerated for the first IE and at least one of identifying the first UE or determining the wireless traffic behavior, at the BS, based on based on based on the data in fields of the Attach Request Message.

Example 25 may include the elements of any of examples 21 to 24, wherein generating the at least one configuration signal comprises causing the BS to transmit at least one Long Term Evolution (LTE) System Information Block (SIB) message over an LTE

Physical Downlink Shared Channel (PDSCH) including at least a Base Station (BS) On/Off cycle.

Example 26 may include the elements of any of examples 21 to 25, and may further comprise causing the BS to enter a mode including at least one period of low power operation corresponding to at least one period of inactivity in the at least one pattern of operation.

Example 27 may include the elements of example 26, and may further comprise causing the base station to transmit synchronization signals at a reduced frequency during the at least one period of low power operation to conserve power in the base station.

According to example 28 there is provided a system including at least one device, the system being arranged to perform the method of any of the above examples 21 to 27.

According to example 29 there is provided a chipset arranged to perform the method of any of the above examples 21 to 27.

According to example 30 there is provided at least one machine readable medium comprising a plurality of instructions that, in response to be being executed on a computing

device, cause the computing device to carry out the method according to any of the above examples 21 to 27.

According to example 31 there is provided at least one apparatus equipped to coordinate user equipment (UE) wireless traffic behavior, the at least one device being arranged to perform the method of any of the above examples 21 to 27.

According to example 32 there is provided a system for coordinating user equipment (UE) wireless traffic behavior. The system may comprise means for identifying, at a base station (BS), a first UE from a plurality of UEs based, at least in part, on operational characteristics of the first UE, means for determining, at the BS, wireless traffic behavior for the first UE to identify at least one pattern of operation of the first UE and means for generating, at the BS, at least one configuration signal for the first UE based on the at least one pattern of operation.

Example 33 may include the elements of example 32, wherein the means for at least one of identifying the first UE or determining the wireless traffic behavior comprise means for determining identification information from a Long Term Evolution (LTE) Radio

Resource Control (RRC) Connection Request message received at the BS from the first UE during an RRC Connection Establishment procedure, means for causing the BS to forward at least the identification information to a mobility management engine (MME) in an LTE core network supporting the BS, means for analyzing data related to a subscription profile of the first UE received at the BS from the MME and means for at least one of identifying the first UE or determining the wireless traffic behavior, at the BS, based on the data related to the subscription profile.

Example 34 may include the elements of any of examples 32 to 33, wherein the means for at least one of identifying the first UE or determining the wireless traffic behavior comprise means for determining a Long Term Evolution (LTE) Radio Resource Control (RRC) Establishment Cause information element (IE) from an RRC Connection Request message received at the BS from the first UE during an RRC Connection Establishment procedure, means for determining, at the BS, that the IE is set to a value of "delay tolerant" and means for at least one of identifying the first UE or determining the wireless traffic behavior, at the BS, based on based on the IE value being set to "delay tolerant."

Example 35 may include the elements of any of examples 32 to 34, wherein the means for at least one of identifying the first UE or determining the wireless traffic behavior comprise means for determining an Attach Request message from a Long Term Evolution (LTE) Radio Resource Control (RRC) Connection Setup Complete message received at the

BS from the first UE during an RRC Connection Establishment procedure, the Attach Request message including fields having data indicating at least one of expected traffic type, periodicity or maximum latency tolerated for the first IE and means for at least one of identifying the first UE or determining the wireless traffic behavior, at the BS, based on based on based on the data in fields of the Attach Request Message.

Example 36 may include the elements of any of examples 32 to 35, wherein the means for generating the at least one configuration signal comprise means for causing the BS to transmit at least one Long Term Evolution (LTE) System Information Block (SIB) message over an LTE Physical Downlink Shared Channel (PDSCH) including at least a Base Station (BS) On/Off cycle.

Example 37 may include the elements of any of examples 32 to 36, and may further comprise means for causing the BS to enter a mode including at least one period of low power operation corresponding to at least one period of inactivity in the at least one pattern of operation.

Example 38 may include the elements of example 37, and may further comprise means for causing the BS to transmit synchronization signals at a reduced frequency during the at least one period of low power operation to conserve power in the BS.

The terms and expressions which have been employed herein are used as terms of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding any equivalents of the features shown and described (or portions thereof), and it is recognized that various modifications are possible within the scope of the claims. Accordingly, the claims are intended to cover all such equivalents.