RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional Patent Application No.

62/200,485, which was filed on August 3, 2015, the contents of which are hereby incorporated by reference as though fully set forth herein.

BACKGROUND

Long Term Evolution (LTE) and Global System for Mobile Communications (GSM) networks provide an ideal platform for Internet of Things (loT) connectivity. The extensive footprint, high reliability, and security features of these platforms can make for an ideal network to service IoT devices. Extended Coverage GSM (EC-GSM) is one proposal to extend the coverage area of existing networks to reach IoT devices. EC-GSM generally operates by repeating communications to IoT devices, which can lead to significant coverage extensions for devices, such as IoT devices, that do not require high data rate communications.

Many IoT devices perform relatively infrequent small data transmissions. For example, IoT devices may include sensor devices (e.g., a temperature sensor, a utility meter reading device, etc.) that are designed to take a measurement once a day (or once a week, etc.) and then upload the measurement. For such devices, it can be desirable to minimize energy usage of the devices and to minimize the load, imposed on the network, by such devices.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals may designate like structural elements. Embodiments of the invention are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.

Fig. 1 is a diagram illustrating an example system in which systems and/or methods described herein may be implemented;

Fig. 2 is a diagram illustrating an example process for using device periodicity information;

Fig. 3 is a diagram conceptually illustrating signal flows corresponding to a possible implementation of the process of Fig. 2;

Fig. 4 is a diagram illustrating another example process for using device periodicity information;

Fig. 5 is a diagram conceptually illustrating signal flows corresponding to a possible implementation of the process shown in Fig. 4; and

Fig. 6 illustrates, for one embodiment, example components of an electronic device.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments in accordance with the present invention is defined by the appended claims and their equivalents.

Techniques described herein relate to controlling a cellular communication device, such as an IoT device, to transition to an IDLE state, such as a General Packet Radio Service (GPRS) Mobility Management (GMM) IDLE state, after packet transmission is complete.

In one implementation, for devices that are primarily uplink only devices (e.g., IoT devices operating as remote sensors), the device may send periodicity information, relating to the expected period at which the device is likely to transmit uplink data, in a network Attach Request message. After the uplink transmission, the device may wait for a short period to receive any downlink acknowledgements (ACKs). Subsequently, the device may enter the GMM IDLE state directly from the GMM READY state. This can be performed either autonomously by the IoT device itself or based on an indicator in the downlink ACK.

Alternatively or additional ly, for devices with downlink traffic or both uplink and downlink traffic, the uplink and downlink periodicity values may be provided by the device in the Attach Request message. After receiving the uplink and downlink periodicity values, the network may indicate the length of time the device should spend in the GMM IDLE state (the "wake up period"). At the end of the wake up period, the device may wake up (i.e., transition to a GMM READY or STANDBY state) so that the device can receive the expected downlink packets. The wake up period may be indicated, by the network, as part of a network-initiated deregistration procedure. The value of the wake up period may be calculated based on the expected traffic periodicity. For uplink packet transmission, the device may wake up at any time. Fig. 1 is a diagram illustrating an example system 1 00 in which systems and/or methods described herein may be implemented. As illustrated, system 1 00 may include a number of loT devices 1 1 0, which may obtain network connectivity from cellular wireless network 120. Cellular wireless network 120 may provide access to one or more external networks, such as packet data network (PDN) 1 50. The wireless network may include radio access network (RAN) 1 30 and core network 140. Some or all of RAN 1 30 may be associated with a network operator that controls or otherwise manages core network 140. Core network 140 may include an Internet Protocol ("I P")-based network, such as a General Packet Radio Service (GPRS) core network.

IoT devices 1 10 may each include a device that may implement one or more sensing components and a communication component. The sensing component may include, for example, a temperature sensor, a humidity sensor, a light sensor, a camera, a video camera, a geo-positioning element (e.g., a GPS component), and/or other sensors that generate or monitor data that relates to the environment of a IoT device 1 10. The communication component may include a wireless or wired communication circuit that loT devices 1 10 use to transmit the sensed data to another IoT device and/or to RAN 130. For example, the communication component may include a cellular radio. IoT devices 1 10 are sometimes referred to as Machine to Machine (M2M) devices. When designed to communicate with a cellular network, an IoT device may also be referred to as a Cellular IoT (CIoT) device. In the context of a general cel lular communication device, IoT device 1 10 may also be referred to as a Mobile Station (MS) or User Equipment (UE).

Although not shown in Fig. 1 , in a typical implementation, user mobi le devices, such as cellular telephones, may be present and connect to cel lular wireless network 120. That is, wireless cellular network 120 may be operated to provide communications services to both IoT devices 1 1 0 and user mobile devices.

RAN 1 30 may represent a wireless access network for cellular wireless network 1 20. For example, RAN 130 may include base transceiver stations (BTS) 132 and one or more base station controllers (BSC) 134. BTS 132 may include equipment for transmitting and receiving radio signals (transceivers), antennas, and equipment for encrypting and decrypting communications with BSC 1 34. Typically, BTS 1 32 may include several transceivers, which may al low BTS 1 32 to serve several different frequencies and different sectors of a cell.

BTS 132 may be controlled by a parent BSC 134. BSC 134 may handle allocation of radio channels, receive measurements from the IoT devices 1 10, and controls handovers from BTS to BTS. BSC 134 may also provide data to an operation support subsystem

(OSS) as well as to performance measuring centers.

Core network 140 may include a number of network devices, including Serving

GPRS Support Node (SGSN) 142 and Gateway GPRS Support Node (GGSN) 144. SGSN 142 may include one or more computing devices that control the delivery of data packets from and/or to the IoT devices 1 10 within the geographical service area of SGSN 142.

SGSN 142 may perform packet routing and transfer, mobil ity management (attach/detach and location management), logical link management, and authentication and charging functions. SGSN 142 may maintain a location register to stores location information (e.g., current cell location data) and user profiles of all GPRS users (e.g., IoT devices 1 10 and other user devices) registered with the SGSN.

In some implementations consistent with aspects described herein, SGSN 142 may be associated with a buffer 143. Buffer 143 may include memory that is used to temporarily store (buffer) downlink data that is received for IoT devices 1 10, when the devices are in the GMM IDLE state. The operation of buffer 143 wil l be described in more detail below.

GGSN 144 may include one or more computing devices that provide for the internetworking between the GPRS network and external packet switched networks, such as PDN 1 50. GGSN 144 may convert GPRS packets coming from SGSN 142 into the appropriate packet data protocol (PDP) format (e.g., IP or X.25) and send the data out to the corresponding packet data network. In the incoming direction, PDP addresses of incoming data packets may be converted to the GSM address of the destination user, and the readdressed packets sent to the responsible SGSN 142.

PDN 1 50 may include one or more packet networks, such as an Internet Protocol (IP) based packet network. PDN 250 may include a wide area network (WAN), a local area network (LAN), and/or combinations of WANs and LANs. Application servers or other computing devices, designed to control or aggregate data from IoT devices 1 10, may be connected to PDN 250.

The quantity of devices and/or networks, i llustrated in Fig. 1 , is provided for explanatory purposes only. In practice, there may be additional devices and/or networks; fewer devices and/or networks; different devices and/or networks; or differently arranged devices and/or networks than illustrated in Fig. 1 . Alternatively, or additionally, one or more of the devices of system 100 may perform one or more functions described as being performed by another one or more of the devices of system 1 00. Furthermore, while "direct" connections are shown in Fig. 1 , these connections should be interpreted as logical communication pathways, and in practice, one or more intervening devices (e.g., routers, gateways, modems, switches, hubs, etc.) may be present.

As previously mentioned, for GPRS devices, such as IoT devices 1 10, the devices, when powered-on, may be in one of three states: GMM READY, GMM STANDBY, or GMM I DLE. Conventionally, loT device 1 1 0 may stay in the GMM READY state during data communication. The IoT device will enter the GMM STAN DBY state either after expiration of a timer (the "READY" timer) or upon receipt of an explicit request from SGSN 142 to force the device into the GMM STANDBY state. In the GMM STANDBY state, the device is known to the network at a Routing Area level of granularity. In contrast, when in the GMM READY state, IoT device 1 1 0 is tracked at the cell level (i.e., at a more specific level of granularity). A device in the GMM STANDBY state may still receive paging messages. When a downlink packet is received, by wireless network 120, for a device in the GMM STAN DBY state, wireless network 120 may indicate the presence of the downlink packet via a paging message.

IoT device 1 10, when not attached to wireless network 120, is in the GMM I DLE state. In this state, however, there is no GPRS mobility context established between IoT devices 1 1 0 and SGSN 142. Conventionally, when in the GMM I DLE state, information relating to IoT devices 1 10 is not stored at the SGSN level. In contrast, in the GMM STANDBY and READY states, a GPRS mobi lity context may be established between IoT devices 1 1 0 and SGSN 142.

As mentioned, when in the GMM STANDBY state, wireless network 120 may track IoT devices 1 1 0 at a Routing Area level of granularity. IoT devices 1 10 devices may accordingly send periodic Routing Area Update (RAU) messages. The period of the RAU messages may be controlled by the Periodic RAU Timer (the "T33 12" timer) wh ich, by default, is set to approximately 54 minutes at the IoT devices. On the network side, wireless network 1 20 may maintain a "mobile reachable timer." When the mobi le reachable timer expires without communication from IoT device 1 10, then the device is considered "not reachable" and detached from the network by setting the device to the GMM I DLE state. Since most networks expect to communicate with IoT device 1 1 0 every few hours, the value of mobi le reachable timer is typically set to few minutes more than the value of the Periodic RAU timer.

Conventional operation of wireless network 120, as discussed in the previous paragraph, may include at least two potential issues. First, for IoT devices 1 10 that have infrequent and small data transmissions (e.g., no traffic for several hours or even days), performing Periodic RAUs every 54 minutes can consume significant energy at the device. This can be particularly troublesome for battery powered IoT devices. Second, keeping loT devices 1 10 registered, with the network, can require a lot of network resources, which can be challenging for the network operator, especially when large numbers of IoT devices are deployed.

In one implementation, consistent with aspects described herein, for IoT devices with relatively long periods between communications, the device may be forced to the GMM idle state after data transmission is complete. This may be particularly useful for, in EC-GSM systems, IoT applications that exhibit periodicity, such as smart meters, smart agriculture devices, and smart city devices. The periodicity value, or "inter-data arrival time", can range from several minutes to several days (or more).

Fig. 2 is a diagram illustrating an example process 200 for using device periodicity information. Process 200 may be particularly appropriate for uplink centric devices. The uplink centric device may be an IoT device that predominantly operates to upload data to wireless network 120. For example, IoT sensor devices may be uplink centric devices. Process 200 may be implemented by, for example, IoT device 1 10.

Process 200 may include attaching to the network (block 210). IoT device 1 1 0 may begin in the GMM I DLE state. As part of the operation of IoT device 1 10, IoT device 1 10 may obtain data that is to be uploaded to wireless network 120. For example, IoT device 1 1 0 may be a meter that periodically (e.g., once a week) uploads a measurement value corresponding to the meter reading. The estimated periodicity of the data may be transmitted, as part of the attachment process, to network 120 (e.g., to SGSN 142). In one implementation, the periodicity value may be transmitted as part of an Attach Request message sent from IoT device 1 1 0 to wireless network 120 (block 210). For instance, consistent with aspects described herein, a field, such as a field labeled as

"P T INTER ARRIVAL," may be included in the Attach Request message, along with the corresponding periodicity value.

IoT device 1 10 may obtain the periodicity value, or an estimate of the periodicity value, from a number of possible sources. For example, the periodicity value may be obtained from an application layer process at IoT device 1 1 0. The application layer process may measure the periodicity value (e.g., based on historical data transfers made by IoT device 1 10) and/or receive the periodicity value from another source (e.g., as part of provisioning or initial setup of loT device 1 10). Alternatively, in some implementations, the periodicity value for IoT device 1 10 may be transmitted, to wireless network 120, from another device, such as an IoT device management application that connects to PDN 1 50.

In some implementations, the indication of the uplink periodicity may be an indication, to SGSN 142, that the IoT device will operate in an "energy savings" mode in which the IoT device will transition to the GMM IDLE state immediately after completing the uplink transmission for the device. Some IoT devices may be capable of operating in either "energy savings" mode or "normal" mode. An application server or other IoT management server may control, such as via downlink commands transmitted to the IoT device, the operating mode of the IoT device.

Process 200 may further include performing packet data transmission (block 220).

That is, IoT device 1 10 may transmit data, in the uplink direction, to wireless network 120 (e.g., to SGSN 142). The sensor data, or other data obtained by IoT device 1 10, may thus be communicated to an application server or other computing device designed to receive the output of IoT device 1 10.

Process 200 may further include waiting, while still in the GMM READY state, to receive any downlink acknowledgments (ACKs) from the wireless network (block 230). For example, after packet data transmission has been performed to upload the data obtained by IoT device 1 10, IoT device 1 10 may wait a relatively short period (e.g., on the order of seconds) to receive downlink ACK(s) from SGSN 142. At the conclusion of the waiting period, the IoT device may directly enter the GMM IDLE state (block 240). In one implementation, IoT device 1 10 may initiate a Detach Request procedure, with SGSN 142, to detach itself from wireless network 120 (and to thus enter the GMM I DLE state). Alternatively, SGSN 240, in response to receiving the uplink periodicity value, may initiate the Detach Request procedure with IoT device 1 10. For example, SGSN 240, in response to receiving the "PKT INTER ARRIVAL" field in the Attach Request message, may initiate the Detach Request procedure at the conclusion of the packet data transfer.

In some implementations, SGSN 142, based on reception of the

"PKT INTER ARRIVAL" field, may, while IoT device 1 10 is in the GMM I DLE state, continue to buffer, using buffer 143, any received downl ink data for IoT device 1 1 0. For instance, SGSN 142 may store downlink data, such as packets received from PDN 1 50 and destined for IoT device 1 1 0. When IoT device 1 10 reattaches to the network (e.g., at the time indicated by the periodicity value), SGSN 142 may transmit the buffered data to IoT device 1 10. In some implementations, SGSN 142 may use the periodicity value to determine when to delete the buffer for IoT device 1 1 0. For instance, if IoT device 1 1 0 does not reattach at the expiration of the periodicity value, or at the expiration of the periodicity value plus some margin, SGSN 142 may delete or clear the buffer for IoT device 1 10, thus potentially conserving network resources.

Fig. 3 is a diagram conceptually illustrating signal flows corresponding to a possible implementation of process 200. As illustrated, IoT device 1 10 may attach to wireless network 120 based on the communication of an Attach Request message to SGSN 142 (at 3 10). The Attach Request message may include an indication of the estimated or expected periodicity of the uplink data from IoT device 1 10. Additionally, or as part of the Attach Request, IoT device 1 10 may request to activate a packet data protocol (PDP) context (i.e., IoT device 1 1 0 may request a PDP session).

SGSN 142 may accept the attach request (at 320). At this point, IoT device 1 10 may be in the GMM READY state and may perform packet data transmissions (at 330). The packet data transmission may be used to, for example, upload sensor measurements or other data generated by IoT device 1 10.

At the conclusion of the packet data transmission, and potentially after a relatively short period (e.g., long enough for IoT device 1 10 to receive any downlink

acknowledgement packets from SGSN 142), IoT device 1 10 may detach from wireless network 120 (at 340). That is, IoT device 1 10 may thus transition from the GMM READY state to the GMM IDLE state. As shown, the detach procedure may be initiated by SGSN 142. Alternatively, in some implementations, instead of the detach procedure being implemented by SGSN 142, the detach procedure may be implemented by IoT device 1 10 (e.g., IoT device 1 10 may signal SGSN 142 to initiate the detach).

The concepts described with respect to Figs. 2 and 3 may be useful for IoT devices that are predominantly or exclusively uplink devices. Consistent with the concepts described with respect to Figs. 2 and 3, uplink IoT devices can enter the GMM I DLE state shortly after transmitting data, potentially saving energy at the IoT device and reducing the network resources required to service the IoT device.

For devices with downlink traffic or both uplink and downlink traffic, the device may not autonomously decide to go to GMM I DLE since the network may need to page the devices if there is downlink traffic. Forcing the devices to GMM I DLE may make them unreachable by the network. In an alternative implementation, for these devices, wireless network 1 20 may communicate wakeup timing information (the wake up period) to the IoT devices. Fig. 4 is a diagram i llustrating an example process 400. Process 400 may be particularly appropriate for devices with downlink traffic or both uplink and downlink traffic. Process 200 may be implemented by, for example, IoT device 1 10.

Process 400 may include attaching to the network (block 410). As part of the attachment process, an indication of the uplink and downlink periodicity of the IoT device may be transmitted to the network (block 410). In one implementation, the periodicity values may be transmitted as part of the Attach Request message sent from IoT device 1 10 to wireless network 120. For instance, consistent with aspects described herein, two fields, such as fields labeled as "P T INTER ARRI VAL UL" and

"PC INTER ARRIVAL DL" may be included in the Attach Request message, along with the corresponding periodicity values.

IoT device 1 10 may obtain the periodicity values, or an estimate of the periodicity values, from a number of possible sources. For example, the periodicity values may be obtained from an application layer process at IoT device 1 1 0. The application layer process may measure the periodicity values (e.g., based on historical uplink and downlink data transmissions periods) and/or receive the periodicity value from another source (e.g., as part of provisioning or initial setup of IoT device 1 10). Alternatively, in some implementations, the periodicity values for IoT device 1 1 0 may be transmitted, to wireless network 120, from another device, such as an IoT device 1 1 0 management application that connects to PDN 150 or an edge analytics device. The uplink periodicity value may provide an estimate of the period between uplink transmissions for the IoT device and the downlink periodicity value may provide an estimate of the period between downlink communications directed at the IoT device.

Process 400 may further include performing packet data transmission (block 420). That is, IoT device 1 1 0 may transmit data, in the uplink direction, or receive data, in the downlink direction, with wireless network 120 (e.g., with SGSN 142). For downl ink data, sensor data, or other data obtained by IoT device 1 10, may be communicated to an appl ication server or to another computing device designed to receive the output of IoT device 1 1 0. Similarly, the application server, or other computing device, may

communicate control information, configuration information, or other data, to IoT device 1 1 0.

Process 400 may further include receiving a detach request message from the network (block 430). Detach Request message may include, or be associated with, an indication of when the IoT device should wake up (block 430). The Detach Request message may be transmitted, by the network, at the end of the packet data transmission (i.e., at the end of the uplink/downlink transmissions). The indication of when IoT device 1 1 0 should wake up may be communicated via a field, such as a

"WAKE_UP_TIM ING_INFO" field, communicated with the Detach Request message. The value of the field may indicate the when IoT device 1 10 should wake up from the GMM I DLE state (e.g., the value of the field may indicate the wake up period for the IoT device). For example, the field may indicate a certain length of time (e.g., one hour, one day, etc.) that IoT device 1 10 should spend in the GMM IDLE state or a particular date/time at which IoT device 1 10 should wake up. The value for the field may be determined, by SGSN 142, based on the expected periodicity of downlink traffic for IoT device 1 10. For example, the value of the field may be set to the value of the

"PKT INTER ARRIVAL DL" field. Alternatively, other values can be used, such as values based on the value of "PKT INTER ARRIVAL DL," based on network specific information (e.g., congestion or based on a desire to schedule packet transmissions at off- peak periods), and/or based on information received from an application server or other device that controls or manages IoT device 1 10.

Process 400 may include entering the GMM IDLE state (block 440). For instance, in response to the detach request message, IoT device 1 10 enter the GMM I DLE state directly from the GMM READY state. While IoT device 1 10 is in the GMM I DLE state, SGSN 142 may buffer downlink data received for IoT device 1 10. In some

implementations, SGSN 142 may buffer the downlink data until the scheduled wake up time (e.g., as indicated via the "WAKE_UP_TIMING_INFO" field) from the GMM I DLE state. SGSN 142 may delete the buffered data, for the particular IoT device, if the wake up time passes without the IoT device attaching to SGSN 142.

Process 400 may further include reattaching to the network based on the wake up indication (block 450). IoT device 1 10, at the scheduled wake up time, may initiate an Attach Request procedure to reattach to the network and enter the GMM READY state. Alternatively or additionally, IoT device 1 10 may reattach to wireless network 120 when the device has uplink data to transmit.

Fig. 5 is a diagram conceptually i llustrating signal flows corresponding to a possible implementation of process 400. As illustrated, IoT device 1 1 0 may attach to wireless network 1 20 based on the communication of an Attach Request message to SGSN 142 (at 5 10). The Attach Request message may include an indication of the estimated or expected periodicity of the uplink and downlink data associated with IoT device 1 10. Additionally, or as part of the Attach Request, IoT device 1 10 may request to activate a PDP context (i.e., IoT device 1 10 may request a PDP session).

SGSN 142 may accept the attach request (at 520). At this point, IoT device 1 10 may be in the GMM READY state and may perform packet data transmissions (at 530). The packet data transmission may be used to, for example, upload sensor measurements or other data generated by IoT device 1 10. SGSN 142 may also transmit, to IoT device 1 10, any downlink data that is destined for IoT device 1 10, such as downlink data that was buffered by SGSN 142 while IoT device 1 10 was in the GMM I DLE state, or "live" downlink data that is received from an application server or other device that is attempting to communication with IoT device 1 1 0.

At the conclusion of the packet data transmission, IoT device 1 1 0 may detach from wireless network 120. IoT device 1 1 0 may detach in response to SGSN 142 initiating the attachment, including SGSN 142 transmitting, to IoT device 1 1 0, an indication of when IoT device 1 1 0 should wake up (at 540). In response, IoT device 1 10 may detach from the network and enter the GMM I DLE state. IoT device may store the an indication of when IoT device 1 1 0 should wake up, and use the indication to schedule the next network attachment.

The concepts described with respect to Figs. 4 and 5 may be useful for IoT devices that receive downlink data. Consistent with the concepts described with respect to Figs. 2 and 3, IoT devices wake up periods for IoT devices can be scheduled to match the uplink and/or downlink periodicity of the IoT device. The IoT device can enter the GMM I DLE state when not actively communicating data at a time specified by the uplink/downlink periodicity. I n this manner, the time spent in the GMM IDLE state can be maximized, potentially saving energy at the IoT device and reducing the network resources required to service the IoT device.

As used herein, the term "circuitry" or "processing circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware. Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. Fig. 6 illustrates, for one embodiment, example components of an electronic device 600. In embodiments, the electronic device 600 may be a user equipment (UE), an evolved NodeB (eNB), a IoT device, a CIoT device, a mobile station (MS), or some other appropriate electronic device. In some embodiments, the electronic device 600 may include application circuitry 602, baseband circuitry 604, Radio Frequency (RF) circuitry 606, front-end module (FEM) circuitry 608 and one or more antennas 660, coupled together at least as shown.

The application circuitry 602 may include one or more application processors. For example, the application circuitry 602 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/or may include memory/storage, such as storage medium 603, and may be configured to execute instructions stored in the memory /storage to enable various applications and/or operating systems to run on the system. In some implementations, storage medium 603 may include a non-transitory computer-readable medium. Application circuitry 602 may, in some embodiments, connect to or include one or more sensors, such as environmental sensors, cameras, etc.

The baseband circuitry 604 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 604 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 606 and to generate baseband signals for a transmit signal path of the RF circuitry 606. Baseband processing circuity 604 may interface with the application circuitry 602 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 606. For example, in some embodiments, the baseband circuitry 604 may include a second generation (2G) baseband processor 604a, third generation (3G) baseband processor 604b, fourth generation (4G) baseband processor 604c, and/or other baseband processor(s) 604d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 604 (e.g., one or more of baseband processors 604a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 606. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some implementations, baseband circuitry 604 may be associated with storage medium 603 or with another storage medium. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 604 may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 604 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments. In some embodiments, the baseband circuitry 604 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol

(PDCP), and/or radio resource control (RRC) elements. A central processing unit (CPU) 604e of the baseband circuitry 604 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 604f. The audio DSP(s) 604f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.

The baseband circuitry 604 may further include memory/storage 604g. The

memory/storage 604g may be used to load and store data and/or instructions for operations performed by the processors of the baseband circuitry 604. Memory/storage for one embodiment may include any combination of suitable volatile memory and/or non-volatile memory. The memory/storage 604g may include any combination of various levels of memory/storage including, but not limited to, read-only memory (ROM) having embedded software instructions (e.g., firmware), random access memory (e.g., dynamic random access memory (DRAM)), cache , buffers, etc. The memory/storage 604g may be shared among the various processors or dedicated to particular processors.

Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some

embodiments, some or all of the constituent components of the baseband circuitry 604 and the application circuitry 602 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 604 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 604 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 604 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 606 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 606 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 606 may include a receive signal path which may include circuitry to down-convert RF signals received from the FE circuitry 608 and provide baseband signals to the baseband circuitry 604. RF circuitry 606 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 604 and provide RF output signals to the FEM circuitry 608 for transmission.

In some embodiments, the RF circuitry 606 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 606 may include mixer circuitry 606a, amplifier circuitry 606b and filter circuitry 606c. The transmit signal path of the RF circuitry 606 may include filter circuitry 606c and mixer circuitry 606a. RF circuitry 606 may also include synthesizer circuitry 606d for synthesizing a frequency for use by the mixer circuitry 606a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 606a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 608 based on the synthesized frequency provided by synthesizer circuitry 606d. The amplifier circuitry 606b may be configured to amplify the down-converted signals and the filter circuitry 606c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals.

Output baseband signals may be provided to the baseband circuitry 604 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 606a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 606a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 606d to generate RF output signals for the FEM circuitry 608. The baseband signals may be provided by the baseband circuitry 604 and may be filtered by filter circuitry 606c. The filter circuitry 606c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect. In some embodiments, the mixer circuitry 606a of the receive signal path and the mixer circuitry 606a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upcon version respectively. In some embodiments, the mixer circuitry 606a of the receive signal path and the mixer circuitry 606a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 606a of the receive signal path and the mixer circuitry 606a may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 606a of the receive signal path and the mixer circuitry 606a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 606 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 604 may include a digital baseband interface to communicate with the RF circuitry 606.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry 606d may be a fractional-N synthesizer or a fractional N N+6 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 606d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 606d may be configured to synthesize an output frequency for use by the mixer circuitry 606a of the RF circuitry 606 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 606d may be a fractional N N+6 synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 604 or the applications processor 602 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 602. Synthesizer circuitry 606d of the RF circuitry 606 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+6 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 606d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 606 may include an IQ/polar converter.

FEM circuitry 608 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 660, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 606 for further processing. FEM circuitry 608 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 606 for transmission by one or more of the one or more antennas 660.

In some embodiments, the FEM circuitry 608 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 606). The transmit signal path of the FEM circuitry 608 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 606), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 660.

In some embodiments, the electronic device 600 may include additional elements such as, for example, memory/storage, display, camera, sensors, and/or input/output (I/O) interface. In some embodiments, the electronic device of Fig. 6 may be configured to perform one or more methods, processes, and/or techniques such as those described herein.

A number of examples, relating to implementations of the techniques described above, will next be given.

In a first example, a device may comprise a sensor to measure environmental data associated with the device; an antenna to communicate with a cellular wireless network; and circuitry to: obtain periodicity information relating to a period at which data, received from the sensor, is to be communicated to the cellular wireless network; and attach to the cellular wireless network, the attaching including transmitting the periodicity information as part of an attachment procedure.

In a second example, the subject matter of example 1 , the periodicity information may be obtained from an application layer of the device. In a third example, in the subject matter of example 1 or any of the examples described herein, the transmission of the periodicity information includes transmitting the periodicity information as a field in an Attach Request message.

In a fourth example, in the subject matter of example 1 or any of the examples described herein, the circuitry may be further to: transmit, in response to attaching to the cellular wireless network, the data, as uplink data, to the cellular wireless network; and detach from the cellular wireless network in response to the completed transmission of the data. In a fifth example, the subject matter of example 1 or any of the examples described herein, may further include detaching from the cellular network may transitioning from a General Packet Radio Service (GPRS) Mobility Management (GMM) READY state to a GMM IDLE state. In a sixth example, in the subject matter of example 1 or any of the examples described herein, the device may be an Internet of Things (IoT) device.

In a seventh example, an Internet of Things (IoT) device may include circuitry to: attach to a cellular wireless network, the attachment including transmitting an indication that the IoT device will enter a General Packet Radio Service (GPRS) Mobi lity Management (GMM) I DLE state after data transmission; perform an uplink transmission of data, to the cellular wireless network, from the IoT device; and detach from the cellular wireless network after the uplink transmission, the detaching from the cellular wireless network being performed after completion of the uplink transmission data and including entering the GMM I DLE state.

In an eighth example, in the subject matter of example 7 or any of the examples described herein, the detachment from the cellular wireless network is performed after a time period that is selected to be long enough to receive downlink acknowledgments from the wireless cellular network. In a ninth example, in the subject matter of example 7 or any of the examples described herein, the GMM I DLE state may be entered directly from a GMM READY state. In a 10 ^lh example, in the subject matter of example 7 or any of the examples described herein, the transmitted indication includes a periodicity value relating to a period at which the IoT device will perform the uplink data transmission. In an 1 1 ^th example, in the subject matter of example 7 or any of the examples described herein, the IoT device may further include application circuitry to implement an application layer of the device, wherein the periodicity value is obtained from the application layer of the device.

In a 12 ^lh example, in the subject matter of example 7 or any of the examples described herein, the IoT device may comprise circuitry to: attach to a cellular wireless network; perform, while attached to the cellular wireless network, packet data transmission; detach from the cellular wireless network, the detaching from the cellular wireless network being performed after completion of the packet data transmission and including receiving an indication of when the IoT device should wake up from a General Packet Radio Service (GPRS) Mobi lity Management (GMM) I DLE state, and entering the GMM IDLE state; and reattaching to the cellular wireless network based on the indication of when the IoT device should wake up from the GMM IDLE state.

In a 13 ^th example, in the subject matter of example 7 or any of the examples described herein, the indication of when the IoT device should wake up includes wake up timing information that is received from the cellular wireless network. In a 14 ^th example, in the subject matter of example 7 or any of the examples described herein, the attachment may include periodicity information for uplink and downlink data. In a 15 ^th example, , in the subject matter of example 7 or any of the examples described herein, the reattachment to the cellular wireless network includes activating a default packet data protocol (PDP) context.

In a 16 ^th example, relating to the subject matter of the first, seventh, or 12 ^Ih example, the circuitry may be further to: receive downlink data, that was previously buffered by the wireless cellular network, when the device attaches the cellular wireless network. In a 1 7 ^th example, relating to the subject matter of the 16 ^th , the data may be buffered, by the cellular wireless network, for a period that is based on the periodicity of data transfer of the device. In an 18 ^th example, subject matter of the first, seventh, or 12 ^th example, the circuitry may be further to receive an indication, from the wireless cel lular network, that the device is to enter an energy savings mode. In a 19 ^th example, the subject matter of the seventh or 12 ^th examples may further relate to detachment from the cellular wireless network is initiated by a Serving GPRS Support Node (SGSN).

In a 20 ^,h example, a computer readable medium containing program instructions for causing one or more processors to: attach to a cellular wireless network, the attachment including transmitting an indication that a device will enter a General Packet Radio Service (GPRS) Mobility Management (GMM) I DLE state after data transmission; perform an uplink transmission of data to the cellular wireless network; and detach from the cellular wireless network after the uplink transmission, the detaching from the cellular wireless network being performed after completion of the uplink transmission data and including entering the GMM I DLE state.

In a 21 ^s1 example, in the subject matter of example 20 or any of the examples described herein, the detachment from the cellular wireless network is performed after a time period that is selected to be long enough to receive downlink acknowledgments from the wireless cellular network. In a 22 ^nd example, in the subject matter of example 20 or any of the examples described herein, the GMM I DLE state may be entered directly from a GMM READY state. In a 23 ^rd example, in the subject matter of example 20 or any of the examples described herein, the transmitted indication may include a periodicity value relating to a period at which an Internet of Things (IoT) device wi ll perform the uplink data transmission.

A 24 ^th example may include a computer readable medium that may contain program instructions for causing one or more processors to: attach to a cellular wireless network;

perform, while attached to the cellular wireless network, packet data transmission; detach from the cellular wireless network after, the detaching from the cellular wireless network being performed after completion of the packet data transmission and including receiving an indication of when the IoT device should wake up from a General Packet Radio Service (GPRS) Mobility Management (GMM) IDLE state, and entering the GMM IDLE state; and reattach to the cellular wireless network based on the indication of when the IoT device should wake up from the GMM I DLE state.

In a 25 ^lh example, in the subject matter of example 24 or any of the examples described herein, the attachment may include periodicity information for uplink and downlink data. In a 26 ^th example, in the subject matter of example 24 or any of the examples described herein, the reattachment to the cellular wireless network may include activating a default packet data protocol (PDP) context.

In a 27 ^lh example, in the subject matter of example 24 or any of the examples described herein, a device may comprising: means for attaching to a cellular wireless network, the attachment including transmitting an indication that the IoT device will enter a General Packet Radio Service (GPRS) Mobility Management (GMM) I DLE state after data transmission; means for performing an uplink transmission of data, to the cellular wireless network, from the IoT device; and means for detaching from the cellular wireless network after the uplink transmission, the detaching from the cellular wireless network being performed after completion of the uplink transmission data and including entering the GMM IDLE state.

In a 28 ^th example, in the subject matter of example 24 or any of the examples described herein, the detachment from the cellular wireless network is performed after a time period that is selected to be long enough to receive downlink acknowledgments from the wireless cel lular network. In a 29 ^th example, in the subject matter of example 24 or any of the examples described herein, the GMM I DLE state is entered directly from a GMM READY state. In a 30 ^th example, in the subject matter of example 24 or any of the examples described herein, the transmitted indication includes a periodicity value relating to a period at which the IoT device will perform the uplink data transmission.

In the preceding specification, various embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

For example, while series of signals have been described with regard to Figs. 3 and 5, the order of the signals may be modified in other implementations. Further, non-dependent signals may be performed in parallel. Also, while series of blocks have been described with regard to Fig. 4, the order of the blocks may be modified in other implementations. Further, non- dependent blocks may be performed in parallel.

It will be apparent that example aspects, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects should not be construed as limiting. Thus, the operation and behavior of the aspects were described without reference to the specific software code— it being understood that software and control hardware could be designed to implement the aspects based on the description herein.

Further, certain portions of the invention may be implemented as "logic" that performs one or more functions. This logic may include hardware, such as an application-specific integrated circuit ("ASIC") or a field programmable gate array ("FPGA"), or a combination of hardware and software.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.

No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. An instance of the use of the term "and," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Similarly, an instance of the use of the term "or," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Also, as used herein, the article "a" is intended to include one or more items, and may be used interchangeably with the phrase "one or more." Where only one item is intended, the terms "one," "single," "only," or similar language is used.