Patent Publication Number: US-11381644-B2

Title: Devices and methods for QoS determination of IoT-based applications

Description:
CROSS REFERENCE TO RELATED APPLICATION(S) 
     This application is a 35 U.S.C. § 371 National Stage of International Patent Application No. PCT/IN2018/050141, filed Mar. 15, 2018, designating the United States. 
     TECHNICAL FIELD 
     The invention relates to method and devices of enabling determination of overall Quality of Service (QoS) of at least one Internet of Things (IoT) device. The invention further relates to computer programs comprising computer-executable instructions for causing devices to perform steps recited in methods according to embodiment when the computer-executable instructions are executed on a processing unit included in the network node. Still further, the invention relates to computer program products comprising a computer readable medium, the computer readable medium having the computer programs embodied thereon. 
     BACKGROUND 
     In networks comprising Internet of Things (IoT) devices such as e.g. thermostats, light bulbs, television sets, door locks, refrigerators, smart grids, cars, etc., large-scale IoT applications involving hundreds or even thousands of IoT devices can be created. 
     For such large-scale IoT applications to be possible, it will be necessary to supervise and coordinate the great number of IoT devices, in particular as regards performance monitoring of the IoT devices. 
     In current IoT networks, such supervision and coordination of IoT device resources is not possible, in that required information for determining performance of the IoT devices forming the large-scale IoT applications is not available. 
     SUMMARY 
     An object of the present invention is to solve, or at least mitigate, this problem in the art and to provide an improved method of determining performance of IoT devices in a network. 
     This object is attained in a first aspect of the invention by a method of a network node for enabling determining of an overall Quality of Service (QoS) of at least one IoT device. The method comprises transmitting, to a device connectivity middleware (DCM) node, an identifier of said at least one IoT device for which a QoS measure is to be acquired, receiving, from the DCM node, a network profile of the IoT device associated with said identifier, transmitting, to a Service Capability Exposure Function (SCEF), a request for the QoS measure of the IoT device for the received network profile, the SCEF acquiring the QoS measure from a Policy and Charging Control (PCC) function, receiving, from the SCEF, the requested QoS measure of the IoT device, transmitting, to a Lightweight Machine-to-Machine (LWM2M) device, a request for availability information for said at least one IoT device, and receiving, from the LWM2M device, the requested availability information, wherein the received QoS measure and the availability information is taken into account for determining the overall QoS of said at least one IoT device. 
     This object is attained in a second aspect of the invention by a network node configured to enable determining of an overall QoS of at least one IoT device. The network node comprises a processing unit and a memory, said memory containing instructions executable by said processing unit, whereby the network node is operative to transmit, to a DCM node, an identifier of said at least one IoT device for which a QoS measure is to be acquired, receive, from the DCM node, a network profile of the IoT device associated with said identifier, transmit to a SCEF a request for the QoS measure of the IoT device for the received network profile, the SCEF acquiring the QoS measure from a PCC function, receive, from the SCEF, the requested QoS measure of the IoT device, transmit, to an LWM2M device, a request for availability information for said at least one IoT device, and receive, from the LWM2M device, the requested availability information, wherein the received QoS measure and the availability information is taken into account for determining the overall QoS of said at least one IoT device. 
     This object is attained in a third aspect of the invention by a method of an IoT service managing device of determining an overall QoS for a group of IoT devices from QoS measures and availability information acquired by at least two network nodes according to the second aspect. The method comprises acquiring, from a first of the at least two network nodes, the QoS measure and the availability information of a first of the at least two IoT devices, acquiring, from a second of the at least two network nodes, the QoS measure and the availability information of a second of the at least two IoT devices, and determining an overall QoS for the group of at least two IoT devices based on the individual QoS measure and availability information of the first IoT device and the individual QoS measure and availability information of the second IoT device. 
     This object is attained in a fourth aspect of the invention by an IoT service managing device configured to determine an overall QoS for a group of IoT devices from QoS measures and availability information acquired by at least two network nodes according to the second aspect. The IoT service managing device comprises a processing unit and a memory, said memory containing instructions executable by said processing unit, whereby the IoT service managing device is operative to acquire, from a first of the at least two network nodes, the QoS measure and the availability information of a first of the at least two IoT devices, acquire, from a second of the at least two network nodes, the QoS measure and the availability information of a second of the at least two IoT devices, and determine an overall QoS for the group of at least two IoT devices based on the individual QoS measure and availability information of the first IoT device and the individual QoS measure and availability information of the second IoT device. 
     Hence, the network node of the second aspect, referred to in the following as an IoT micro-service device, acquires a QoS measure of an IoT device by initially transmitting an identifier of at least one IoT device for which the QoS measure is to be acquired to the DCM. It is noted that the IoT micro-service device may request QoS measures for a great number of IoT devices, in which case it could provide the DCM node with a corresponding number of identifiers. 
     The DCM node responds by transmitting the network profile of the IoT device, such that a QoS measure of the IoT device subsequently can be obtained form the 3GPP network by the micro-service device. 
     After having received the network profile, the IoT micro-service device transmits a request for the QoS measure of the IoT device comprising the network profile to the SCEF, which in its turn will forward the request to the PCC function. 
     The PCC function stores QoS information associated with the received network profile of the concerned IoT device and accordingly fetches a QoS measure and returns the QoS measure to the SCEF, which forwards the received QoS measure to the IoT micro-service device. 
     Hence, the micro-service device now has access to the requested QoS measure of the IoT device, which is based on parameters such as for instance bandwidth, latency and location of the IoT device, or a combination of a plurality of parameters. Latency is typically determined by a combination of parameters such as delay, jitter, packet loss, etc., and may further be dependent on types of payload such as e.g. speech, streaming video, online gaming, etc. 
     Further, the IoT micro-service device transmits a request for availability information of the IoT device to the LWM2M device, which fetches the availability information of IoT device from an internal storage and returns the availability information to the micro-service device. The availability information comprises for instance current battery power level, load and discharge rate, etc., of the IoT device. 
     The IoT micro-service device thus has access to both a QoS measure of the IoT device as well as availability information of the IoT device. Advantageously, with the described embodiment, an overall QoS can be determined for the IoT device. 
     For instance, the QoS measure may indicate that the IoT device is capable of acquiring data and transmitting such data to the micro-service device at a high bandwidth. However, the availability information may indicate that the IoT device is close to running out of battery power. This may affect the overall QoS of the IoT device in the sense that the overall QoS of the IoT device may decrease when taking into account the poorer availability as compared to a scenario where only the (high) QoS bandwidth figure is taken into account. 
     Further advantageous, with the described embodiment, it is possible for a group of IoT micro-service devices to supervise and coordinate a plurality of IoT devices. This may be performed by having the IoT micro-service devices intercommunicate with each other to build large-scale IoT applications. 
     In a further aspect, the IoT service managing device may collect, from the IoT micro-service devices, the QoS measures and availability information of the IoT devices and thus handle the supervision and coordination of IoT device resources, which advantageously will give the IoT service managing device a “bird&#39;s eye view” as regards the capabilities of the IoT devices. 
     In yet an embodiment, the determining of the overall QoS of one or more IoT devices further advantageously comprises predicting a future overall QoS from determined overall QoS values. 
     For instance, by analyzing a current battery charge level of a particular IoT device, an IoT micro-service device and/or the IoT service managing device may predict that the battery will be more or less discharged after a given time period, which hence will affect the overall QoS of the particular IoT device. 
     In a fifth aspect of the invention, a computer program is provided comprising computer-executable instructions for causing a network node to perform steps recited in the method of the first aspect when the computer-executable instructions are executed on a processing unit included in the network node. 
     In a sixth aspect of the invention, a computer program product is provided comprising a computer readable medium, the computer readable medium having the computer program of the fifth aspect embodied thereon. 
     In a seventh aspect of the invention, a computer program is provided comprising computer-executable instructions for causing an IoT service managing device to perform steps of the method of the third aspect when the computer-executable instructions are executed on a processing unit included in the IoT service managing device. 
     In an eighth aspect of the invention, a computer program product is provided comprising a computer readable medium, the computer readable medium having the computer program of the seventh aspect embodied thereon. 
     Further embodiments will be discussed in the following. 
     Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to “a/an/the element, apparatus, component, means, step, etc.” are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention is now described, by way of example, with reference to the accompanying drawings, in which: 
         FIG. 1  illustrates a communication network implementing a plurality of network nodes according to an embodiment, which nodes are referred as IoT micro-service devices; 
         FIG. 2  shows a signaling diagram illustrating a method of a micro-service device of acquiring a QoS measure of an IoT device according to an embodiment; 
         FIG. 3  shows a signaling diagram illustrating an IoT service managing device collecting QoS measures and availability information of a plurality of IoT devices from a group of IoT micro-service devices according to an embodiment; 
         FIG. 4  shows a signaling diagram illustrating a method of an IoT micro-service device of acquiring a QoS measure of an IoT device according to an embodiment; 
         FIG. 5  illustrates an IoT micro-service device according to an embodiment; 
         FIG. 6  illustrates an IoT service managing device according to an embodiment; 
         FIG. 7  illustrates an IoT micro-service device according to another embodiment; and 
         FIG. 8  illustrates an IoT service managing device according to another embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     The invention will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout the description. 
       FIG. 1  illustrates a communication network implementing a plurality of network nodes according to an embodiment, which nodes are referred as IoT micro-service devices  10   a - 10   e . Each of the micro-service devices is capable of connecting to one or more IoT devices  11   a - 11   c  via a network, in this particular exemplifying embodiment being a 3rd Generation Partnership Project (3GGP) type network  12 , such as a Universal Mobile Telephone System (UMTS), a Long Term Evolution (LTE) system or even a next-generation 5G system. 
     The IoT devices  11   a - 11   c  may be embodied in the form of thermostats, light bulbs, television sets, door locks, refrigerators, smart grids, cars, etc. In practice, the network of  FIG. 1  may comprise hundreds and even thousands of IoT devices. For instance, it may be envisaged that the network of  FIG. 1  is implemented in a factory environment, where thousands of IoT sensors and actuators are to be communicated with and/or controlled. 
     To enable an IoT micro-service device  10   a - 10   e  to communicate with one or more of the IoT devices  11   a - 11   c  a protocol known as Lightweight Machine-to-Machine (LWM2M) is implemented. Hence, each IoT micro-service device  10   a - 10   e  communicates by means of LWM2M with an LWM2M server  13 , which in its turn connects to the IoT devices  11   a - 11   c  via the 3GPP network  12 . 
     The IoT micro-service devices  10   a - 10   e  may fetch data of the IoT devices  11   a - 11   c  via the LWM2M server  13 , and also availability information of the IoT devices  11   a - 11   c , for instance current battery power level, load and discharge rate, etc. 
     Further, the IoT micro-service devices  10   a - 10   e  may communicate with a device connectivity middleware (DCM) node  14 , which holds a network profile of each IoT device  11   a - 11   c  e.g. for subscriber identity module (SIM) provisioning in case of mobile IoT devices. The network profile stipulates which QoS of an IoT device will be granted in terms of e.g. allowed services to be accessed, maximum allowed bit rate or allowed traffic class, latency, etc. 
     Upon having received the network profile of an IoT device  11   a - 11   c , an IoT micro-service device  10   a - 10   e  may obtain Quality of Service (QoS) information of the IoT device  11   a - 11   c  by transmitting the network profile information to a device referred to as a Service Capability Exposure Function (SCEF)  15 . 
     The SCEF  15  is a key entity within the 3rd Generation Partnership Project (3GPP) architecture for service capability exposure that provides a means to securely expose the services and capabilities provided by 3GPP network interfaces. SCEF  15  resides either on the edge of an IoT domain or completely within the IoT domain, interfacing with an external API Management Platform at the edge. The functionality of the SCEF  15  is descried in detail in e.g. 3GPP specification TS 23.682. 
     After having received the network profile information from an IoT micro-service device  10   a - 10   e , the SCEF  15  will in its turn will transmit the network profile information to a Policy and Charging Control, (PCC) function  16 , where the network profile information is mapped to a QoS measure for the IoT device  11   a - 11   c  associated with the received network profile information. In practice, the PCC function  16  may be embodied by entities like a Policy and Charging Control Function (PCRF) and a Policy and Charging Enforcement Function (PCEF). 
     Further, the network of  FIG. 1  optionally comprises an IoT service managing device  17  which is used for collecting the QoS measures and availability information acquired by the different IoT micro-service device  10   a - 10   e  for an overall view of the QoS situation of the IoT devices  11   a - 11   c  in order to provide a service-oriented architecture (SOA). 
       FIG. 2  shows a signaling diagram illustrating a method of an IoT micro-service device  10   a  of acquiring a QoS measure of an IoT device  11   a  according to an embodiment. 
     In a first step S 101 , the IoT micro-service device  10   a  transmits an identifier of at least one IoT device  11   a  for which QoS information is to be acquired to the DCM node  14 . It is noted that the IoT micro-service device  10   a  may request QoS measures for a great number of IoT devices  11   a , and not just a single one as disclosed in  FIG. 2 , in which case it could provide the DCM node  14  with a corresponding number of identifiers. 
     In step S 102 , the DCM node  14  responds by transmitting the network profile of the IoT device  11   a , such that a QoS measure of the IoT device  11   a  subsequently can be obtained from the 3GPP network  12  by the micro-service device. 
     After having received the network profile, the IoT micro-service device  10   a  transmits a request for the QoS measure of the IoT device  11   a  comprising the network profile to the SCEF  15  in step S 103 , which in its turn will forward the request to the PCC function  16  in the 3GPP network  12  in step S 104 . 
     The PCC function  16  stores QoS information associated with the received network profile of the concerned IoT device  11   a  and accordingly fetches a QoS measure, commonly referred to as QoS Attribute Value Pairs (AVPs), from a storage referred to as a Service Profile Repository (SPR) of the PCC function  16  and returns the QoS measure to the SCEF  15  in step S 105 , which forwards the received QoS measure to the IoT micro-service device  10   a  in step S 106 . 
     Hence, the IoT micro-service device  10   a  now has access to the requested QoS measure of the IoT device  11   a , which is based on parameters such as for instance bandwidth, latency and location of the IoT device  11   a , or a combination of a plurality of parameters. 
     Further, the IoT micro-service device  10   a  transmits a request for availability information of the IoT device  11   a  to the LWM2M server  13  in step S 107 . As previously discussed, communication between the IoT micro-service device  10   a  and the LWM2M server  13  is undertaken using the Open Mobile Alliance (OMA) LWM2M protocol. 
     The LWM2M server  13  fetches the availability information of IoT device  11   a  from an internal storage and returns the availability information to the IoT micro-service device  10   a  in step  108 . As previously discussed, the availability information comprises for instance current battery power level, load and discharge rate, etc., of the IoT device  11   a.    
     The IoT micro-service device  10   a  now has access to both a QoS measure of the IoT device  11   a  as well as availability information of the IoT device  11   a . Advantageously, with the described embodiment, an overall QoS can be determined for the IoT device  11   a.    
     For instance, the QoS measure may indicate that the IoT device  11   a  is capable of acquiring data and transmitting such data to the micro-service device  10   a  at a high bandwidth. However, the availability information may indicate that the IoT device  11   a  is close to running out of battery power. This may affect the overall QoS of the IoT device  11   a  in the sense that the overall QoS of the IoT device  11   a  may decrease when taking into account the poorer availability as compared to a scenario where only the (high) QoS bandwidth figure is taken into account. 
     Further advantageous, with the described embodiment, it is possible for the IoT micro-service devices  10   a - 10   e  to supervise and coordinate resources of the IoT devices  11   a - 11   c . This may be performed by having the IoT micro-service devices  10   a - 10   e  intercommunicate with each other to build large-scale IoT applications. 
     In a further embodiment to be discussed in the below, the IoT service managing device  17  may collect the QoS measures and availability information of the IoT devices  11   a - 11   c  and thus handle the supervision and coordination of IoT device resources. 
     The overall QoS of a large-scale IoT application will depend on the QoS of the respective IoT device forming part of the application. 
     The acquiring of the QoS measures of the IoT devices  11   a - 11   c  is performed via a network path to the PCC function  16  by means of the network profiles of the IoT devices  11   a - 11   c , while the availability information and raw data of the IoT devices  11   a - 11   c  are acquired using the device identifier via a data path implemented by means of a standard protocol such as the LWM2M protocol. 
     The power state of the IoT devices  11   a - 11   c  decides the availability of the raw data from the device. This is further constrained by the actual telecommunication network  12 , for instance stipulated by the network profile registered for an IoT device at the PCC function  16  which determines availability and bandwidth of the IoT device  11   a.    
     Hence, the total QoS of an IoT device  11   a  is a function of parameters acquired both via the data path and the via network path. Further, since both paths have variability over time and location, the total QoS is a function of time and location. 
     Advantageously, IoT applications may be given access to a number of 3GPP services through the SCEF  15 . These include IoT device triggering, IoT device power saving, radio access network (RAN) parameter tuning, monitoring, group message delivery, etc. One or more of these parameters may be acquired to determine latency and bandwidth of an IoT device  11   a.    
     With reference to  FIG. 2 , steps S 103 -S 107  may advantageously be performed repeatedly for an IoT device  11   a , the network profile of which is acquired in step S 101  and S 102 , such that the QoS measure and the availability information of the IoT device(s)  11   a - 11   c  are regularly updated to estimate an adequate overall QoS for the IoT device(s)  11   a - 11   c.    
     It should be noted that the IoT micro-service device  10   a  may perform the communication of steps S 103  and S 106  with the SCEF  15  simultaneously with the communication of steps S 106  and S 107  with the LWM2M server  13 , or in a reversed order as compared to that shown in  FIG. 2 . 
     Again with reference to  FIG. 1 , as was discussed hereinabove, in order to effectively supervise and coordinate resources of the IoT devices  11   a - 11   c  forming part of an IoT application, the IoT service managing device  17  may collect the QoS measures and availability information of the IoT devices  11   a - 11   c  from the IoT micro-service devices  10   a - 10   e . In such an embodiment, the IoT service managing device  17  will advantageously be capable of drawing conclusions as regards the total QoS situation of the IoT application. For instance, the IoT service managing device  17  may concluded that a part of the IoT network formed by a first subset of IoT devices currently has low availability and thus should not—at least temporarily—be burdened with the task of providing data. The IoT service managing device  17  may concurrently conclude that a different, second subset of IoT devices indeed has an adequate QoS, and is instead called upon to deliver said data. 
     Hence, the IoT service managing device  17  may direct an IoT application to the second subset of IoT devices for a requested service, if the device comes to the conclusion that the QoS provided by the second subset of IoT devices is superior to that of the first subset of IoT devices. 
       FIG. 3  shows a signaling diagram illustrating the embodiment where the IoT service managing device  17  collects the QoS measures and availability information of a plurality of IoT devices  11   a - 11   c  from a group of IoT micro-service devices  10   a - 10   e.    
     Hence, after e.g. a first IoT micro-service device  10   a  and a second IoT micro-service device  10   b  has performed the process of  FIG. 2 , collecting the QoS measures and availability information of a plurality of IoT devices  11   a - 11   c , the IoT service managing device  17  acquires, from the first IoT micro-service device  10   a , the QoS measure and the availability information of for instance a first and a second of the IoT devices  11   a  and  11   b  in step S 201 . 
     Then, in step S 202 , the IoT service managing device  17  acquires the QoS measure and the availability information of for instance a third of the IoT devices  11   c  from the second IoT micro-service device  10   b.    
     From the information acquired in steps S 201  and S 202 , the IoT service managing device  17  determines in step S 203  an overall QoS for the group of IoT devices  11   a - 11   c.    
     It should be noted that the actual determination of current overall QoS of an individual IoT device based on a QoS measure of the IoT device and its availability information can be computed in many different ways, and the various possible computations are per se beyond the scope of this invention. 
     In a further embodiment, the IoT micro-service devices  10   a - 10   e  and/or the IoT service managing device  17  may advantageously predict a future overall QoS for an individual IoT device or for a group of IoT devices  11   a - 11   c  based and the determined current overall QoS. 
     For instance, by analyzing a current battery charge level of a particular IoT device  11   a - 11   c , an IoT micro-service device  10   a - 10   e  and/or the IoT service managing device  17  may predict that the battery will be more or less discharged after a given time period, which obviously will affect the overall QoS of the particular IoT device  11   a - 11   c.    
     In another example, bandwidth capability of a certain device on a given hour of the day or week may be predicted. For some parameters to be predicted, it may be necessary to take into account a set of determined historical overall QoS values. 
     Hence, the prediction model is implemented in the IoT micro-service devices  10   a - 10   e  and/or in the IoT service managing device  17 . The prediction model can be configured for any period (seasonality such as time-of-day, day-of-week, etc.). For a given a time of day in the future, the model may predict values of availability, bandwidth and latency of access to a given IoT device  11   a - 11   c.    
     There are many methods available for predicting data, and commonly machine learning models are utilized. 
       FIG. 4  shows a signaling diagram illustrating an embodiment of an IoT micro-service device  10   a  acquiring a QoS measure of an IoT device  11   a - 11   c  (as described in  FIG. 1 ) via an SCEF  15 . 
     In a first step S 301 , the IoT micro-service device  10   a  sends a Resource Modify Request message to the SCEF  15 . With this Resource Modify Request message, the IoT micro-service device  10   a  requests a QoS measure of the IoT device  11   a - 11   c  (cf. step S 103  of  FIG. 2 ) from the SCEF  15 , which request comprises the network profile of the IoT device. 
     The SCEF  15  transmits the QoS measure request in the form of a Lightweight Directory Access Protocol (LDAP) SEARCH message to a Service Profile Repository (SPR)  18  in step S 302 , which will return adequate parameters of the request in an appropriate LDAP Data Interchange Format (LDIF) to the SCEF  15  in step S 303  with an LDAP RES message. 
     The SCEF  15  thus transmits the LDIF QoS measure request to the PCC  16  (cf. step S 104  of  FIG. 2 ) in the form of a Modify Resources message, i.e. a so called Rx Authorize/Authenticate-Request (AAR). 
     As previously discussed, the PCC function  16  stores QoS information associated with the received network profile of the concerned IoT device  11   a - 11   c , which profile is included in the request of step S 304 . 
     Accordingly, the PCC function  16  fetches a QoS measure, commonly referred to as QoS AVPs from its storage and returns the QoS measure to the SCEF  15  in step S 305  (cf. step S 105  of  FIG. 2 ) in the form of a Modify Success message, i.e. a so called Rx Authorize/Authenticate-Answer (AAA). 
     Finally, the SCEF  15  forwards the received QoS measure to the IoT micro-service device  10   a  in step S 306  (cf. step S 106  of  FIG. 2 ) in the form of a Modify Response Success message. 
     Hence, the micro-service device  10   a  now has access to the requested QoS measure of the IoT device  11   a - 11   c , which is based on parameters such as for instance bandwidth, latency and location of the IoT device, or a combination of a plurality of parameters. 
     With reference to  FIG. 5 , the steps of the method performed by the IoT micro-service device  10   a  of enabling determining of an overall QoS of at least one IoT device  11   a - 11   c  according to embodiments as previously has been described are in practice performed by a processing unit  20  embodied in the form of one or more microprocessors arranged to execute a computer program  21  downloaded to a suitable storage volatile medium  22  associated with the microprocessor, such as a Random Access Memory (RAM), or a non-volatile storage medium such as a Flash memory or a hard disk drive. The processing unit  20  is arranged to cause the IoT micro-service device  10   a  to carry out the method according to embodiments when the appropriate computer program  21  comprising computer-executable instructions is downloaded to the storage medium  22  and executed by the processing unit  20 . The storage medium  22  may also be a computer program product comprising the computer program  21 . Alternatively, the computer program  21  may be transferred to the storage medium  22  by means of a suitable computer program product, such as a Digital Versatile Disc (DVD) or a memory stick. As a further alternative, the computer program  21  may be downloaded to the storage medium  22  over a network. The processing unit  20  may alternatively be embodied in the form of a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), etc. 
     With reference to  FIG. 6 , the steps of the method performed by the an IoT service managing device  17  of determining an overall QoS for a group of IoT devices  11   a - 11   c  from QoS measures and availability information acquired by at least two IoT micro-service devices  10   a - 10   e  of the type illustrated in  FIG. 5  according to embodiments as previously has been described are in practice performed by a processing unit  30  embodied in the form of one or more microprocessors arranged to execute a computer program  31  downloaded to a suitable storage volatile medium  32  associated with the microprocessor, such as a RAM, or a non-volatile storage medium such as a Flash memory or a hard disk drive. The processing unit  30  is arranged to cause the IoT service managing device  17  to carry out the method according to embodiments when the appropriate computer program  31  comprising computer-executable instructions is downloaded to the storage medium  32  and executed by the processing unit  30 . The storage medium  32  may also be a computer program product comprising the computer program  31 . Alternatively, the computer program  31  may be transferred to the storage medium  32  by means of a suitable computer program product, such as a DVD or a memory stick. As a further alternative, the computer program  31  may be downloaded to the storage medium  32  over a network. The processing unit  30  may alternatively be embodied in the form of a DSP, an ASIC, an FPGA, a CPLD, etc. 
       FIG. 7  illustrates an IoT micro-service device  10   a  according to an embodiment. The IoT micro-service device  10   a  comprises transmitting means  40  adapted to transmit to a DCM node, an identifier of at least one IoT device  11   a - 11   c  for which a QoS measure is to be acquired, receiving means  41  adapted to receive, from the DCM node, a network profile of the IoT device associated with said identifier, transmitting means  42  adapted to transmit, to an SCEF, a request for the QoS measure of the IoT device for the received network profile, receiving means  43  adapted to receive, from the SCEF, the requested QoS measure of the IoT device, transmitting means  44  adapted to transmit, to a LWM2M device, a request for availability information for said at least one IoT device, and receiving means  45  adapted to receive, from the LWM2M device, the requested availability information, wherein the received QoS measure and the availability information is taken into account for determining the overall QoS of said at least one IoT device. 
     The means  40 - 45  may comprise a communications interface for receiving and providing information, and further a local storage for storing data, and may (in analogy with that previously discussed) be implemented by a processor embodied in the form of one or more microprocessors arranged to execute a computer program downloaded to a suitable storage medium associated with the microprocessor, such as a RAM, a Flash memory or a hard disk drive. 
       FIG. 8  illustrates an IoT service managing device  17  according to an embodiment. IoT service managing device  17  comprises acquiring means  50  adapted to acquire, from a first of at least two IoT micro-service devices  10   a - 10   e , the QoS measure and the availability information of a first of at least two IoT devices  11   a - 11   c , acquiring means  51  adapted to acquire, from a second of the at least two IoT micro-service devices  10   a - 10   e , the QoS measure and the availability information of a second of the at least two IoT devices, and determining means  52  adapted to determine an overall QoS for the group of at least two IoT devices  11   a - 11   c  based on the individual QoS measure and availability information of the first IoT device  11   a  and the individual QoS measure and availability information of the second IoT device  11   b.    
     The means  50 - 52  may comprise a communications interface for receiving and providing information, and further a local storage for storing data, and may (in analogy with that previously discussed) be implemented by a processor embodied in the form of one or more microprocessors arranged to execute a computer program downloaded to a suitable storage medium associated with the microprocessor, such as a RAM, a Flash memory or a hard disk drive. 
     The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.