This application claims the priority and benefit of United States Provisional Patent Application 62/620,627, filed January 23, 2018, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

[0001] The technology relates to electronically controlled devices, and particularly to methods and apparatus for power management of electronically controlled devices. BACKGROUND

[0002] In wireless communication systems, a radio access network generally comprises one or more access nodes (such as a base station) which communicate on radio channels over a radio or air interface with plural wireless terminals. In some technologies such a wireless terminal is also called a User Equipment (UE). A group known as the 3rd Generation

Partnership Project (“3GPP”) has undertaken to define globally applicable technical specifications and technical reports for present and future generation wireless communication systems. The 3GPP Long Term Evolution (“LTE”) and 3GPP LTE Advanced (LTE-A) are projects to improve an earlier Universal Mobile Telecommunications System (“UMTS”) mobile phone or device standard in a manner to cope with future requirements. [0003] In typical cellular mobile communication systems, the base station broadcasts on the radio channels certain information which is required for mobile stations to access to the network. In Long-Term Evolution (LTE) and LTE Advanced (LTE-A), such information is called“system information” (“SI”). Each access node, such as an evolved NodeB (“eNB"), broadcasts such system information to its coverage area via several System Information Blocks (SIBs) on downlink radio resources allocated to the access node. [0004] A wireless terminal (“UE”), after entering a coverage area of an eNB, is required to obtain all the SIBs which are necessary to access to the system. For sake of UEs under coverage, the eNB periodically broadcasts all SIBs relevant for offered services, not just SIBs that are required for access to the system. Each type of SIBs is transmitted in a designated radio resource(s) with its own pre-determined/configurable frequency.

[0005] Public Warning System (PWS) requirements are described, e.g., in 3GPP TR 22.869. The requirements for Public Warning System specified in 3GPP Release 8 onwards provide a text-based and language-dependent PWS Message to mobile users who have conventional mobile devices (e.g., it is assumed the user’s device can display a text-based messages and has some form of a user interface for interaction with the message.

[0006] New and emerging markets are being developed for mobile devices with different or no user interface (e.g., devices implemented with a tiny screen and a limited/no user interface, or sensors with no user interface that support simple functionality such as the control for device power on/off, etc.). [0007] Enhancements to TR 22.869 may consider cases that describe scenarios where user equipments (UEs) with no user interface (e.g., are not intended for human type communication) are connected to a 3GPP network and receive a PWS Message when a disaster occurs. Such UEs may take pre-defmed actions (e.g., shutting down an escalator when an earthquake occurs to prevent harm to users and damage to the device) to minimize damages caused by disasters and to protect humans.

[0008] When PWS Messages are transmitted via a broadcast service, the content provided by such a broadcast service is by design intended to be consumed in a nearly simultaneous manner by a multitude of devices. Thus when a PWS Message is received by the multitude of devices, the activity triggered by the PWS Message will also occur in a near simultaneous manner for each device. [0009] If, for example, the action triggered by the PWS Message causes the device to turn off, or to minimize power its consumption, or to stop the physical aspects controlled by the devices, that action will occur in a near simultaneous manner across the devices receiving the PWS Message, and the resulting load to the electrical distribution system will be minimized in a near simultaneous manner (e.g., the change in load to the electrical system is nearly synchronized with the LTE system broadcast).

[00010] However, it is also true that the action triggered by the termination of the PWS Message may cause the device to turned on, or to maximize its power consumption, or to resume the physical aspects controlled by the device, and that action will also occur in a near simultaneous manner across the devices, and the resulting load spike to the electrical distribution system will also occur in a near simultaneous manner (e.g., the change in load on the electrical distribution system is again nearly synchronized with the LTE system broadcast). Such a spike in electrical demand may cause significant harm to an electrical distribution system that may already be under stress due to the original emergency situation. [00011] Thus there is a need to provide a function that will distribute the actions taken by a device when the action is triggered by a broadcasted PWS Message.

SUMMARY

[00012] In one of its example aspects the technology disclosed herein concerns an electronically controlled device. The electronically controlled device comprises receiver circuitry and processor circuitry. The receiver circuitry is configured to obtain broadcast system information from a base station node over a radio interface. The processor circuitry configured to use the broadcast system information to control a power management function of the electronically controlled device. In an example embodiment and mode the processor circuitry is configured to determine a wait period before performing the power management function. [00013] In another of its example aspects the technology disclosed herein concerns a method for operating an electronically controlled device. In a basic mode the method comprises using receiver circuitry to obtain broadcast system information from a base station node over a radio interface; and processor circuitry using the broadcast system information to control a power management function of the electronically controlled device.

[00014] In another of its example aspects the technology disclosed herein concerns a server which communicates with an electronically controlled device. The server comprises processor circuitry and a communications interface. The processor circuitry is configured to generate a parameter paring selection criteria signal. The parameter paring selection criteria signal comprises an indication of which of plural possible parameter parings are to be utilized by an electronically controlled device in conjunction with a power management function performed by the electronically controlled device. Each of the plural possible parameter parings comprising a wait factor as a first parameter of the pair and a wait time as a second parameter of the pair. The communications interface is configured to transmit the parameter paring selection criteria signal to the electronically controlled device.

BRIEF DESCRIPTION OF THE DRAWINGS

[00015] The foregoing and other objects, features, and advantages of the technology disclosed herein will be apparent from the following more particular description of preferred embodiments as illustrated in the accompanying drawings in which reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the technology disclosed herein. [00016] Fig. 1 is a schematic view showing an example embodiment of an electronically controlled device, such as an internet of things device, in the example non-limiting context of a system comprising a plurality of premises of other electronically controlled devices.

[00017] Fig. 2A - Fig. 2G are diagrammatic views of Si-based power management controllers of differing example embodiments and modes of electronically controlled devices and basic acts performed thereby. [00018] Fig. 3 A - Fig. 3E are diagrammatic views of power level utilization as a function of operation of the Si-based power management controllers of the respective embodiments and modes of Fig. 2A - Fig. 2E.

[00019] Fig. 4 is a diagrammatic view showing example electronic machinery which may comprise server electronic machinery or electronically controlled device electronic machinery.

[00020] Fig. 5 is a diagrammatic view showing figures which illustrate data flows and computer program routines associated with execution of an electronically controlled device of a consolidated example embodiment and mode in which various features of the example embodiments and modes of Fig. 2A - Fig. 2G may be optionally and selectively implemented, either alone or in various differing combinations.

[00021] Fig. 6 and Fig. 7 are diagrammatic views showing a respective first data flow and second data flow for the consolidated example embodiment and mode of Fig. 5

[00022] Fig. 8 is a flowchart showing basic, representative acts or steps comprising a routine executed by an application programmable interface of the Si-based power management controller of the example embodiment and mode of Fig. 5. Fig. 8-1 through Fig. 8-4, including Fig. 8-2A and Fig. 8-2B and Fig. 8-4A and Fig. 8-4B, are flowcharts showing basic, representative acts or steps comprising respective subroutines invoked by the application programmable interface of Fig. 8.

[00023] Fig. 9 shows basic introductory acts comprising a process logic routine executed by a Si-based power management controller of the consolidated example embodiment and mode of Fig. 5. Fig. 9-1 through Fig. 9-4, including Fig. 9-2A and Fig. 9-2B, are flowcharts showing basic, representative acts or steps comprising respective subroutines invoked by the process logic routine of Fig. 9.

[00024] Fig. 10 together with Fig. 10A and Fig. 10B, show basic substantive acts comprising a process logic routine executed by a Si-based power management controller of the consolidated example embodiment and mode of Fig. 5. Fig. 10-1 through Fig. 10-4, including Fig. 10-3 A and Fig. 10-3B, are flowcharts showing basic, representative acts or steps comprising respective subroutines invoked by the process logic routine of Fig. 10.

DETAILED DESCRIPTION

[00025] In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the technology disclosed herein. However, it will be apparent to those skilled in the art that the technology disclosed herein may be practiced in other embodiments that depart from these specific details. That is, those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the technology disclosed herein and are included within its spirit and scope. In some instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the technology disclosed herein with unnecessary detail. All statements herein reciting principles, aspects, and embodiments of the technology disclosed herein, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

[00026] Thus, for example, it will be appreciated by those skilled in the art that block diagrams herein can represent conceptual views of illustrative circuitry or other functional units embodying the principles of the technology. Similarly, it will be appreciated that any flow charts, state transition diagrams, pseudocode, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[00027] As used herein, the term“core network” can refer to a device, group of devices, or sub-system in a telecommunication network that provides services to users of the telecommunications network. Examples of services provided by a core network include aggregation, authentication, call switching, service invocation, gateways to other networks, etc. [00028] As used herein, the term“wireless terminal” can refer to any electronic device used to communicate voice and/or data via a telecommunications system, such as (but not limited to) a cellular network. Other terminology used to refer to wireless terminals and non- limiting examples of such devices can include user equipment terminal, UE, mobile station, mobile device, access terminal, subscriber station, mobile terminal, remote station, user terminal, terminal, subscriber unit, cellular phones, smart phones, personal digital assistants (“PDAs”), laptop computers, netbooks, e-readers, wireless modems, etc.

[00029] As used herein, the term“access node”,“node”, or“base station” can refer to any device or group of devices that facilitates wireless communication or otherwise provides an interface between a wireless terminal and a telecommunications system. A non-limiting example of a base station can include, in the 3GPP specification, a Node B (“NB”), an enhanced Node B (“eNB”), a home eNB (“HeNB”), a gNB or some other similar terminology. Another non-limiting example of a base station is an access point. An access point may be an electronic device that provides access for wireless terminal to a data network, such as (but not limited to) a Local Area Network (“LAN”), Wide Area Network (“WAN”), the Internet, etc. Although some examples of the systems and methods disclosed herein may be described in relation to given standards (e.g., 3GPP Releases 8, 9, 10, 11, and/or 12 or higher), the scope of the present disclosure should not be limited in this regard. At least some aspects of the systems and methods disclosed herein may be utilized in other types of wireless communication systems.

[00030] As used herein, the term“telecommunication system” or“communications system” can refer to any network of devices used to transmit information. A non-limiting example of a telecommunication system is a cellular network or other wireless communication system. [00031] As used herein, the term“cellular network” can refer to a network distributed over cells, each cell served by at least one fixed-location transceiver, such as a base station. A “cell” may be any communication channel that is specified by standardization or regulatory bodies to be used for International Mobile Telecommunications-Advanced (“IMTAdvanced”). All or a subset of the cell may be adopted by 3GPP as licensed bands (e.g., frequency band) to be used for communication between a base station, such as a Node B, and a UE terminal. A cellular network using licensed frequency bands can include configured cells. Configured cells can include cells of which a UE terminal is aware and in which it is allowed by a base station to transmit or receive information.

[00032] Fig. 1 shows an electronically controlled device 20 which obtains electrical power for its operation, at least in part, from an electrical power grid 22. The device 20 performs one or more device-native operations, e.g., operations for which the device 20 is configured to provide a function or service. The device-native operation(s) may depend upon the nature or purpose of the location/premise 24 in which the device 20 is employed or connected. As one example, the device 20 may be a household device such as a refrigerator which performs a refrigeration operation; an air conditioning or heating device which performs a cooling, heating, and/or air handling operation(s) for a home; a remote or central vacuum system which performs a home cleaning operation; or other home appliance or system. As another example, the device 20 may be a tool or piece of equipment or a robot that is located in a shop or factory.

[00033] One non-limiting example of an electronically controlled device 20 is an internet of things (IoT) device. An internet of things device is an electronically controlled device 20 that is addressable using an internet address and/or communicates using internet protocol. In view of the increasing use and practicality of such internet of things devices, for sake of illustration the devices 20 of Fig. 1 and herein are generally referenced as internet of things devices 20. But it should be understood that the devices 20 are not confined to those having internet compatibility.

[00034] As used herein,“electrical power grid”,“grid”, or“electrical power” encompasses any suitable network form of electrical power supply, such as a public electrical power grid (e.g., the conventional public service that provides 120 volts alternating current (AC) to, e.g., businesses and residences, as well as private power grids or private power networks. A provide power grid may, for example, supply electrical power (e.g., direct current (DC) power) to a particular premise(s) or factory(ies). [00035] Fig. 1 illustrates that plural devices 20 may be situated at any given location or premise 24. For example, Fig.l shows that devices 20i,i, ...20i.j and 20 _2,i ...20 _2,k are situated at or connected to premises 24i. The devices 20 at premises 241 may be grouped or organized into different classes or ranks, as indicated by the first subscripts for the respective devices 20. For example, devices 20i,i, ...20i.j may comprise a first class or rank of devices 20, while devices 20 _2,I ...20 _2,k may comprise a first class or rank of devices 20. There may be only one, two, or more than two such classes or ranks. The criteria for grouping or dividing into classes or ranks can be various, such as sub-location within the premise 24, type of functions of the devices 20, anticipated hours or extent of operation of the devices 20, as a few examples. All of the devices 20 of the premise 24 obtain electrical power for operation, at least in part, from an electrical power grid 22. As used hereinafter,“device 20” shall refer to a generic,

representative one of the devices 20. As such, it should be understood that constituent units and functionalities of the device 20i,i described in Fig. 1 may typify such generic,

representative device 20, and may be included in one or more, all, or less than all of the devices 20. Reference to device 20 in conjunction with an alphabetical suffix may have reference to an embodiment figure corresponding to the suffix.

[00036] A premise 24 may optionally comprise one or more server(s) 26. The server(s) 26 may be configured to control one or more of the devices 20, either in individual or coordinated fashion. When provided at the premise 24, server(s) 26 may also be connected to electrical power grid 22, although the server(s) 26 preferably also have backup power. The server(s) 26 may be connected to one or more of the devices 20 of the premise 24 either by hardwire or (more preferably) wireless connections. To this end, Fig. 1 shows the server(s) 26 as comprising server wireless communication interface 28. The protocol/technology utilized for wireless communication interface 28 may be any suitable protocol/technology, such as Bluetooth™, Wi-Fi, 3 GPP LTE, 3 GPP 5G.

[00037] Although shown in Fig. 1 as being situated at the premise 24, server(s) 26 which wireless connect to the device(s) 20 may be located remotely from the premise 24, e.g., anywhere in the world. For example, the server(s) 26 may be situated in a server farm that is remotely operated by some service provider. [00038] Fig. 1 shows that the electrical power grid 22 may supply electrical power to plural premises 24, such as premise 241 (which is illustrated in more detail in Fig. 1), premise 24 ₂ , and premise 24N. It should be understood that the other premises may comprise one or more other device 20s, either of same or differing types, and have same or different configurations, as the premise 241 which is more conspicuously shown in Fig. 1.

[00039] As shown in Fig. 1, the electrical power grid 22 may have many devices 20 of many premises 24 dependent thereon for electrical power. Under certain circumstances it may be desired or required electrical power to one or more devices 20 be shut-down (e.g., terminated), so that the one or more devices 20 are essentially disconnected from the electrical power grid 22. The termination or disconnection of a device 20 from electrical power grid 22 is usually only temporary, and may be for reason of protection to the electrical power grid 22, protection of the device 20, and may be related to or involved with a public safety event or warning. After the termination or disconnection, the devices 20 are generally permitted to reconnect to the electrical power grid 22. [00040] As previously indicated, simultaneous electrical disconnection or reconnection to electrical power grid 22 may tax or overload the electrical power grid 22. An aspect of the technology disclosed herein is a device 20 for which a power management function, such as (for example) termination of grid power utilization or resumption of power grid utilization, is controlled to mitigate grid tax or overload. As described in more detail herein, the device 20 uses broadcast system information obtained over a radio interface from a base station node to control the power management function of the electronically controlled device 20.

[00041] Fig. 1 further shows that the representative device 20 (e.g., device 20i,i) comprises power management function 30. The power management function 30 in turn comprise mechanisms for electrical connection to and/or disconnection from electrical power grid 22, and particularly to electrical distribution line(s) 32 which connect the power management function 30 to electrical power grid 22. The distribution line(s) 32 may connect plural devices 20, and plural premises 24, to electrical power grid 22. The device 20 further comprises a system information-based power management controller, illustrated as Si-based power management controller 34 in Fig. 1. As explained herein, the Si-based power management controller 34 uses broadcast system information to control the power

management function 30 of the electronically controlled device 20.

[00042] The device 20 further comprises device native operation controller 36. The device native operation controller 36 governs the operation of the native function of device 20, whether a household function, factory or shop function, or other function. The native function in turn may employ, and thus device 20 may further comprise, mechanical mechanisms such as actuators, servo motors, that are utilized to implement the native function(s). One or more of such mechanism may utilize the electrical power obtained from electrical power grid 22 when the power management function 30 maintains connection of the device 20 to the electrical power grid 22.

[00043] In an example implementation, the Si-based power management controller 34 and the device native operation controller 36 may comprise the same controller(s) or be dedicated controllers. When plural controllers are employed, the controllers may be distributed and/or co-operating. In an example implementation, the Si-based power management controller 34 and device native operation controller 36 are illustrated as comprising processor circuitry 38. The processor circuitry 38 may comprise one or more processors. Fig. 1 further shows that device 20 comprises memory 40. The memory 40 comprises read-only-memory (ROM) 42 and non-volatile memory (NV-memory) 44. In an example implementation, memory 40 may store, on non-transitory medium, one or more computer programs in the form of coded instructions. The memory 40 and the program(s) are configured to, working with the at least one processor 38, to cause the device 20 to perform, e.g., the control of the native device operations and, as described herein, control of the power management function 30 as by Si-based power management controller 34. One such computer program described herein for a non-limiting example embodiment and mode is a Power Management Life Cycle System program.

[00044] Fig. 1 further shows that representative device 20 also comprises device communication interface(s) 50. The device communication interface(s) 50 comprises radio network interface 52 and server interface 54. The radio network interface 52 comprises at least a receiver for receiving, over a wireless or radio interface 56, communications from a radio access network node 60. The communications may be, for example, Long Term Evolution (LTE) communications. In one example embodiment and mode, radio network interface 52 may comprise merely a receiver, but other example embodiment and modes the radio network interface 52 may comprise a transceiver with transmitting capabilities. As explained herein, the radio network interface 52 obtains system information broadcast over radio interface 56 from the radio access network node 60. The server interface 54 is configured to communicate with the wireless communication interface 28 of server(s) 26. The radio network interface 52 and server interface 54 may be combined in or consolidated in a same interface(s), and may share circuitry such as e.g., amplifier(s), modulation circuitry, demodulation circuitry, and other conventional receiver/transmission equipment, and antennas. Alternatively, each radio network interface 52 and server interface 54 may have dedicated such circuitry.

[00045] The device 20 may include, but is not required to include, an unillustrated user interface for interaction with a user. When provided, such device user interface may serve for both user input and output operations, and may comprise (for example) a screen such as a touch screen that can both display information to the user and receive information entered by the user. The user interface may also include other types of devices, such as a speaker, a microphone, or a haptic feedback device, for example. As previously explained, however, in many situations the device 20 does not have such user interface, but instead is otherwise controlled, if at all, by external equipment such as server(s) 26.

[00046] The radio access network node 60 may be any suitable type of radio access network node, such as a base station (which may be, for example, an eNodeB (eNB) or gNB (for the New Radio System Technology), or an access point such as for WiFi and similar technologies. Among other known constituent components and functionalities, radio access network node 60 comprises a system information controller or system information (SI) generator 62 and transmitter 64. The nature of the system information generated by system information (SI) generator 62, for use by the device 20 for control of the power management function 30, for some non-limiting example embodiment and modes is further described herein. As illustrated in Fig. 1, the radio access network node 60 may communicate with devices 20 at plural premises 24.

[00047] In the example embodiment and modes described herein, the Si-based power management controller 34 of each example embodiment and mode of device 20 uses broadcast system information to control a power management function of the electronically controlled device. Typically the device 20 does not rely upon or utilize any other aspect of the radio access network communications for its device native operation. Thus the device 20 does not typically function as a wireless device, such as a user equipment (UE), which requires radio communications with a radio access network for it native operation. That is, other than the broadcast system information, no other information transmitted by the radio access network is particularly necessary for the native operation of the device 20. Moreover, the broadcast system information which the device 20 does obtain from the radio access network is utilized for other than radio access network purposes. That is, the broadcast system information is not used for control of radio communications, but instead for determining a wait period in conjunction with a power management operation of the device 20.

[00048] Non-limiting specific example implementations of how the system information may be obtained are described in conjunction with various ensuing example embodiments and modes.

[00049] Fig. 2A - Fig. 2G illustrate basic distinguishing aspects of differing embodiment and modes of the Si-based power management controller 34, and thus correspondingly differing embodiment and modes of devices 20A- 20E. Fig. 3A - Fig. 3E correspondingly illustrate basic power management phenomena associated with the respective embodiment and modes of Fig. 2A - Fig. 2E. The example embodiment and modes may be implemented separately or in combination with one or more of the other example embodiment and modes. [00050] After brief separate discussion of each of the paired device and associated basic power management phenomena, example scenarios of operation of the device 20 are described with reference to a composite example embodiment and mode of Fig. 5. The example embodiment and mode of Fig. 5 is termed as“composite” since it provides an illustration of either total or optional/selective implementation of one, two, more or all of the distinguishing aspects of the differing embodiment and modes of Fig. 2A - 2G.

[00051] In various example embodiment and modes the Si-based power management controller 34 determines, from the broadcast system information, a wait period before performing the power management function. As used herein,“determines/determining ... wait period” encompasses and comprises, but is not limited to, determining and/or obtaining one or more parameters upon which a wait period depends, e.g., one or more parameters which are input to a function that determines the wait period.

[00052] In the example embodiment and mode of Fig. 2A and Fig. 3 A, the power management controller 34A of device 20A determines, from the broadcast system information, a wait period before performing termination of power grid utilization. Thus, for the example embodiment and mode of Fig. 2A and Fig. 3A, the power management function performed by power management function 30 but controlled by Si-based power management controller 34A is termination of power grid utilization. Fig. 2A and Fig. 3A show as act 34A-1 the device 20 receiving a power termination command, as act 34A-2 the Si-based power management controller 34A waiting the duration of the wait period, and as act 34A-3 the Si-based power management controller 34 A sending a signal to power management function 30 to terminate power grid utilization.

[00053] In the example embodiment and mode of Fig. 2B and Fig. 3B, the power management controller 34B of device 20B determines, from the broadcast system information, a wait period before performing resumption of power grid utilization. Thus, for the example embodiment and mode of Fig. 2B and Fig. 3B, the power management function performed by power management function 30 but controlled by Si-based power management controller 34B is resumption of power grid utilization. Fig. 2B and Fig. 3B show as act 34B-1 the device 20 of the second embodiment 20B receiving a power resumption command, as act 34B-2 the SI- based power management controller 34B waiting the duration of the wait period, and as act 34B-3 the Si-based power management controller 34B sending a signal to power management function 30 to resume power grid utilization. [00054] In the example embodiment and mode of Fig. 2C and Fig. 3C, the power management controller 34C of device 20C determines, from the broadcast system information, a wait period before performing device power-up, e.g., start-up of power grid utilization. Thus, for the example embodiment and mode of Fig. 2C and Fig. 3C, the power management function performed by power management function 30 but controlled by Si-based power management controller 34C is start-up of power grid utilization. Fig. 2C and Fig. 3C show as act 34C-0 the device 20C receiving a power-up command, which may be received, e.g., from a device user interface or from server(s) 26. As act 34C-1 the Si-based power management controller 34C checks if device 20C is experiencing a power avoidance event. As used herein, experiencing a“power avoidance event” comprises the Si-based power management controller 34C receiving a notification, e.g., based on broadcast system information, that the device 20C should avoid power grid utilization, including avoiding power grid utilization upon start up.

As such, for the Si-based power management controller 34C of Fig. 2C and Fig. 3C, the power avoidance is a power-up delay event. After end of the“power avoidance event” (also known as power-up delay event), as act 34C-2 the Si-based power management controller 34C waits the duration of the wait period before issuing a signal to power management function 30 to commence actual start-up of power grid utilization (to actual power up the device 20C). If it is determined as act 34C-1 that the device 20C is not experiencing a power avoidance event, then the Si-based power management controller 34C proceeds directly without wait to commence actual start-up of power grid utilization (as 34C-3).

[00055] In the example embodiment and mode of Fig. 2D and Fig. 3D, the power management controller 34D of device 20D determines, from the broadcast system information, a wait period before performing its power management function, but also determines if the device 20D is requested to be attached to the radio access network node 60 before commencing the wait period. Fig. 2D and Fig. 3D show as act 34D-0 the device 20D receiving a power management command. Depending on its nature, the power management command may be received either from radio access network node 60 or from server(s) 26. The power management command of act 34D-0 may be, in differing scenarios, either the power termination command (see Fig. 2A), the power resumption command (see Fig. 2B), or the power start-up command (see Fig. 2C), as non-limiting examples. As act 34D-1 the Si-based power management controller 34D checks if device 20D has been requested to post-pone implementation of the power management function corresponding to the power management command, and whatever wait period may be applicable, until the device 20D is attached to the radio access network node 60. As used herein,“attach” or“attachment” is understood from Figure 5.2.2-1: RRC IDLE Cell Selection and Reselection in TS 36.304, from which it is understood that“Detached” is when the UE is in“Any Cell Selection State”, and“Attached” is when the UE is not in“Any Cell Selection State”. After the end of an attachment procedure, e.g., after it is confirmed that device 20D is attached to radio access network node 60, as act 34D-2 the Si-based power management controller 34D imposes the wait period before issuing a signal to power management function 30 to perform (as act 34D-3) the requested power management function. If it is determined as act 34D-1 that the device 20D is attached, or that attachment is not requested or required, the Si-based power management controller 34D proceeds directly without wait to commence implementation of the power management function (as act 34D-3).

[00056] In the example embodiment and mode of Fig. 2E and Fig. 3E, the power management controller 34E of device 20E determines, from the broadcast system information, a wait period before performing its power management function, but also determines if the device 20E is requested to be connected to the server(s) 26 before commencing the wait period. Fig. 2E and Fig. 3E show as act 34E-0 the device 20E receiving a power management command. For the example embodiments and modes of Fig. 2E and Fig. 3E, the power management command may be received from radio access network node 60. The power management command of act 34E-0 may be, in differing scenarios, either the power termination command (see Fig. 2A), the power resumption command (see Fig. 2B), or the power start-up command (see Fig. 2C), as non-limiting examples. As act 34E-1 the Si-based power management controller 34E checks if device 20E has been requested to post-pone implementation of the power management function corresponding to the power management command, and whatever wait period may be applicable, until the device 20E is connected to the server(s) 26. As used herein,“connect” or“connection”, e.g., to the server(s) 26, comprises the ability to receiving signals and/or data from the server(s) 26, either through wired or wireless channels. After the end of an connection procedure, e.g., after it is confirmed that device 20E is connected to server(s) 26, as act 34E-2 the Si-based power management controller 34E imposes the wait period before issuing a signal to power management function 30 to perform (as act 34E-3) the requested power management function. If it is determined as act 34E-1 that the device 20E is already connected to server(s) 26, or that connection to server(s) 26 is not requested or required, the Si-based power management controller 34E proceeds directly without wait to commence implementation of the power management function (as 34E-3).

[00057] In the example embodiment and mode of Fig. 2F, the power management controller 34F of device 20F determines, from broadcast system information, whether any wait period (also communicated in the broadcast system information) is applicable to the device 20F. As a non-limiting example depiction, Fig. 2F shows that system information 70 broadcasted from radio access network node 60 comprises one or more wait parameter(s) 72 and one or more broadcast events 74. The broadcast events 74 may be, for example, public safety events or warnings, such as a weather warning (tornado, tsunami, flood, earthquake, etc.), an emergency notification (missing persons alert (e.g., amber alert), police notification (e.g., terrorist alert), or an environmental notification (e.g., toxic spill or leakage). For sake of illustration, Fig. 2F shows possible broadcast events BE1, BE2, ... BEn, with broadcast event BE2 being active or set. The Si-based power management controller 34F of Fig. 2F is configured to obtain from the broadcast system information an indication of one or more broadcast events (BE1, BE1, ... BEn), and (as act 34F-0) to determine if any one or more such indications of broadcast events corresponds to any trigger event or configuration event (CE1, CE2, ... CEm) which is configured at the device 20F. The Si-based power management controller 34F thus has access to, e.g., stored in memory 40, an indication of one or more such trigger or configuration event(s) for/to which the device 20F is affected for power grid utilization reasons. The indication of one or more such trigger or configuration event(s) may take the form of a list or a bitmap, as non-limiting examples. In the particular situation which is illustrated in Fig. 2F, it so happens that the system information 70 includes an indication of an active broadcast event BE2 (as indicated by the BE2 block of Fig. 2F being stippled), and that the device 20F is configured to be affected by the BE2 event as shown by configured event CE2 (also stippled). As further described herein, a configured or trigger event such as event CE2 may be pre-configured at (e.g., in memory 40 or processor 34F) or may be downloaded to or updated at the Si-based power management controller 34F. A dashed line in Fig. 2F further indicates that the broadcast event 74 of system information 70 of Fig. 2F is applicable to SI- based power management controller 34F of device 20F. After it is determined at act 34F-0 whether the device 20F is affected by a broadcast event(s), as act 34F-1 the device 20F receiving a power management command to perform a corresponding power management function. For the example embodiments and modes of Fig. 2F, the power management command may be received from radio access network node 60 or server(s) 26. The power management command of act 34F-1 may be, in differing scenarios, either the power termination command (see Fig. 2A), the power resumption command (see Fig. 2B), or the power start-up command (see Fig. 2C), as non-limiting examples. Then, if it is determined at act 34F-0 that the device 20F is affected by one or more broadcast event(s), as act 34F-2 the Si-based power management controller 34F imposes the wait period before issuing a signal to power management function 30 to perform (as act 34F-3) the corresponding requested power management function.

[00058] As explained herein with further reference to the consolidated example embodiment and mode of Fig. 5, in an example, non-limiting implementation the Si-based power management controller 34F may be configured to obtain the indication of one or more public safety events from either system information block 10 (SIB 10) or system information block 12 (SIB12) of the broadcast system information.

[00059] In the example embodiment and mode of Fig. 2G, the power management controller 34G of device 20G is configured to obtain two parameters from the broadcast system information used by the processor circuitry to determine the wait period. As a non-limiting example depiction, Fig. 2G shows that system information 70 broadcasted from radio access network node 60 comprises one or more wait parameter(s) 72. In particularly, the non-limiting example depiction of Fig. 2G shows the wait parameter(s) 72 as comprising plural parings 76 of a first parameter and a second parameter, and wherein for each parameter pair 76 the first parameter is a wait factor and the second parameter is a wait time. As explained further in conjunction with the example consolidated example embodiment and mode, in an non-limiting implementation the Si-based power management controller 34G is configured to use the wait factor and the wait time of a selected one of the parameter pairings 76 as inputs for a random determination of the wait period.

[00060] In an example embodiment and mode the Si-based power management controller 34G may be configured to utilize a configured one of the plural pairings 76 to obtain the wait factor and the wait time. For example, in the Fig. 2G illustration, the Si-based power management controller 34G is configured to select the two parameters from the first the parameter pairings that actually contains the two parameters wait factor and wait time. In the illustration of Fig. 2G, the first pairing 76i is the first of the plural parameter pairings 76 to actually contain parameter values. It should be understood that in some situations not all of the parameter pairings 76 may include content, e.g., that some of the parameter pairings 76 may be empty. In the situation of the Si-based power management controller 34G being configured to select the first parameter pairing 76 with actual content, should the first parameter pairing 76i be empty, the Si-based power management controller 34G would, in numerical order, select the next of the parameter pairings 762 - 765 that includes parameter.

[00061] Moreover, it should be understood that the configuration of Si-based power management controller 34G may change or otherwise be configured to select another one of the parameter pairings 76 (e.g., the second one of the parameter pairings 76 that has actual content, rather than the first of the parameter pairings 76 that has actual content). In fact, which of the parameter pairings, e.g., first parameter paring, second parameter paring, or other parameter paring selection criteria, may be configured at the device 20 (e.g., at the Si-based power management controller). Such configuration of parameter paring selection criteria, or logic for selecting a parameter paring, may be pre-configured, or may be downloaded or otherwise communicated to the device 20, e.g., by or from server(s) 26 . For example, an algorithm that selects ac-BarringF actor and ac-BarringTime from one of the plurality of IE in the SIB2 that contained that information may be configured such that a specific IE (e.g. ssac- BarringForMMTEL-Video-r9) is associated with a specific device (e.g., a security monitor), and that the ac-BarringF actor and ac-BarringTime associated with that specific IE is selected for use by a specific type of device. [00062] Thus, as described above, one or more server(s) 26 may generate a parameter paring selection criteria signal to send to the device(s) 20. The parameter paring selection criteria signal comprises an indication of which of plural possible parameter parings are to be utilized by an electronically controlled device 20 in conjunction with a power management function performed by the electronically controlled device. As understood from the foregoing, the power management function may comprise termination of grid power utilization by the electronically controlled device. Each of the plural possible parameter parings may comprise a wait factor as a first parameter of the pair and a wait time as a second parameter of the pair.

The server(s) 26 comprise hardware or processor circuitry for generating the parameter paring selection criteria signal (such as processor 90 of Fig. 4) and a communications interface (such as interface 27 of Fig. 1) or interface 96 of Fig. 4 for transmitting the parameter paring selection criteria signal to the electronically controlled device. As indicated above, the communications interface may be hardwired or wireless. As also explained above, in an example embodiment and mode the processor circuitry of the server(s) 26 may be configured to generate the parameter paring selection criteria signal dependent upon type of electronically controlled device to which the parameter paring selection criteria signal is transmitted.

[00063] Thus, Fig. 2G shows as act 34G-0 the Si-based power management controller 34G obtaining two parameters from the broadcast system information used by the processor circuitry to determine the wait period. Act 34G-1 comprises the Si-based power management controller 34G making a determination of the wait period using the two parameters. As mentioned above, in making the determination of the wait period the Si-based power management controller 34G may use the wait factor and the wait time of a selected one of the parameter pairings 76 as inputs for a random determination of the wait period, as depicted by randomization function 78. [00064] As act 34G-2 the device 20G receives a power management command to perform a corresponding power management function. For the example embodiments and modes of Fig. 2G, the power management command may be received from radio access network node 60 or server(s) 26. The power management command of act 34G-2 may be, in differing scenarios, either the power termination command (see Fig. 2A), the power resumption command (see Fig. 2B), or the power start-up command (see Fig. 2C), as non limiting examples. As act 34G-3 the Si-based power management controller 34G imposes the wait period before issuing a signal to power management function 30 to perform (as act 34G-4) the corresponding requested power management function. [00065] Certain units and functionalities of device 20 and/or server(s) 26 are, in example embodiments, implemented by electronic machinery, computer, and/or circuitry. For example, the processor circuitry 38 of the example embodiments of devices 20 and processor circuitry of server(s) 26 herein described and/or encompassed may be comprised by the computer circuitry of Fig. 4. Fig. 4 shows an example of such electronic machinery or circuitry, whether node or terminal, as comprising one or more processor(s) circuits 90, program instruction memory 92; other memory 94 (e.g., RAM, cache, etc.); input/output interfaces 96; peripheral interfaces 98; support circuits 99; and busses 100 for communication between the aforementioned units.

[00066] The program instruction memory 92 may comprise coded instructions which, when executed by the processor(s), perform acts including but not limited to those described herein. Thus is understood that each of device 20 and servers 26, for example, may comprise memory in which non-transient instructions are stored for execution.

[00067] The memory 94, or computer-readable medium, may be one or more of readily available memory such as random access memory (RAM), read only memory (ROM), floppy disk, hard disk, flash memory or any other form of digital storage, local or remote, and is preferably of non-volatile nature. The support circuits 99 are coupled to the processors 90 for supporting the processor in a conventional manner. These circuits include cache, power supplies, clock circuits, input/output circuitry and subsystems, and the like.

[00068] Fig. 5 shows various data flows and computer program routines that may be associated with a consolidated example embodiment and mode of an electronically controlled device 20 that obtains a wait period from broadcast system information, and which may selectively implement one or more (in any desired combination) of the distinctive differing aspects of the example embodiments and modes of Fig. 2A - Fig. 2G. The data flows and computer program routines of Fig. 5 involve a first data flow depicted by Fig. 6; a second data flow depicted by Fig. 7; basic acts comprising a routine executed by an application programmable interface (RRC Msg API routine) are depicted by Fig. 8.

[00069] In conjunction with the application programmable interface routine

(RRC Msg API) depicted by Fig. 8, basic acts comprising a SIBl Msg subroutine are depicted by Fig. 8-1; basic acts comprising a SIB2_Msg subroutine are depicted by Fig. 8-2A and Fig. 8-2B; basic acts comprising a SIBlO Msg subroutine are depicted by Fig. 8-3; and basic acts comprising a NAS_Msg subroutine are depicted by Fig. 8-4A and Fig. 8-4B.

[00070] Fig. 9 shows basic introductory acts comprising a process logic routine executed by Si-based power management controller 34, with Fig. 9-1 through Fig. 9-4 showing further basic acts comprising initialization subroutines including an initialize working variables subroutine of Fig. 9-1; a Get ROM Cfg Data subroutine of Fig. 9-2A and Fig. 9-2B; a Get_NV_Cfg_Data subroutine of Fig. 9-3; and a GET NV_PWS_Wait_State subroutine of Fig 9-4. [00071] Fig. 10A and Fig. 10B show basic substantive acts comprising a process logic routine executed by Si-based power management controller 34, while Fig. 10-1 shows basic acts comprising an Attach_Wait subroutine; Fig. 10-2 shows basic acts comprising a

Server_Wait subroutine; Fig. 10-3A and Fig. 10-3B show basic acts comprising a PWS_Wait subroutine; and Fig. 10-4 shows basic acts comprising a Delay_Change_Wait subroutine. [00072] The example consolidated embodiment and mode of Fig. 5 involves data flows such as shown in Fig. 6 and Fig. 7, and comprises a Power Management Life Cycle System configured to provide aspects of the technology disclosed herein. In Fig. 6 and Fig. 7, a LTE eNB or NR gNB may correspond, for example, to radio access network node 60 of Fig. 1; an LTE/NR UE RxTx Device may correspond to radio network interface 52 of Fig. 1; the Power Management Life Cycle System may correspond to Si-based power management controller 34 of Fig.1; a Device Power Control Logic may correspond to power management function 30 of Fig. 1 ; a ROM may correspond to ROM 42 of Fig. 1; and a Non-Volatile Memory may correspond to non-volatile memory (NV-memory) 44 of Fig. 1.

[00073] The“Power Management Life Cycle System” (“PMLCS”) of the consolidated example embodiment and mode is configured to manage the functionality expressed by device 20 as associated with the receipt, and though receipt-end, of a message or command (such as that labeled in LTE/New Radio (NR) Public Warning System (PWS) Message) that would trigger, for example, a“Power Down” event. By way of non-limiting example, such command(s) or message(s) may be received through the application programmable interface of Fig. 8. A PWS message may include ETWS and CMAS messages, and as used herein the term “PWS Message” may refer to one or the other or both types of messages. The Power

Management Life Cycle System determines when to signal to the“Device Power Control Logic” (aka Controlled Device) the transition of a variable“Device Power State” from Low to Normal, and vise-versa. As mentioned above, the Power Management Life Cycle System may be implemented by a Si-based power management controller 34, and may particularly illustrate the routines described herein including the routines of Fig. 8 and Fig. 10.

[00074] The Power Management Life Cycle System may set the Device Power State variable to Low upon The Device system power on, and then upon determining that there are no PWS Messages received by an“LTE Device” that would trigger The Device to action, set the Device Power State variable to Normal, as understood (for example) with reference to Fig. 2C and Fig. 3C.

[00075] The Power Management Life Cycle System may set the Device Power State variable to Low upon initial receipt of the PWS Message from an“LTE Device” (such as radio access network node 60) that would trigger The Device to action, maintain the Device Power State through the period that the PWS Message is continuously received, maintain the Device Power State through to the termination of that PWS Message, and maintain the Device Power State for a period of time following the termination of the PWS Message. [00076] The RRC Msg API routine of Fig. 8 may run independently of the LTE/NR UE Device, but can share data objects such as RRC Msg Event and RRC Msg Data. The RRC Msg API routine of Fig. 8 may run independently of the System and Life Cycle for Power Mgmt. of IoT Device (e.g., Si-based power management controller 34) and the PWS Message Logic, but can share data objects such as Cfg_Data and PWS_State. When the LTE/NR UE RxTx Device (e.g., radio network interface 52) receives a RRC message, it will send to RRC_Msg_ API an“RRC Msg Event” and RRC Msg Data which holds the received message(s). As understood from Fig. 8, messages particularly of interest are messages which include system information block (SIB) 1 (which are handled by the subroutine of Fig. 8-1); messages which include system information block (SIB) 2 (which are handled by the subroutine of Fig. 8-2); messages which include system information block (SIB) 10 or 12 (which are handled by the subroutine of Fig. 8-3); and non-access stratum (NAS) messages (which are handled by the subroutine of Fig. 8-4A and Fig. 8-4B).

[00077] As indicated above, a system information block (SIB) 1 is handled by the subroutine of Fig. 8-1. Scheduling information for SIBs (other SIB1) is carried in

schedulinglnfoList. The schedulinglnfoList is contained in SystemlnformationBlockTypel . The device 20 receives ETWS notification in SIB10 according to Scheduling data in SIB1. The SIBs to be broadcast are divided into multiple schedulinginfo, each schedulinginfo may contain one or multiple SIBs. The subroutine of Fig. 8-1 searches each schedulinginfo of the schedulinglnfoList to determine if a PWS Message (i.e. SIB10) is being broadcasted by the system.

[00078] Messages which include system information block (SIB) 2 are handled by the subroutine of Fig. 8-2. A Rel-l4 SIB2 can carry five different AC-BarringConfig IEs. The subroutine of Fig. 8-2 selects one of the five, if available, per configuration data. After selecting one, the BarringF actor and BarringTime is copied into Lcl ACB Data and maybe copied into Cfg Data.

[00079] Messages which include system information block (SIB) 10 or 12 are handled by the subroutine of Fig. 8-3. If SIB10 is not being broadcast (see SIB1 processing in Fig. 8-1), then PWS State is FALSE. If SIB10 is being broadcast, then the PWS state is may be TRUE per the bit settings in the“warringType” data object in the received SIB 10.

[00080] Non-access stratum (NAS) messages are handled by the subroutine of Fig. 8-4. The subroutine of Fig. 8-4 updates Cfg data with new parameters received from the system; saves the updated copy back into Non-Volatile Memory; adjusts the Cfg_Data as necessary per configuration for ac-barringF actor and ac-barringTime received via SIB msg.

[00081] Fig. 9 shows basic introductory acts comprising a process logic routine executed by the Power Management Life Cycle System, e.g., by Si-based power management controller of the consolidated example embodiment and mode of Fig. 5. Fig. 9-1 is a routine which initializes certain working variables; Fig. 9-2 is a subroutine which obtains ROM configured data (from ROM 42); Fig. 9-3 is a subroutine which obtains configured data from the non volatile memory (NV-memory) 44; and Fig. 9-4 is a subroutine which, e.g., obtains a variable NV_PWS_Wait_State from non-volatile memory (NV-memory) 44. If there is no NV data to set the NV-PWS_Wait_State, then it is configured to FALSE. [00082] Fig. 10A and Fig. 10B shows basic substantive acts comprising a process logic routine executed by a Si-based power management controller of the consolidated example embodiment and mode of Fig. 5. The routine of Fig. 10 waits in a loop for LTE Device (e.g., radio access network node 60) to signal receipt of a PWS_Message, and then changes the Device Power State signal to the Controlled Device accordingly. In a selectively optional embodiment and mode such as that of Fig. 2F, it may be required that the PWS_Message type map to one of the Trigger_States (e.g. an Earthquake message type). The process may be selectively configured to be dependent upon any one or more of the following before signaling to the device:

• LTE Device must be attached to the eNB (see the example embodiment and mode of Fig.

2D and the subroutine of Fig. 10-1) • A wait time following the LTE Device attachment to the eNB (If the LTE Device is attached, then if configured to do so, wait for an additional amount of time, so as to provide some hysteresis to changes of the Device_Power_State and thus prevent“rattling” of that signal shared by the Controlled Device). · LTE Device having made a connection to a server (see the example embodiment and mode of Fig. 2E and the subroutine of Fig. 10-2)

[00083] The routine of Fig. 10A and Fig. 10B may ultimately invoke the subroutines of Fig. 10-1 through Fig. 10-4. The subroutine of Fig. 10-1 pertains, e.g., to the example embodiment and mode of Fig. 2D and Fig. 3D which concerns waiting for the device 20 to attach to a radio access network. The subroutine of Fig. 10-1 randomizes a wait time and then starts a background process that will initialize the timer (first parameter) with a value (second parameter) and then decrement the timer at a fixed rate (e.g. 1 per second) until it reaches zero. The subroutine then waits until the end of the eNB_Attach_Wait_Timer. If LTE device detaches from eNB while waiting, the subroutine is exited. If LTE Device is attached to the eNB while waiting, and the LTE Device receives a PWS_Message then wait for an end to the PWS_Message and then returns to restart this wait loop. If enabled to do so, then following the end of the wait, the subroutine uses the random factor to determine if the process should begin another wait time cycle.

[00084] The subroutine of Fig. 10-2 pertains, e.g., to the example embodiment and mode of Fig. 2E, which involves a wait for connection to the server(s) 26. The subroutine of Fig.

10-2 begins with a request to the LTE Device to establish a connection to the data server as identified by Cfg_Data.Server_Address. The subroutine then waits for either a connection to be established, or time out on the wait loop. If a PWS PS State is detected while waiting, the subroutine waits for the PWS PS State to end, and then returns to finish this wait loop. The subroutine also may get the address of the server from the configuration data and store into variable shared with the LTE Device. The subroutine may send an event to the LTE Device via shared data object that it should attempt to connect to the data server identified. The subroutine starts a background process that will initialize the timer (first parameter) with a value (second parameter) and then decrement the timer at a fixed rate (e.g. 1 per second) until it reaches zero. The subroutine then waits until either the end of the

SVR Connect Wait Timer or, if LTE Device detaches from eNB while waiting, then exits.

For example, if LTE Device is attached to the system while waiting, and the eNB signals it is in PWS_State, then the subroutine waits for the PWS_State to end.

[00085] The subroutine of Fig. 10-3 begins (see Fig. 10-3A) by setting the state of PWS_Wait_State to TRUE in Non-Volatile memory to preserve it in case of power cycle. The subroutine then waits until either an indication that the LTE Device is detached from the eNB, or an end to the PWS_Message. If enabled to do so after making a go/no go determination based on PWS Random F actor, the subroutine of Fig. 10-3 then randomizes a maximum wait time, and starts a background process that will initialize the timer (first parameter of the argument) with a value (second parameter of the argument) and then decrement the timer at a fixed rate (e.g. 1 per second) until it reaches zero. If configured to do so (i.e. PWS_Wait_Time != 0)..., the subroutine then waits until either the end of PWS Wait Timer or another

PWS_Message is received, in which case the subroutine goes back to the top of the subroutine and waits for PWS Message to end again. The subroutine may check if LTE Device is attached to the eNB before testing for PWS_State to prevent“stale” data from being used (e.g. if LTE Device detaches, and PWS State was TRUE, then PWS State would remain in that state until re-attach or Power Cycle). Before ending, the subroutine sets the state of

PWS_Wait_State to FALSE in Non-Volatile memory after PWS_Wait_Timer has expired.

[00086] The subroutine of Fig. 10-4 begins by randomizing the wait time. The subroutine then starts a background process that will initialize the timer (first parameter) with a value (second parameter) and then decrement the timer at a fixed rate (e.g. 1 per second) until it reaches zero. The subroutine then waits until the end of the eNB_Attach_Wait_Timer. If LTE device detaches from eNB while waiting, then the subroutine may exit. If enabled to do so, then following the end of the wait, the subroutine may use the random factor to determine if the process should begin another wait time cycle. Thus, there is a different order of operation for Random F actor and Wait Time for the subroutine of Fig. 10-4 (and some other subroutines described herein) in comparison to the subroutine of Fig. 10-3: In the subroutine PWS Wait of Fig. 10-3 Random Factor is followed by Wait time, but in the subroutine Attach Wait Wait Time is followed by Random F actor.

[00087] It should be appreciated from the foregoing that the technology disclosed herein, including the Power Management Life Cycle System, in its various embodiments and modes which may be selectively combined, provides many example features and example advantages, of which the following is a non-exhaustive list:

[00088] 1. The PMLCS may signal to the Controlled Device a Low Device Power State when the PMLCS receives from the LTE Device an indication that the LTE Device has received a PWS Message (i.e. an ETWS SystemlnformationBlockTypelO, aka SIB10, CMAS SystemInformationBlockTypel2, aka SIB 12), and the PMLCS has determined that that PWS Message maps to one or more Trigger Types configured in the Controlled Device. A Trigger Type may be, for example, an Earthquake.

[00089] 2. If the PMLCS has determined that that PWS Message maps to one or more

Trigger Types configured in the Controlled Device, and if one or more of the mapped Trigger Types also maps to an Delay Type configured in the Controlled Device, then before the

PMLCS will signal to the Controlled Device a Low Device Power State the PMLCS may wait some amount of time.

[00090] 3. Multiple Trigger Types may be used by PMLCS. The Trigger Types may be initially configured at time of The Device manufacture and may be stored as default in ROM. The Trigger Types may be individually or group reconfigured by reception of an LTE NAS message. A reconfigured Trigger Type may be stored in NV Memory. A Trigger Type stored in NV Memory may supersede the related Trigger Type stored in ROM. The PMLCS system may be disabled by configuring all Trigger Types as disabled.

[00091] 4. Multiple Delay Types may be used by PMLCS. The Delay Types may be initially configured at time of The Device manufacture and may be stored as default in ROM. The Delay Types may be individually or group reconfigured by reception of an LTE NAS message. A reconfigured Delay Type may be stored in NV Memory. A Delay Type stored in NV Memory may supersede the related Delay Type stored in ROM.

[00092] 5. After the LTE Device indicates receipt of a PWS Message and PMLCS determines that the PWS Message no longer maps to any of the configured Trigger Types (i.e. a determination), or the LTE Device indicates receipt of a SystemlnformationBlockTypel (aka SIB1) and PMLCS detects that the SIB1 no longer has SIB10 or SIB12 in its

schedulinglnfoList (i.e. a detection), and if the PMLCS is configured to do so, the PMLCS may continue to signal to the Controlled Device a Low Device Power State, and the PMLCS may wait some amount of time before its signals to the Controlled Device a Normal Device Power State. If not so configured, the PMLCS may signal to the Controlled Device a Normal Device Power State without waiting.

[00093] 6. The parameter(s) used by PMLCS to determine wait times may be

configurable. The parameters used may be per the values stored in ROM (i.e. default values) or per the values stored in NV Memory (i.e. values received via NAS message), and may be further configured to use values received from one of multiple possible SIB2 AC- BarringConfig Information Element (IE), which are not stored in NV Memory.

[00094] 7. The length of time that PMLCS will wait following the determined/detected end of PWS Message and before it signals to the Controlled Device a Normal Device Power State may be configurable. It may be configured, for example, that the there is a 90% chance that a wait period will occur, and the subsequent wait period may be a random number of seconds, for example, between 0 and 32. Following the first wait, there may be again another 90% chance that a second wait between 0 and 32 seconds will occur... .etc. until a 10% chance event occurs that no wait period will occur and the wait ends.

[00095] 8. If the power to The Device should fail while PMLCS is waiting for the end of a PWS Message, and when the power to The Device is recovered, the PMLCS may continue to signal to the Controlled Device a Low Device Power State, and the PMLSC may resume waiting for a determined/detected end of a PWS Message. If the PMLCS should then determine/detect the end of the PWS Message, then if the PMLCS is configured to do so, the PMLCS may continue to signal to the Controlled Device a Low Device Power State, and the PMLCS may wait some amount of time before its signals to the Controlled Device a Normal Device Power State. Otherwise if the PMLCS is configured to do so, the PMLCS signals to the Controlled Device a Normal Device Power State without waiting.

[00096] 9. If the power to The Device should fail while PMLCS is waiting for the configured time after the end of the PWS Message is determined/detected, and when the power to The Device is recovered, the PMLCS may continue to signal to the Controlled Device a Low Device Power State, and the PMLCS may wait some amount of time before its signals to the Controlled Device a Normal Device Power State (i.e. PMLCS must wait the full amount of time without interruption from a PWS Message before indicating Normal).

[00097] 10. If configured to do so, the LTE Device must be“Attached” to eNB before the

PMLCS may consider signaling to the Controlled Device a Normal Device Power State. If not configured so, the PMLCS may only consider the PWS Message state before signaling to the Controlled Device the Low Device Power State.

[00098] 11. If configured to do so, the rapid transitions between Low and Normal (e.g.

Rattling of Device Power State) that may result from LTE system instability or poor RF conditions may be prevented. A wait timer is used to ensure that when the LTE Device indicates a transitions from detached to Attached, that the LTE Device remains Attached without interruption for at least some amount of time before the PMLCS may take further consideration, and before signaling to the Controlled Device a Normal Device Power State.

The wait timer may be configured with a random number of seconds, for example, between 0 and 32. Following the wait, it is configurable that there is, for example, 90% chance that a second wait between 0 and 32 seconds will occur....etc. Until a 10% chance event occurs that no wait period will occur and the wait ends.

[00099] 12. If configured to do so, then before the PMLCS will signal to the Controlled

Device a Low Device Power State the PMLCS will wait some amount of time. The wait time may be configured with a random number of seconds, for example, between 0 and 32.

Following the wait, it is configurable that there is, for example, 90% chance that a second wait between 0 and 32 seconds will occur....etc. Until a 10% chance event occurs that no wait period will occur and the wait ends. [000100] 13. If configured to do so, and the LTE Device is Attached to the eNB, the

PMLCS may at time of power on attempt to connect to a server. If the PMLCS cannot connect to the server after a configurable amount of time it will signal to the Controlled Device a Low Device Power State. The PMLCS may continue to try to connect to the server and signal to the Controlled Device a Low Device Power State until a server connection is made. [000101] 14. If configured to do so, and the LTE Device is attached to the eNB, the

PMLCS may at a configurable periodicity attempt to connect to a server. If the PMLCS cannot connect to the server after a configurable amount of time it will signal to the Controlled Device a Low Device Power State. The PMLCS may continue to try to connect to the server and signal to the Controlled Device a Low Device Power State until a server connection is made. [000102] The technology disclosed herein thus provides a distribution function that distributes the actions taken by an electronically controlled device when the action is triggered by a broadcasted PWS Message. The various example embodiments and modes the distribution function takes into account the density of devices that it is trying to distribute. To account for density, in various example embodiments and modes the function may be configurable. Such configuration is not dependent upon establishment of a data channel to a server that might provide such that configuration data, since a server with an individual data channel to each individual device to (re)configure the distribution function of the device with a new data set, could potentially require millions of individual connections, which would result in inefficient use of system resources and long latency to effect a system wide

(re)configuration. Rather, an example embodiment and mode of the technology disclosed herein provides that a distribution function is configured to use the ac-BarringF actor and ac- BarringTime values carried in/by the SystemInformationBlockType2 IE. Because the SIB2 is a system broadcast IE, it can address the issues of inefficiency and latency incurred by using an individual connection to a device for the purpose of (re)configuring the distribution function.

[000103] In some of the example embodiment and modes, a distribution function uses the ac-BarringF actor and ac-BarringTime values is provided as part of a Power Management Life Cycle System. The Power Management Life Cycle System may, in its various and selectively optional aspects, address issues such as how long the device should remain in a mode triggered by a PWS Message, what the device should do after PWS Message is no longer transmitted by the system, or when it can no longer receive a PWS Message, or what the device should do when executing a mode triggered by a PWS Message and device power is lost and then restored .

[000104] Features of any one or more of the example embodiments and modes described herein may be combined with any other example embodiment(s) and mode(s) described herein.

[000105] The technology of this application thus encompasses but is not limited to the following example embodiments:

[000106] Example Embodiment 1 : An electronically controlled device configured to perform a device-native operation, the electronically controlled device comprising:

receiver circuitry configured to obtain broadcast system information from a base station node over a radio interface; processor circuitry configured to use the broadcast system information to control a power management function of the electronically controlled device.

[000107] Example Embodiment 2: The device of claim 1, wherein the processor circuitry is configured to determine a wait period before performing the power management function. [000108] Example Embodiment 3 : The device of claim 2, wherein the power management function comprises termination of grid power utilization by the electronically controlled device.

[000109] Example Embodiment 4: The device of claim 2, wherein the power management function comprises resumption of grid power utilization by the electronically controlled device.

[000110] Example Embodiment 5: The device of claim 2, wherein the power management function comprises power start-up of the electronically controlled device.

[000111] Example Embodiment 6: The device of claim 2, the processor circuitry is configured to:

determine that the electronically controlled device is attached to a node of a radio access network from which the broadcast system information is obtained; and then

impose the wait period before performing the power management function.

[000112] Example Embodiment 7: The device of claim 2, the processor circuitry is configured to:

determine that the electronically controlled device is connected to a server that transmit signals to the electronically controlled device; and then

impose the wait period before performing the power management function. [000113] Example Embodiment 8: The device of claim 1, wherein the processor circuitry is configured to obtain from the broadcast system information an indication of one or more public safety events, and wherein the processor circuitry is configured to control the power management function of the electronically controlled device when the one or more public safety events corresponds to a triggered event configured at the electronically controlled device. [000114] Example Embodiment 9: The device of claim 8, wherein the processor circuitry is configured to obtain the indication of one or more public safety events from either system information block 10 (SIB10) or system information block 12 (SIB12) of the broadcast system information. [000115] Example Embodiment 10: The device of claim 2, wherein the processor circuitry is configured to obtain two parameters from the broadcast system information used by the processor circuitry to determine the wait period, and wherein the first parameter is a wait factor and the second parameter is a wait time.

[000116] Example Embodiment 11: The device of claim 10, wherein the processor circuitry is configured to use the wait factor and the wait time as inputs for a random determination of the wait period.

[000117] Example Embodiment 12: The device of claim 10, wherein the processor circuitry is configured to obtain the two parameters from the system information block 2 (SIB2) of the broadcast system information. [000118] Example Embodiment 13: The device of claim 12, wherein system information block 2 (SIB2) of the broadcast system information comprises plural parings of a first parameter and a second parameter, and wherein the processor circuitry is configured to utilized a configured one of the plural pairings to obtain the wait factor and the wait time.

[000119] Example Embodiment 14: A method in electronically controlled device configured to perform a device-native operation, the method comprising:

using receiver circuitry to obtain broadcast system information from a base station node over a radio interface;

processor circuitry using the broadcast system information to control a power management function of the electronically controlled device. [000120] Example Embodiment 15: The method of claim 14, further comprising the processor circuitry determining a wait period before performing the power management function.

[000121] Example Embodiment 16: The method of claim 15, wherein the power management function comprises termination of grid power utilization by the electronically controlled device.

[000122] Example Embodiment 17: The method of claim 15, wherein the power management function comprises resumption of grid power utilization by the electronically controlled device. [000123] Example Embodiment 18: The method of claim 15, wherein the power management function comprises power start-up of the electronically controlled device.

[000124] Example Embodiment 19: The method of claim 15, further comprising the processor circuitry:

determining that the electronically controlled device is attached to a node of a radio access network from which the broadcast system information is obtained; and then

imposing the wait period before performing the power management function.

[000125] Example Embodiment 20: The method of claim 15, further comprising the processor circuitry: determining that the electronically controlled device is connected to a server that transmit signals to the electronically controlled device; and then imposing the wait period before performing the power management function. [000126] Example Embodiment 21: The method of claim 14, further comprising the processor circuitry obtaining from the broadcast system information an indication of one or more public safety events, and controlling the power management function of the

electronically controlled device when the one or more public safety events corresponds to a triggered event configured at the electronically controlled device.

[000127] Example Embodiment 22: The method of claim 21, further comprising the processor circuitry obtaining the indication of one or more public safety events from either system information block 10 (SIB10) or system information block 12 (SIB12) of the broadcast system information. [000128] Example Embodiment 23: The method of claim 15, further comprising the processor circuitry obtaining two parameters from the broadcast system information used by the processor circuitry to determine the wait period, and wherein the first parameter is a wait factor and the second parameter is a wait time.

[000129] Example Embodiment 24: The method of claim 23, further comprising the processor circuitry using the wait factor and the wait time as inputs for a random determination of the wait period.

[000130] Example Embodiment 25: The method of claim 23, further comprising the processor circuitry obtaining the two parameters from the system information block 2 (SIB2) of the broadcast system information. [000131] Example Embodiment 26: The method of claim 25, wherein system information block 2 (SIB2) of the broadcast system information comprises plural parings of a first parameter and a second parameter, and further comprising the processor circuitry utilizing a configured one of the plural pairings to obtain the wait factor and the wait time. [000132] Example Embodiment 27: A server comprising:

processor circuitry configured to generate a parameter paring selection criteria signal, the parameter paring selection criteria signal comprising an indication of which of plural possible parameter parings are to be utilized by an electronically controlled device in conjunction with a power management function performed by the electronically controlled device, each of the plural possible parameter parings comprising a wait factor as a first parameter of the pair and a wait time as a second parameter of the pair;

a communications interface configured to transmit the parameter paring selection criteria signal to the electronically controlled device.

[000133] Example Embodiment 28: The server of claim 27, wherein the processor circuitry is configured to generate the parameter paring selection criteria signal dependent upon type of electronically controlled device to which the parameter paring selection criteria signal is transmitted. [000134] Example Embodiment 29: The server of claim 27, wherein the power management function comprises termination of grid power utilization by the electronically controlled device.

[000135] Although the processes and methods of the disclosed embodiments may be discussed as being implemented as a software routine, some of the method steps that are disclosed therein may be performed in hardware as well as by a processor running software.

As such, the embodiments may be implemented in software as executed upon a computer system, in hardware as an application specific integrated circuit or other type of hardware implementation, or a combination of software and hardware. The software routines of the disclosed embodiments are capable of being executed on any computer operating system, and is capable of being performed using any CPU architecture. The instructions of such software are stored on non-transient computer readable media. [000136] The functions of the various elements including functional blocks, including but not limited to those labeled or described as“computer”,“processor” or“controller”, may be provided through the use of hardware such as circuit hardware and/or hardware capable of executing software in the form of coded instructions stored on computer readable medium. Thus, such functions and illustrated functional blocks are to be understood as being either hardware-implemented and/or computer-implemented, and thus machine-implemented.

[000137] In terms of hardware implementation, the functional blocks may include or encompass, without limitation, digital signal processor (DSP) hardware, reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) [ASIC], and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

[000138] In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer and processor and controller may be employed interchangeably herein. When provided by a computer or processor or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, use of the term“processor” or“controller” shall also be construed to refer to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.

[000139] The functions of the various elements including functional blocks, including but not limited to those labeled or described as“computer”,“processor” or“controller”, may be provided through the use of hardware such as circuit hardware and/or hardware capable of executing software in the form of coded instructions stored on computer readable medium. Thus, such functions and illustrated functional blocks are to be understood as being either hardware-implemented and/or computer-implemented, and thus machine-implemented. [000140] Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[000141] It will be appreciated that the technology disclosed herein is directed to solving radio communications-centric issues and is necessarily rooted in computer technology and overcomes problems specifically arising in radio communications. Moreover, in at least one of its aspects the technology disclosed herein improves the functioning of the basic function of a wireless terminal and/or node itself so that, for example, the wireless terminal and/or node can operate more effectively by prudent use of radio resources.

[000142] Although the description above contains many specificities, these should not be construed as limiting the scope of the technology disclosed herein but as merely providing illustrations of some of the presently preferred embodiments of the technology disclosed herein. Thus the scope of the technology disclosed herein should be determined by the appended claims and their legal equivalents. Therefore, it will be appreciated that the scope of the technology disclosed herein fully encompasses other embodiments which may become obvious to those skilled in the art, and that the scope of the technology disclosed herein is accordingly to be limited by nothing other than the appended claims, in which reference to an element in the singular is not intended to mean "one and only one" unless explicitly so stated, but rather "one or more." All structural, chemical, and functional equivalents to the elements of the above-described preferred embodiment that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the technology disclosed herein, for it to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. No claim element herein is to be construed under the provisions of 35 U.S.C. 112, sixth paragraph, unless the element is expressly recited using the phrase "means for."