Scheduling transmissions of internet of things devices

Abstract

A computer-implemented method, executed by a node in a communication network, for scheduling transmissions of multiple Internet of Things (IoT) devices to network resources in the communication network, includes acquiring (402) transmission patterns of the IoT devices. The method then includes clustering (404) the IoT devices into a cluster based on the acquired transmission patterns. The method further includes scheduling (406) transmissions of IoT devices in different clusters to different network resources, thereby increasing the synchronization of transmissions scheduled on each network resource and allowing for increased periods of inactivity on the network resources between transmissions.

Description

Technical Field

[0001] This disclosure relates to methods, nodes, and systems in communication networks. More specifically, but not exclusively, this disclosure relates to scheduling transmissions from multiple Internet of Things (IoT) devices to network resources within a communication network. Background Technology

[0002] The adoption of Internet of Things (IoT) technology is rapidly increasing across many industries, such as manufacturing, automotive, and healthcare. Consequently, future communication networks (such as mobile networks) will contain many different types of connected IoT devices with varying network requirements, such as Type M (CAT-M) or Narrowband IoT (NB-IoT). These different types of connected IoT devices with varying network requirements may lead to a range of different Service Level Agreements (SLAs) for different IoT devices on the communication network.

[0003] Figure 1 As shown, depending on the technology, IoT carriers can operate within a frequency band, a guard band, or an independent location within the spectrum. For example, in Cat-M 102, devices 104 and 106 can operate within frequency band 108. For NB-IoT 110, devices can operate in independent frequency bands 112 and 114 of GSM (Global System for Mobile Communications), in the guard band 118 of LTE (Long Term Evolution) 116, or within frequency band 122 of LTE frequency band 120.

[0004] Some IoT devices use specific transmission patterns for short-duration transmissions. Communication networks need to be able to schedule these transmissions together with the "normal" transmissions associated with user equipment (UE).

[0005] As communication networks expand, energy efficiency becomes increasingly important. The embodiments described herein relate to scheduling the transmissions of multiple IoT devices within a communication network in an energy-efficient manner that optimizes network resources. Summary of the Invention

[0006] One way to save energy in communication networks is to shut down network resources (or put them into a dormant state) when not needed. This is especially important if there are many IoT devices in different deployments, such as... Figure 1 As shown, for networks with different attributes (such as frequency and transmission time) that require periodic transmission, it becomes increasingly difficult to find time periods when transmission is not required and network resources can be shut down. This can reduce the number of time periods that allow network resources to enter a sleep mode and / or shorten the length of such time periods, resulting in a "less deep" sleep state and lower energy savings.

[0007] One objective of the embodiments described herein is to provide improved scheduling of IoT transmissions to enhance energy efficiency in communication networks.

[0008] Therefore, in a first aspect, there exists a computer-implemented method, executed by nodes in a communication network, for scheduling transmissions from multiple Internet of Things (IoT) devices to network resources within the communication network. The method includes: i) acquiring transmission patterns from the IoT devices; ii) clustering the IoT devices into clusters based on the similarity of the acquired transmission patterns; and iii) scheduling transmissions from IoT devices in different clusters to different network resources, thereby increasing the synchronization of the transmissions scheduled on each network resource and allowing for increased inactivity periods on the network resources between transmissions.

[0009] In some embodiments, the method further includes selecting a new transmission mode for the IoT device, wherein the new transmission mode is predicted to cause aggregation, thereby increasing the synchronization of the transmission modes of the IoT devices in the cluster, and repeating steps ii) and iii) for the new transmission mode.

[0010] According to the second aspect, a node exists in a communication network for scheduling transmissions of multiple Internet of Things (IoT) devices to network resources within the communication network. The node includes a memory containing instruction data representing an instruction set, and a processor configured to communicate with the memory and execute the instruction set. When executed by the processor, the instruction set causes the processor to: i) acquire transmission patterns from the IoT devices; ii) cluster the IoT devices into clusters based on the acquired transmission patterns; and iii) schedule transmissions of IoT devices in different clusters to different network resources, thereby increasing the synchronization of the transmissions scheduled on each network resource and allowing for increased inactivity periods on each corresponding network resource between transmissions.

[0011] According to the third aspect, there exists a computer program comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to the first aspect.

[0012] According to the fourth aspect, there exists a carrier containing a computer program according to the third aspect, wherein the carrier includes one of an electrical signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0013] According to the fifth aspect, there exists a computer program product including a non-transitory computer-readable medium on which the computer program according to the third aspect is stored.

[0014] The embodiments described herein enable better grouping and synchronization of transmissions from IoT devices across each network resource, resulting in increased periods of inactivity where network resources can be shut down to conserve energy. By modeling and synchronizing the temporal aspects of when different clusters transmit data, the system described herein can optimize and predict when radio or radio technology can be shut down or enter sleep mode without impacting SLA or quality of service. Attached Figure Description

[0015] To better understand and more clearly illustrate how the embodiments described herein can be implemented, reference will now be made to the accompanying drawings by way of example only, wherein:

[0016] Figure 1 This illustrates the various transmission bands and protocols associated with IoT devices;

[0017] Figures 2a and 2b illustrate how resources can be scheduled according to embodiments of this document;

[0018] Figure 3 The nodes are shown according to some embodiments of this document;

[0019] Figure 4 Methods according to some embodiments of this document are illustrated;

[0020] Figure 5 The system shown is based on the example in this article; and

[0021] Figures 6a and 6b show example signaling diagrams according to example embodiments of this document. Detailed Implementation

[0022] This disclosure relates to scheduling the transmission of IoT devices on network resources in a manner that results in energy savings for network resources. Example transmission patterns for three IoT devices 202, 204, and 206 are shown in Figure 2a over time (x-axis) (top, middle, and bottom rows, respectively). Vertical slot 208 (shaded slot) indicates inactive periods during which network resources serving devices 202, 204, and 206 can be placed into sleep mode to save energy. Slot 210 (cross-shaded vertical slot) indicates shorter inactive periods where the slot may be too short to place resources into a “deep” sleep state; in some cases, the time may be too short to place resources into a sleep state at all. For example, in LTE networks, transmission subframes are 1 ms, and sleep durations are in milliseconds. For New Radio (NR), sleep slots may be less than 100 microseconds. For deep sleep states (e.g., device shutdown or cell locking), it may take up to 3 minutes to turn the cell back on. Therefore, energy savings may be less during these periods. Typically, transmission patterns result in many short idle slots that cannot be optimally utilized. One objective of the embodiments described herein is to schedule IoT device transmissions in a manner that allows for increased inactivity periods and longer durations of inactivity. This allows for increased energy savings.

[0023] More specifically, this disclosure relates to a communication network (or telecommunications network). This communication network may include any one or a combination of the following: wired links (e.g., ASDL) or wireless links, such as Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), WiFi, or Bluetooth wireless technologies. Those skilled in the art will understand that these are merely examples and the communication network may include other types of links. The wireless network may be configured to operate according to specific standards or other types of predefined rules or procedures. Therefore, specific embodiments of the wireless network may implement communication standards such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, or 5G standards; wireless local area network (WLAN) standards, such as the IEEE 802.11 standard; and / or any other suitable wireless communication standards, such as Global Microwave Access Interoperability (WiMax), Bluetooth, Z-Wave, and / or ZigBee standards.

[0024] Figure 3Network node 300 in a communication network according to some embodiments of this document is illustrated. Generally, node 300 may include any component or network function (e.g., any hardware or software module) in the communication network suitable for performing the functions described herein. For example, a node may include a device capable of, configured to, arranged to, and / or operable to communicate directly or indirectly with IoT devices or UEs (such as wireless devices) and / or with other network nodes or devices in the communication network to enable and / or provide wireless or wired access to IoT devices or UEs and / or perform other functions (e.g., management) in the communication network. Examples of nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)). Other examples of nodes include, but are not limited to, core network functions, such as those in a fifth-generation core network (5GC).

[0025] Node 300 is configured (e.g., adapted, operated, or programmed) to perform any embodiment of the methods 400 described below. It should be understood that node 300 may include one or more virtual machines running different software and / or processes. Node 300 may therefore include one or more servers, switches, and / or storage devices, and / or may include cloud computing infrastructure running software and / or processes, or infrastructure configured to perform in a distributed manner.

[0026] Node 300 may include a processor (e.g., processing circuitry or logic) 302. Processor 302 may control the operation of node 300 in a manner described herein. Processor 302 may include one or more processors, processing units, multi-core processors, or modules configured or programmed to control node 300 in a manner described herein. In certain embodiments, processor 302 may include multiple software and / or hardware modules, each configured to perform or be used to perform one or more steps of the functionality of node 300 as described herein.

[0027] Node 300 may include memory 304. In some embodiments, memory 304 of node 300 may be configured to store program code or instructions 306 that can be executed by processor 302 of node 300 to perform the functions described herein. Alternatively or additionally, memory 304 of node 300 may be configured to store any requests, resources, information, data, signals, or the like described herein. Processor 302 of node 300 may be configured to control memory 304 of node 300 to store any requests, resources, information, data, signals, etc., described herein.

[0028] It should be understood that "attached to" or "replaced" Figure 3Node 300 may include other components besides those specified in the diagram. For example, in some embodiments, node 300 may include a communication interface. This communication interface can be used to communicate with other nodes (e.g., other physical or virtual nodes) in a communication network. For example, the communication interface may be configured to send and / or receive requests, resources, information, data, signals, etc., to and from other nodes or network functions. The processor 302 of node 300 may be configured to control such a communication interface to send and / or receive requests, resources, information, data, signals, etc., to and / or from other nodes or network functions.

[0029] In summary, in one embodiment, node 300 is used to schedule transmissions from multiple Internet of Things (IoT) devices to network resources in a communication network. Node 300 is configured to: i) acquire transmission patterns from IoT devices; ii) cluster IoT devices into clusters based on the acquired transmission patterns; and iii) schedule transmissions from IoT devices in different clusters to different network resources, thereby increasing the synchronization of transmissions scheduled on each network resource and allowing for increased inactivity periods on each corresponding network resource between transmissions.

[0030] Turn now Figure 4 There exists a computer-implemented method 400 executed by a node in a communication network. This method is used to schedule transmissions from multiple Internet of Things (IoT) devices to network resources within the communication network. This method can be executed by a node in the communication network, such as node 300 described above.

[0031] In summary, in the first step 402, the method includes i) acquiring the transmission pattern of transmissions from IoT devices. In the second step 404, the method includes ii) clustering IoT devices into a cluster based on the acquired transmission pattern. In the third step, the method includes iii) scheduling transmissions from IoT devices in different clusters to different network resources, thereby increasing the synchronization of transmissions scheduled on each network resource and allowing for increased periods of inactivity on network resources between transmissions.

[0032] As mentioned above, scheduling transmissions in this manner results in more inactive periods between transmissions, and thus more opportunities for network resources to be shut down or enter a dormant state. Furthermore, the duration of these inactive periods may be longer, allowing network resources to enter a “deeper” dormant state. This leads to energy savings in network resources. For reference, different dormant states are described in Annex 1.

[0033] More specifically, an IoT device can include a device that is capable of, configured to, arranged to, and / or operable to wirelessly communicate with network nodes and / or other wireless devices. An Internet of Things (IoT) device can represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to other user equipment (UE) and / or network nodes. IoT devices can include machine-to-machine (M2M) devices, which may be referred to as MTC devices in the 3GPP context. As a specific example, an IoT device can be a device that implements the 3GPP Narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices (e.g., power meters), industrial machinery, or household or personal appliances (e.g., refrigerators, televisions, etc.) and personal wearable devices (e.g., watches, fitness trackers, etc.). In other cases, an IoT device can represent a vehicle or other device capable of monitoring and / or reporting its operational status or other functions associated with its operation. In yet another case, an IoT device can initiate a real-time video stream.

[0034] Some embodiments described herein depict user equipment (UE). As used herein, a UE may include devices capable of, configured to, arranged to, and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Examples of UEs include, but are not limited to, smartphones, mobile phones, cellular phones, Voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless client devices (CPEs), vehicle-mounted wireless terminal devices, etc.

[0035] The type of device can be determined, for example, based on the International Mobile Subscriber Identity (IMSI) or through the header in the communication stack.

[0036] As described above, in step 402, the method includes i) obtaining the transmission mode (e.g., network access mode) of the IoT device.

[0037] The transmission mode can be periodic, such as periodic reports from sensors (e.g., temperature sensors, weather sensors), equipment status updates (e.g., factory equipment monitoring), or any other type of periodic transmission.

[0038] Step 402 may also include acquiring transmission parameters associated with the transmission mode. For example, transmission parameters may include, for instance, transmission frequency or timing information. The transmission mode may be associated with a Service Level Agreement (SLA) of the IoT device.

[0039] The transmission mode and / or transmission parameters can be obtained, for example, from another node in the communication network (e.g., the Service Capability Opening Function (SCEF) in a 5G network). However, this is merely an example, and those skilled in the art will understand that the transmission mode can be obtained from any other node in the communication network, for example, that has functionality similar to SCEF.

[0040] In step 404, the method includes ii) clustering IoT devices into a cluster based on the acquired transmission patterns. Clustering can be based on the similarity of transmission patterns and can be performed using known clustering techniques such as k-means. Clustering can be further performed based on IoT device SLAs, transmission patterns (e.g., network access patterns), coverage area, data rate, and the criticality of the devices. Examples of critical devices are, for example, medical devices and autonomous vehicles with clearly defined time-critical aspects of data transmission that cannot be interrupted. In one example, clustering (or defining the cluster) is performed based on whether a common transmission pattern can be negotiated for the devices in the cluster.

[0041] The type of aggregation process performed can depend on the input parameters and / or implementation design. For example, in embodiments where device location is used as a parameter for performing aggregation, density-based spatial aggregation (DBSCAN) with noise can be used to perform aggregation. In another embodiment, the problem can be formulated graphically, in which case affinity propagation can be used. If we are interested in some variance, principal component analysis (PCA) can be used to identify the principal components (i.e., properties of the transmission control parameters of interest). If we want to have more general clusters that become more specific to certain characteristics (e.g., IoT device category, location, transmission frequency, energy, etc.) over time, Chameleon or other hierarchical aggregation techniques can be used. However, those skilled in the art will understand that these are merely examples and other aggregation techniques can also be used.

[0042] In step 406, transmissions from IoT devices in different clusters are scheduled to different network resources (e.g., allocated to different network resources for service). In other words, the transmissions of IoT devices are based on the network resources allocated to them by the cluster. For example, different IoT device clusters may be scheduled to be served by different network resources (e.g., different base stations, or different cells on a base station). In other words, each network resource can serve IoT devices from the same cluster (or two or more similar clusters). It is understood that in practical applications, large clusters of IoT devices can be split and allocated to two or more network resources. By grouping transmissions from IoT devices in this way, transmissions can be better synchronized, thereby increasing the inactivity periods during which network resources might enter a dormant mode (e.g., be turned off), thus saving energy.

[0043] This is illustrated in Figure 2b, which shows the transmission patterns of devices 202, 204, and 206 after scheduling according to the method described herein. Packing transmissions results in larger inactivity slots 210, which allows for longer sleep periods. Furthermore, longer periods of inactivity allow network resources to remain in a “deeper” sleep state, further conserving energy. Slots shorter than a certain duration cannot be used for sleep because they are insufficient to wake the network. It can be seen (e.g., compared to Figure 2a) that the aggregation of transmission patterns leads to an increase in sleep duration.

[0044] Energy savings can be further achieved by improving the aggregation (and therefore synchronization) of IoT devices within each cluster. This can be done by suggesting new transmission modes for the IoT devices. As will be described in more detail below, new transmission modes can be suggested iteratively until the optimal transmission mode that results in the greatest energy savings is found.

[0045] Therefore, method 400 may also typically include selecting a new transmission mode for the IoT devices. Typically, predicting the new transmission mode will result in increased synchronization of transmission modes among the IoT devices in the cluster (e.g., compared to the transmission mode obtained in step i). The method may then include repeating steps ii) and iii) above for the new transmission mode.

[0046] New transport modes can be selected to reduce the number of clusters and / or increase the similarity of transport modes in each cluster.

[0047] Some IoT devices may have flexibility associated with their transmission modes. This flexibility can be about, for example, the timing or frequency of transmissions. The flexibility allowed for an IoT device's transmissions can depend on its Service Level Agreement (SLA). Critical IoT devices (such as those associated with medical applications or autonomous vehicles) may have very little flexibility in their transmission modes. For example, an SLA might describe latency and reliability requirements. For critical devices, an SLA might specify latency ranging from 10 seconds to 1 second, or even milliseconds, and reliability from 99% to 99.999%. Other IoT devices (reporting sensor readings, for example, in weather applications) may have considerably more flexibility. SLAs can also further specify different requirements for different times of day or different applications.

[0048] Therefore, the new transmission mode may include a perturbation (e.g., a change) of the transmission mode obtained in step i), based on a predetermined flexibility associated with the transmission mode of the IoT device. In other words, a new transmission mode can be selected by adjusting the transmission mode obtained in step i) within the range of predetermined flexibility (e.g., constraints imposed by the IoT device's service level agreement).

[0049] Other factors may also be considered when selecting a new transmission mode. For example, network resources may be serving other services such as UE services that are less flexible (or less flexible) in their scheduling (e.g., services arising from calls, data streams, etc.). In this case, IoT services can be scheduled (using predetermined flexibility) to overlap with UE services, thereby increasing the inactivity period of network resources. Therefore, in some embodiments, method 400 may include obtaining the transmission mode for one or more user equipments (UEs) that are using network resources for transmission. The step of selecting a new transmission mode for the IoT device may then further include selecting a new transmission mode for the IoT device to increase the overlap metric between the transmission mode of the IoT device and the transmission modes of one or more UEs (e.g., in time / when transmission occurs). In this way, the flexibility of the IoT transmission mode can be utilized to improve the overlap between IoT transmissions and less flexible (or fixed) UE transmission modes, resulting in increased energy savings.

[0050] The new transmission mode must be accepted by the IoT device and the application running on the IoT device. Therefore, in some embodiments, method 400 may include negotiating with the IoT device to determine whether the new transmission mode meets the performance requirements of the IoT device. For example, negotiation may be performed to determine whether the new transmission mode meets the SLA associated with the IoT device. Negotiation may be performed, for example, by sending a message including suggested parameters (e.g., from the module responsible for negotiation) to the SCEF and / or application manager. In one embodiment, the message may include a preferred list of possible transmission intervals. In this example, the response from the SCEF and / or the application may include an indication of which interval in the list is acceptable.

[0051] Each IoT device can send back confirmation and acceptance for a specific device, and can also interact with network components such as the Management Data Analytics Service (MDAF) to check the feasibility of suggested transmission modes.

[0052] Using clustering and negotiation in this manner allows for the optimization, synchronization, and batching of data transmission patterns from IoT devices without impacting SLAs or the quality of service of the IoT devices.

[0053] As described above, in some embodiments, a new transmission mode can be selected in the perturbation transmission mode of each device, for example, using the transmission mode and the flexibility allowed in said transmission mode.

[0054] As an alternative, machine learning can be used to select new transmission modes for IoT devices. For example, the method could include using a model trained using a machine learning process to select a new transmission mode. This model can take the transmission parameters of the IoT device as input and output a new transmission mode based on those parameters.

[0055] Technicians will be familiar with machine learning and models that can be trained using machine learning processes. A machine learning process can be defined as the process of running on data to create a machine learning model. A machine learning process includes algorithmic steps and / or instructions that, during training, process or use data, typically referred to as training data, to generate a machine learning model. The process learns from or updates the model from the training data.

[0056] Machine learning processes encompass a wide range of methods, including supervised, unsupervised, and reinforcement learning (RL) processes. Supervised processes include, for example, classification processes such as k-nearest neighbors, regression processes such as linear or logistic regression, and clustering processes such as k-means. Further examples of machine learning processes include decision tree algorithms and artificial neural network algorithms. Machine learning processes can be implemented using any of a range of programming languages.

[0057] A model, or machine learning model, can include data and the process for using that data to, for example, make predictions, perform a specific task, or represent the real world or a system. The model represents what the machine learning process learns when trained using training data, or in other words, what the machine learning process generates. The model can represent, for example, rules, numbers, and any other algorithm-specific data structures or the architecture needed to make predictions.

[0058] The model used in this paper can also refer to a reinforcement learning agent, and machine learning processes can include reinforcement learning processes. Examples of reinforcement learning processes include, but are not limited to, Q-learning or SARSA (state-action-reward-state-action) processes. A reinforcement learning agent learns by performing actions (e.g., in the context of proposing new transmission patterns) and receiving feedback in the form of "rewards" based on the results / effects of its actions. The reinforcement learning agent explores an action space encompassing all possible actions in order to obtain rewards and determine the optimal action for different scenarios (or states).

[0059] However, these are merely examples, and in general, any model can be used, which can be trained to take the parameters described in this paper as input and output a prediction of the new transmission pattern.

[0060] The model can be trained to output the transmission pattern for IoT devices, which optimizes the number of clusters that meet, for example, the performance requirements of IoT devices when aggregating IoT devices in step (ii), thereby leading to successful negotiation between the node and the IoT device.

[0061] The model can take one or more of the following transmission parameters as input: the transmission mode obtained in step i), the flexibility associated with the transmission mode obtained in step i), the service level agreement, the time of day, and / or the location of the IoT device. The model can then output a new transmission mode for the IoT device based on these transmission parameters.

[0062] This model can be used to learn the optimal aggregation of possible transmission patterns of IoT devices attached to a cell. As mentioned above, the space of all possible transmission patterns depends on the flexibility of the application SLA (frequency, jitter tolerance, bandwidth) and the device capabilities. For example, the application may function correctly when (1) more frequent access is authorized and the amount of data per access is small, or when (2) less frequent access is authorized and the amount of data per access is large. This flexibility can be used to generate the input space for aggregation.

[0063] Furthermore, flexibility can be dynamic: applications can have different levels of flexibility at different times of the day; for example, video data sampling may be more frequent at night than during the day. Device flexibility may change due to firmware updates or the mobility of devices entering or leaving the cell. Therefore, the available space for transmission patterns may vary, and the goal is to find the optimal aggregation at any given point in time.

[0064] Typically, this model aims to propose improved aggregation and / or patterns that may be acceptable to IoT devices and applications. Through "improved aggregation," the model can predict or select new transmission patterns for each IoT device, resulting in a cluster whose total time and duration of each period are increased, allowing for the use of energy-saving measures. Longer periods enable deeper sleep states, further improving energy efficiency. Therefore, transmission patterns can be selected to increase the synchronization of transmission patterns among IoT devices in each cluster, for example, compared to the transmission patterns obtained in step i).

[0065] In predicting the modes that IoT devices might accept, the model can learn from past experience, such as the fact that monitoring applications cannot accept low-frequency access at night. Therefore, it will not suggest transmission modes with low-frequency characteristics for a particular device at night.

[0066] ML models can be used to determine <device transmission mode, application SLA, time, location>.<device transmissionpatterns,application SLAs,time,location> As input states, it proposes new device transmission modes, predicts negotiation results, and predicts energy savings E_s, corresponding to aggregation and cluster-to-radio resource allocation. During the training phase, it explores the solution space of transmission modes. During the inference phase, it outputs the best available solution.

[0067] In one example, the model is a reinforcement learning (RL) model. The model's inputs are the acceptability of the proposed aggregations (e.g., from a module that performs negotiation on new transmission patterns) and the resulting energy savings (from monitoring network resources).

[0068] Typically, due to the varying input sizes of this model (due to differences in devices and applications), a canonical representation of the input may be required. This can be achieved by fixing an upper limit on the number of devices and applications and replacing unavailable time slots with dummy transport patterns and SLAs. Machine learning based on a knowledge graph of encoded transport patterns and SLAs can be used.

[0069] The new transmission pattern set will now be smaller than the original transmission pattern set obtained in step i), resulting in an increased sleep duration. Clearly, the fewer the clusters, the longer the inactivity period, and the more energy can be saved. For a given time window T and a cluster set C, we can calculate the allowed sleep duration (SD) of the cluster. Then, we use a slab of network resources to calculate the energy savings E_S that may be achieved due to SD (longer sleep duration -> deeper sleep mode -> greater energy saving). We use E_S(C) as a measure of the quality of the aggregation of transmission patterns of multiple IoT devices in the cell.

[0070] Furthermore, given a set of radio resources R1, ..., Rn, the set C of this cluster can be partitioned into C1, ..., Cn, and Ci can be assigned to Ri. It is easy to see that this increases the total sleep duration, i.e., ΣSD(C_i) ≥ SD(C), and thus increases the total E_S(C1, ..., C_n).

[0071] Feedback regarding aggregation, energy saving, and negotiation outcomes can be fed back to the model so that the model can learn from its predictions. Therefore, the method may also include the steps of: providing first feedback to the model based on clustering, and retraining the model using the first feedback to output a transmission pattern that increases the synchronization of transmissions scheduled on each network resource. For example, the first feedback may include a measure of energy usage associated with the network resource for the scheduled transmissions in step iii). It may include a measure of energy saving associated with inactive periods of the network resource. For example, energy saved (or conversely used) when scheduling transmissions from IoT devices based on new transmission patterns and clusters predicted by the model.

[0072] This method may additionally or alternatively include providing a second feedback to the model based on the results of the negotiation step, and retraining the model using the second feedback to output a transmission pattern that meets the performance requirements of IoT devices. For example, the results of the negotiation step (as described above) can be provided to the model for IoT devices (e.g., each IoT device).

[0073] The first and second feedback will take different forms depending on the type of model. For example, if the model includes an RL model, the RL agent can receive positive rewards for predicting transmission patterns that lead to improved aggregation (and thus improved energy efficiency of network resources) and / or are accepted by IoT devices. As a non-limiting example, a reward scheme can be established to penalize (e.g., provide negative rewards) if the new transmission pattern of the IoT device is not accepted by the corresponding IoT device, or if the new transmission pattern saves less energy compared to the previous transmission pattern. Positive rewards can be given if the new transmission pattern of the IoT device (or the pattern set of the corresponding IoT device set) improves aggregation, and / or if the IoT device accepts the result of the new transmission pattern.

[0074] As another example, if the model includes a supervised learning model such as a neural network, the first and / or second feedback may include indications of fundamental facts (e.g., observed) such as whether the new transmission pattern leads to good aggregation, energy savings in network resources, and / or successful negotiation. Those skilled in the art will understand that this is merely an example and that the feedback may take other forms depending on the type of model and its architecture.

[0075] Typically, the method may then include repeating steps ii) and iii) using the retrained model.

[0076] The success (or failure) of the above negotiation steps can be further used to trigger another new set of transmission patterns predicted by the model, thus generating a new aggregation. This creates a loop between the negotiation and aggregation steps, with the goal of maximizing the time available for energy-saving actions while ensuring that new transmissions are accepted and thus meet the SLA requirements of IoT devices.

[0077] Turn now Figure 5 This illustrates an example system architecture where the steps of method 400 are performed by different (computer-implemented) modules. These modules may all be part of the same node (e.g., node 300 mentioned above). Alternatively, one or more nodes may reside in different nodes. Alternatively, one or more nodes may be implemented in the cloud. Alternatively, one or more modules (e.g., negotiator module 506) may reside at the edge (e.g., a base station). It should be understood that this is merely an example architecture and other arrangements are possible.

[0078] exist Figure 5 In the example, aggregation module 502 acquires the transmission modes of 402 multiple IoT devices and aggregates 404 the IoT devices into a cluster based on the acquired transmission modes. These steps have been described in detail above, and the details therein should be understood to apply equally to the functionality of aggregation module 502. Aggregation module 502 outputs aggregation 504. The output of the aggregation module may include fields such as: IoT device identifier, an identifier associated with the SLA of each IoT device, the access / transmission mode of the IoT device, and indications of the criticality of the IoT device.

[0079] In this example, cluster information is sent to negotiator module 506, which negotiates with IoT device 508 and / or IoT device application manager (e.g., service capability open function 526) to determine whether the cluster is available based on (e.g., according to) the IoT device's SLA. Access modes (e.g., transport modes) are aligned within each cluster.

[0080] The negotiator module 506 can also obtain input from network components 522 (e.g., configurable hardware and software components). Such information can be provided by the Management and Orchestration Data Analysis Function (MDAF) 524.

[0081] The successful negotiation result is forwarded to the scheduler and allocator 510. The scheduler and allocator 510 schedules the transmissions of IoT devices in different clusters 406 to different network resources 514 (e.g., according to cluster scheduling). The transmissions are executed and a metric for energy usage is determined. As mentioned above, the metric for energy usage can be the energy savings resulting from inactivity periods between transmissions on network resources.

[0082] The first feedback 518 related to energy usage is determined and fed back to the recommendation submodule 512. The second feedback 520 related to the success of the negotiation performed by the negotiator module 506 is also fed back to the recommendation submodule 512.

[0083] Recommendation module 512 selects a new transmission mode for IoT devices. The new transmission mode is expected to lead to aggregation, which increases the synchronization of transmission modes among IoT devices in the cluster. Recommendation module 512 uses a model trained through a machine learning process to predict the new transmission mode. This model is trained to output transmission modes for IoT devices, optimizing the number of clusters obtained by aggregation module 502 and / or predicted to meet the performance requirements of the IoT devices, thereby leading to successful negotiation by negotiator module 506.

[0084] As described above, the model in the recommendation submodule selects candidate transmission modes different from the current transmission mode (which leads to the current aggregation) based on the permissible flexibility associated with the transmission modes of IoT devices in the cell and the network capabilities supporting the latency and bandwidth requirements of the transmission modes. The ML model is expected to suggest modes that improve aggregation and are likely to be accepted by devices and applications (based on learning from the first and second feedbacks). The first and second feedbacks can be used to train (e.g., update) the model.

[0085] The new transmission mode output / predicted by the recommendation submodule 512 is then sent to the aggregation module 502, and the process is repeated for the new transmission mode. As a result, the system increases the synchronization of transmissions scheduled on each network resource and allows for increased periods of inactivity on network resources between transmissions, while also ensuring that the SLA of IoT devices is met (through the use of the negotiator module 506).

[0086] Figures 6a and 6b illustrate example signaling diagrams for implementing method 400 described above. In this example, negotiator module 602 requests 620 a list of current UEs served by one or more gNBs 610. The gNB provides this list in step 622. Negotiator module 602 then requests 624 details of IoT devices from Service Capability Open Function (SCEF) 612, provided by SCEF in message 626. The negotiator then requests 628 application SLA details from application manager 616. Application manager 616 provides the application details in message 630.

[0087] Then, a loop is executed, starting at 634, where the recommendation model 604 suggests a new transmission mode for the IoT devices based on the information and transmission mode obtained by the negotiation module 602 (in steps 624 and 626). The aggregation module 606 obtains (e.g., receives) the suggested new transmission mode and aggregates the IoT devices into a cluster based on this transmission mode.

[0088] In step 636, the aggregation module 606 sends the cluster and the new transmission mode to the negotiator 602.

[0089] In steps 638 and 640, the negotiator module 602 negotiates with SCEF 612 and application manager 616 to determine, for example, whether a new transmission mode is acceptable based on the SLA of (each) IoT device. The feasibility of the transmission mode is sent to negotiator 602 at 642 and 644.

[0090] Transmissions from IoT devices in different clusters are then scheduled to different network resources. In this embodiment, the IoT device cluster is sent to scheduler / allocator 608, which schedules and executes transmissions from the IoT devices in the cluster. The gNB 610 serving the IoT devices in the cluster determines the energy saving associated with periods of inactivity of the network resources and sends this recommendation model 604 to 648.

[0091] In step 650, the negotiator 610 queries the MDAF whether the transport mode is acceptable from the perspective of network establishment. Step 652 receives a (positive) response from the MDAF in this example. The negotiator then sends a message 654 to the SCEF and, via the SCEF, to the application manager 656 to initiate any changes required to implement the new transport mode. The negotiator 602 then sends message 658 to the MDAF 614 to establish the network change (if needed). In step 660, the negotiator sends a message to the recommended model 604 containing information indicating whether the proposed cluster led to a successful negotiation. This process is performed in a round-robin fashion (steps 634-660). The final cluster can be sent 666 to a network resource (e.g., a gNB) for allocation 668.

[0092] Turning now to another embodiment, in some embodiments there exists a computer program including instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods described herein, such as method 400 described above. In other embodiments, there exists a carrier containing the computer program described above. The carrier includes one of electrical signals, optical signals, radio signals, or a computer-readable storage medium. In other embodiments, there exists a computer program product including a non-transitory computer-readable medium on which the computer program described above is stored.

[0093] Therefore, it should be understood that this disclosure also applies to computer programs, particularly computer programs on or in a carrier, suitable for putting the embodiments into practice. The program may be in the form of source code, object code, intermediate source code, and object code in the form of, for example, partially compiled code, or any other form suitable for implementing the methods according to the embodiments described herein.

[0094] It will also be understood that such a program can have many different architectural designs. For example, the program code implementing the functionality of the method or system can be subdivided into one or more subroutines. Many different ways of distributing functionality among these subroutines will be apparent to those skilled in the art. Subroutines can be stored together in an executable file to form a self-contained program. Such an executable file can include computer-executable instructions, such as processor instructions and / or interpreter instructions (e.g., Java interpreter instructions). Alternatively, one or more subroutines can be stored in at least one external library file and linked to the main program statically or, for example, dynamically at runtime. The main program contains at least one call to at least one subroutine. Subroutines can also include function calls to each other.

[0095] The carrier of a computer program can be any entity or device capable of carrying the program. For example, the carrier can include data storage, such as ROM, like a CD-ROM or semiconductor ROM, or magnetic recording media, such as a hard disk. Furthermore, the carrier can be a transmissible medium such as electrical or optical signals, which can be transmitted via cables or optical fibers or by radio or other means. When the program is embodied in such a signal, the carrier can be constructed from such cables or other devices or means. Alternatively, the carrier can be an integrated circuit in which a program is embedded, adapted to execute or be used to execute related methods.

[0096] By studying the accompanying drawings, disclosure, and appended claims, those skilled in the art can understand and implement variations of the disclosed embodiments in practicing the claimed invention. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude multiple. A single processor or other unit can perform the functions of multiple items listed in the claims. The fact that certain means are recited in dissimilar dependent claims does not indicate that a combination of these means cannot be used advantageously. Computer programs can be stored / distributed on suitable media, such as optical storage media or solid-state media provided with or as part of other hardware, but can also be distributed in other forms (e.g., via the Internet or other wired or wireless telecommunications systems). Any reference marks in the claims should not be construed as limiting the scope.

[0097] Appendix 1

[0098]

Claims

1. A computer-implemented method executed by a node in a communication network for scheduling transmissions of multiple Internet of Things (IoT) devices to network resources in the communication network, the method comprising: i) Obtain (402) the transmission mode of the transmission from the IoT device; ii) Based on the similarity of the acquired transmission patterns, the IoT devices are clustered (404) into a group; as well as iii) Schedule the transmissions of IoT devices in different clusters (406) to different network resources, thereby increasing the synchronization of the transmissions scheduled on each network resource and allowing for increased inactivity periods of the network resources between transmissions; The method further includes: Select a new transmission mode for the IoT device; Obtain the transmission mode of one or more user equipments (UEs) that are using the network resources for transmission; and The step of selecting a new transmission mode for the IoT device further includes: selecting a new transmission mode for the IoT device to increase the overlap between the transmission mode of the IoT device and the transmission modes of the one or more UEs.

2. The method according to claim 1, further comprising: For the new transmission mode, repeat steps ii) and iii). The new transmission mode is predicted to be an aggregation that leads to an increase in the synchronization of the transmission modes of the IoT devices in the cluster.

3. The method according to claim 2, wherein, The new transmission mode includes a perturbation of the transmission mode obtained in step i), wherein the perturbation is based on a predetermined flexibility associated with the transmission mode of the IoT device.

4. The method according to claim 2 or 3, wherein, The step of selecting a new transmission mode for the IoT device includes: The new transmission mode is selected using a model trained through a machine learning process, wherein the model takes the transmission parameters of the IoT device as input and outputs the new transmission mode for the IoT device based on the transmission parameters.

5. The method according to claim 4, wherein, The model is trained to output a transmission pattern for the IoT device, the transmission pattern being optimized for the number of clusters obtained and / or predicted to meet the performance requirements of the IoT device when the IoT device is aggregated in step (ii).

6. The method according to claim 4, further comprising: Based on the cluster, a first feedback is provided to the model; as well as The model is retrained using the first feedback to output a transmission pattern that increases the synchronization of the transmissions scheduled on each network resource.

7. The method according to claim 6, wherein, The first feedback includes an energy usage metric associated with the network resources of the scheduled transmission in step iii).

8. The method according to claim 7, wherein, The energy usage metric includes a metric for energy savings associated with periods of inactivity of the network resources.

9. The method according to claim 2 or 3, further comprising: Negotiate with the IoT device to determine whether the new transmission mode meets the performance requirements of the IoT device.

10. The method of claim 9, further comprising: Based on the results of the negotiation steps, a second feedback is provided to the model; as well as The model is retrained using the second feedback to output a transmission mode for the IoT device that meets the performance requirements of the IoT device.

11. The method according to claim 6 or 10, further comprising: Repeat steps ii) and iii) using the retrained model.

12. The method according to claim 4, wherein, The model takes the transmission parameters of the IoT device as input, and the transmission parameters include one or more of the following: The transmission mode obtained in step i); The flexibility associated with the transmission mode obtained in step i); Service Level Agreement; Time of day; and / or Location.

13. The method according to claim 4, wherein, The model includes a reinforcement learning agent.

14. The method according to claim 13, wherein, The reinforcement learning agent receives a positive reward for predicting transmission patterns that lead to energy savings in the network resources and / or acceptance by the IoT devices.

15. The method according to claim 4, wherein, The model includes a neural network model.

16. The method according to claim 2 or 3, wherein, The step of aggregating the IoT devices based on the acquired transmission mode includes aggregating the IoT devices based on the following: Execution mode; Network access mode; Coverage area; Data rate; and / or Crucial.

17. The method according to claim 2 or 3, wherein, The increased periods of inactivity include more frequent periods of hibernation and / or longer periods of hibernation.

18. A node in a communication network for scheduling the transmissions of multiple Internet of Things (IoT) devices to network resources in the communication network, the node comprising: Memory, which includes instruction data representing instruction sets; as well as A processor configured to communicate with the memory and execute the instruction set, wherein the instruction set, when executed by the processor, causes the processor to: i) Obtain the transmission mode of the transmission from the IoT device; ii) Based on the similarity of the acquired transmission patterns, the IoT devices are clustered together; as well as iii) Schedule the transmissions of IoT devices in different clusters to different network resources, thereby increasing the synchronization of the transmissions scheduled on each network resource and allowing for increased inactivity periods between each corresponding network resource between transmissions; The processor is further configured to: Select a new transmission mode for the IoT device; Obtain the transmission mode of one or more user equipments (UEs) that are using the network resources for transmission; and The process of selecting a new transmission mode for the IoT device further includes: selecting a new transmission mode for the IoT device to increase the overlap between the transmission mode of the IoT device and the transmission modes of the one or more UEs.

19. The node of claim 18 is further configured to perform the method of claim 2 or 3.

20. A computer-readable storage medium storing a computer program comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 17.

21. A computer program product comprising a non-transitory computer-readable medium having a computer program thereon storing instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 17.

Images