Confirmed delivery of messages in an internet of things architecture involving application layer protocol mapping

Abstract

There is provided a method for facilitating delivery of a first message to a computing device over a communication network. The method is performed by a proxy node. A first message is received (110) from a server node over a first application layer protocol. An intended recipient of the first message is the computing device. The first message is mapped (120) to a second application layer protocol, different to the first application layer protocol. The mapped first message is encoded (130) into Short Messaging Service (SMS) Protocol Data Units (PDUs). The encoded first message is forwarded (140) to a communication network SMS Centre (SMS-C). A delivery report, for the encoded first message, is received (150) from the SMS-C, and sent (160) to the server node over the first application layer protocol. The delivery confirmation specifies that the first message has been transmitted to the computing device.

Description

[0001] CONFIRMED DELIVERY OF MESSAGES IN AN INTERNET OF THINGS ARCHITECTURE INVOLVING APPLICATION LAYER PROTOCOL MAPPING

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to methods for communication exchange over a communication network, and nodes configured to operate in accordance with those methods.

[0004] BACKGROUND

[0005] The “Internet of Things” (loT) refers to systems of devices enabled for communication network connectivity, so that these devices may be remotely managed, and data collected or required by the devices may be exchanged between individual devices and between devices and application servers. A popular vision of loT comprises large numbers of such small autonomous devices, transmitting and receiving small amounts of data, typically relatively infrequently. loT devices, examples of which may include sensors and actuators, are often although not necessarily, subject to severe limitations on processing power, storage capacity, energy supply, device complexity and / or network connectivity, imposed by their operating environment or situation, and may consequently be referred to as constrained devices. Constrained devices may operate according to a range of protocols, including widely used protocols such as Internet Protocol (IP) v4 or IPv6, and dedicated protocols for constrained devices, including for example the Constrained Application Protocol (CoAP).

[0006] CoAP is designed to be simple, and enables constrained devices to communicate in constrained networks with low bandwidth and low availability. Similar to HTTP, CoAP follows a client / server model and is based on REST (Representational State Transfer) architecture. CoAP employs a two-layer structure, where these two layers are the Message Layer and the Request / Response layer. The Request / Response layer supports methods including GET, PUT, POST and DELETE (as defined in Internet Engineering Task Force (IETF) RFC 7252), allowing for the access, modification, or deletion of resources. The Message Layer supports four types of messages: CON (confirmable), NON (non-confirmable), ACK (acknowledgement), and RST (reset), as defined in IETF RFC 7252. Message proxies are commonly used to interface between different network domains by enabling the translation of (e.g. request / response) protocols between the domains. For example, messaging proxies using REST protocols tend to implement a one-to-one mapping between protocols. This mapping is similar to that used for translation from hypertext transfer protocol (HTTP) to constrained application protocol (CoAP), and vice- versa. Therefore, if an HTTP message is sent toward a CoAP endpoint, the sender of the message usually requires an acknowledgement of reception via a response. Therefore, even if there is a desire in the network to send a message with minimal communication to a CoAP endpoint, it is expected that a CoAP endpoint will still normally send some response that will then be mapped or translated to HTTP.

[0007] CoAP already provides for a non-confirmable (NON) message that is not acknowledged by the recipient of the NON message. However, typical request / response semantics still require that a server responds to the receipt of a request message with a status code indicating “the result of the attempt to understand and satisfy the request” (e.g., Success 2. XX, Client Error 4. XX, etc). A description of such existing techniques can be found in Internet Engineering Task Force (IETF) RFC 7252.

[0008] “CoAP NoResponse”, as defined in IETF RFC 7967, builds on top of such techniques by explicitly signalling to the server not to send any response at all (in response to the receipt of a message). However, in cases such as these, for example when a CoAP client such as an application server receives no response to a message transmitted to a CoAP server such as a constrained device, the CoAP client cannot know if the request was received by the CoAP server at all. Thus, in general, the problem for applications with regards to proxies is that an originator of a message (i.e. , the initial transmitter of the message, such as an HTTP client) may be unaware of the outcome of an operation associated with the message. That is, in the absence of a reply, the outcome of the receipt of the message is unknown.

[0009] The semantics of REST-based request-response protocols always mandate a request followed by a response, even in cases where the response may not be needed, e.g., actuation without protocol return value. In other cases, a response may be needed but the receiver may not be able to provide such a response. For example, an energy- constrained endpoint using energy harvesting may not have enough power to send a response. An example would be switching on a smart light bulb through the CoAP protocol. This may not need a direct response (e.g., may use a “CoAP NoResponse”), however the application which made the initial request may benefit from knowing that the light bulb has been switched on.

[0010] Thus, there currently exist challenges with reliably and efficiently transmitting messages to a constrained endpoint in a network.

[0011] SUMMARY

[0012] It is an aim of the present disclosure to provide a proxy node, a server node, a computing device, corresponding methods and a corresponding computer program product which at least partially address one or more of the challenges discussed above. It is a further aim of the present disclosure to provide a proxy node, a server node, a computing device, corresponding methods and a corresponding computer program product which cooperate to facilitate delivery of a first message to a computing device over a communication network.

[0013] According to an aspect of the present disclosure, there is provided a first method for facilitating delivery of a first message to a computing device over a communication network. The first method is performed by a proxy node. The first method comprises receiving the first message from a server node. An intended recipient of the first message is the computing device, and the first message is received over a first application layer protocol. The first method also comprises mapping the first message to a second application layer protocol, different to the first application layer protocol. The first method also comprises encoding the mapped first message into Short Messaging Service (SMS) Protocol Data Units (PDUs). The first method also comprises forwarding the encoded first message to a communication network SMS Centre (SMS-C). The first method also comprises receiving from the SMS-C a delivery report for the encoded first message, and sending, to the server node over the first application layer protocol, a delivery confirmation for the first message. The delivery confirmation specifies that the first message has been transmitted to the computing device.

[0014] According to another aspect of the disclosure, there is provided a second method for communicating with a computing device over a communication network. The second method is performed by a server node. The second method comprises sending a first message to a proxy node. An intended recipient of the first message is a computing device, and the first message is sent over a first application layer protocol, to be mapped to a second application layer protocol by the proxy node. The second method also comprises receiving, from the proxy node over the first application layer protocol, a delivery confirmation for the first message. The delivery confirmation specifies that the first message has been transmitted to the computing device.

[0015] According to another aspect of the disclosure, there is provided a third method for managing delivery of messages to a computing device over a communication network by a proxy node. The third method is performed by a management node. The third method comprises determining that a condition is fulfilled for provision of delivery confirmation for messages sent to the computing device, and sending to the proxy node an instruction to provide delivery confirmation for messages sent to the computing device. The delivery confirmation specifies that the first message has been transmitted to the computing device.

[0016] According to another aspect of the disclosure, there is provided a method performed by a system. The method performed by the system comprises two or more of the first method described earlier, the second method described earlier, and the third method described earlier.

[0017] According to another aspect of the disclosure, there is provided a proxy node comprising processing circuitry configured to operate in accordance with the first method described earlier. In some examples, the proxy node may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the proxy node to operate in accordance with the first method described earlier.

[0018] According to another aspect of the disclosure, there is provided a server node comprising processing circuitry configured to operate in accordance with the second method described earlier. In some examples, the server node may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the server node to operate in accordance with the second method described earlier.

[0019] According to another aspect of the disclosure, there is provided a management node comprising processing circuitry configured to operate in accordance with the third method described earlier. In some examples, the management node may comprise at least one memory for storing instructions which, when executed by the processing circuitry, cause the management node to operate in accordance with the third method described earlier.

[0020] According to another aspect of the disclosure, there is provided a system. The system comprises two or more of the proxy node described earlier, the server node described earlier, and the management node described earlier.

[0021] According to another aspect of the disclosure, there is provided a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the first method described earlier, the second method described earlier, and / or the third method described earlier.

[0022] According to another aspect of the disclosure, there is provided a computer program product comprising a computer readable medium, the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the first method described earlier, the second method described earlier, and / or the third method described earlier.

[0023] Examples of the present disclosure thus provide a technique which allows a server node (e.g. application) to be provided with delivery confirmation of a request sent to an (e.g. constrained) endpoint, without the latter actually responding to the request. Indeed, a response to a server node (e.g. application) message (e.g. request) can be inferred without an (e.g. constrained) endpoint having to directly issue a response. The technique may be beneficially applied to any constrained cellular endpoints. The technique also minimizes the energy consumption of a (e.g. constrained) endpoint and the underlying networking infrastructure by reducing the number of exchanged messages in the network. As a consequence, when applied to, for example, wireless constrained endpoints, the technique improves spectrum efficiency on the endpoints’ (e.g. local) network. Moreover, semantics of request-response protocols can still be fulfilled without the receiver responding to the request. The technique also improves the response time of a server node (e.g. application) making (e.g. HTTP) requests toward one or more (e.g. constrained) endpoints. In particular, in examples involving HTTP requests, the technique allows for faster response time in user interfaces (Ills) and application programming interfaces (APIs), as a proxy node can respond to an HTTP request on behalf of an (e.g. constrained) endpoint. As such, there are described herein improved techniques for communication exchange in a communication network.

[0024] BRIEF DESCRIPTION OF THE DRAWINGS

[0025] For a better understanding of the present disclosure, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which:

[0026] Figure 1 is a diagram illustrating an existing method for communication exchange in a network;

[0027] Figure 2 is a flow chart illustrating a method performed by a proxy node;

[0028] Figure 3 is a flow chart illustrating a method performed by a server node;

[0029] Figure 4 is a flow chart illustrating a method performed by a management node;

[0030] Figures 5 and 6 are flow charts illustrating process steps in an example of a method performed by a proxy node;

[0031] Figure 7 is a flow chart illustrating process steps in an example of a method performed by a server node;

[0032] Figure 8 is a flow chart illustrating process steps in an example of a method performed by a management node;

[0033] Figures 9-11 are diagrams illustrating an exchange of signals in systems according to some examples of the present disclosure;

[0034] Figure 12 is a block diagram illustrating a proxy node;

[0035] Figure 13 is a block diagram illustrating a server node;

[0036] Figure 14 is a block diagram illustrating a management node; Figure 15 is a block diagram illustrating a computer program product;

[0037] Figure 16 shows an example of a communication system in accordance with some examples.

[0038] DETAILED DESCRIPTION

[0039] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. 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 methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the examples disclosed herein may be applied to any other example, wherever appropriate. Likewise, any advantage of any of the examples may apply to any other examples, and vice versa. Other objectives, features and advantages of the enclosed examples will be apparent from the following description.

[0040] Some of the examples contemplated herein will now be described more fully with reference to the accompanying drawings. Other examples, however, are contained within the scope of the subject-matter disclosed herein, the disclosed subject-matter should not be construed as limited to only the examples set forth herein; rather, these examples are illustrative, and provided to convey the scope of the subject-matter to those skilled in the art.

[0041] As mentioned earlier, there are described herein improved techniques for communication exchange in a communication network.

[0042] The communication network referred to herein can be any type of communication network. For example, the network referred to herein may be a telecommunication network. In some examples, the communication network referred to herein can be a mobile network, such as a fifth generation (5G) mobile network or any other generation mobile network. In some examples, the communication network referred to herein can be a core network (e.g. 5GC) or a radio access network (RAN). In some examples, the communication network referred to herein can be a virtual network or an at least partially virtual network. Although some examples have been provided for the type of communication network referred to herein, it will be understood that the communication network referred to herein can be any other type of communication network.

[0043] According to examples of the present disclosure, the computing device referred to herein may be a constrained device. For the purposes of the present disclosure, a constrained device comprises a device which conforms to the definition set out in section 2.1 of IETF RFC 7228 for “constrained node”. According to the definition in IETF RFC 7228, a constrained device is a device in which “some of the characteristics that are otherwise pretty much taken for granted for Internet nodes at the time of writing are not attainable, often due to cost constraints and / or physical constraints on characteristics such as size, weight, and available power and energy. The tight limits on power, memory, and processing resources lead to hard upper bounds on state, code space, and processing cycles, making optimization of energy and network bandwidth usage a dominating consideration in all design requirements. Also, some layer-2 services such as full connectivity and broadcast / multicast may be lacking”. Constrained devices are thus clearly distinguished from server systems, desktop, laptop or tablet computers and powerful mobile devices such as smartphones. A constrained device may for example comprise a Machine Type Communication device, a battery powered device or any other device having the above discussed limitations. Examples of constrained devices may include sensors measuring temperature, humidity and gas content, for example within a room or while goods are transported and stored, motion sensors for controlling light bulbs, sensors measuring light that can be used to control shutters, heart rate monitors and other sensors for personal health (continuous monitoring of blood pressure etc.) actuators and connected electronic door locks. loT devices may comprise examples of constrained devices.

[0044] The computing device referred to herein may comprise an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the computing device may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or controls a robotic arm performing a medical procedure according to the received input. The computing device may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are devices which are or which are embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a headmounted display for Augmented Reality (AR) or Virtual Reality (VR), awearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. The computing device may comprise circuitry and / or software in dependence on the intended application of the device in addition to other components.

[0045] As another example, the computing device may comprise a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to a user device, UE, and / or a network node. The computing device may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the computing device may implement the 3GPP NB-loT standard. In other scenarios, a computing device may be present in a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0046] Some of the techniques described herein involve a Short Messaging Service-Centre (SMS-C). Herein, an SMS-C may be defined as a network element in a (e.g. telecommunication) network that is responsible for routing of SMS messages. The SMS- C can act as a relay between a sender and a recipient of a message. As such, the SMS- C can ensure that the message is delivered to the correct destination. The SMS-C may also manage the storage and retrieval of a message in case a (e.g. intended) recipient is not available to receive the message (e.g. at the time of delivery). In order to demonstrate the improvements provided by the techniques described herein for communication exchange in a network, some issues with existing techniques will first be described with reference to Figure 1.

[0047] Figure 1 illustrates an example of a method for communication exchange in a network, showing a common API interaction set up. As illustrated in Figure 1 , the network comprises an application node, a proxy node, and a device. For the purpose of the example illustrated in Figure 1 , the device is a constrained endpoint. As also illustrated in Figure 1 , the application node is configured to operate in accordance with HTTP, transmission control protocol (TCP), and internet protocol (IP). In contrast, the device of Figure 1 is configured to operate in accordance with CoAP and SMS. As such the protocols used by the application node and the device are different, and the proxy node serves to translate between the different protocols to enable communication between the application node and the device.

[0048] As illustrated in Figure 1 , the application node transmits an HTTP request to the proxy node. As mentioned above, a message proxy, which as the proxy node of Figure 1 , can be used to interface between different domains by enabling translation of protocols between those domains. Thus, as illustrated in Figure 1 , the proxy node translates the HTTP request, received from the application node, into a CoAP request and forwards the CoAP request to the device.

[0049] As illustrated in Figure 1 , upon receipt of the CoAP request, the device transmits a CoAP response to the proxy node. On receipt of the response from the device, the proxy node translates the response to HTTP and forwards the translated response to the application node.

[0050] In existing techniques such as that illustrated in Figure 1 , there may be a desire in the network to send a message such as an HTTP request from the application node, with minimal communication to an endpoint that may be constrained, such as the device of Figure 1. However, the endpoint will typically still send some response that will be mapped to HTTP and sent to the initially transmitting node (e.g., the application node of Figure 1). The existing technique illustrated in Figure 1 can therefore be wasteful of network resources by requiring the unnecessary exchange of communications between network elements. Figure 2 is a flow chart illustrating process steps in a method 100 performed by a proxy node in accordance with an example of the present disclosure. The method is for facilitating delivery of a first message to a computing device over a communication network.

[0051] With reference to Figure 2, in step 110 of the method, the first message is received from a server node. An intended recipient of the first message is the computing device, and the first message is received over a first application layer protocol. The first application layer protocol may be, for example, HTTP. In step 120, the first message is mapped to a second application layer protocol, different to the first application layer protocol. The second application layer protocol may be, for example, CoAP or MQTT. In some examples, mapping the first message may comprise translating the first message from the first application layer protocol to the second application layer protocol. In step 130, the mapped first message is encoded into SMS protocol data units (PDlls). Herein, a PDU may be defined as a single unit of information transmitted among peer entities of a network. In step 140, the encoded first message is forwarded to an SMS-C, and in step 150, a delivery report for the encoded first message is received from the SMS-C. In step 160, a delivery confirmation for the first message is sent to the server node over the first application layer protocol. The delivery confirmation specifies that the first message has been transmitted to the computing device.

[0052] Each of the proxy node preforming the method 100, and the server node from which the first message is received, may comprise a physical or virtual node, and may be implemented in a computer system, computing node or server apparatus, and / or in a virtualized environment, for example in a cloud, edge cloud or fog deployment. Examples of a virtual node may include a piece of software or computer program, a code fragment operable to implement a computer program, a virtualized function, or any other logical entity. The proxy node and / or the server node may encompass multiple logical entities cand may, for example, comprise Virtualized Network Functions (VNFs).

[0053] In some examples, the server node may comprise an application, a message queue telemetry transport for sensor networks (MQTT-SN) broker, or any other server node. In some examples, the computing device can be referred to herein as an “endpoint” and / or “constrained endpoint”. For example, the computing device may be a constrained cellular endpoint. In some examples, the second application layer protocol may be a request-response protocol such as CoAP, a publisher-subscriber protocol such as MQTT-SN, or any other application layer protocol, including for example Matter (Connectivity Standards Alliance) or the Advanced Message Queuing Protocol (AMQP) (Organization for the Advancement of Structured Information Standards). The second application layer protocol may be an loT protocol. An loT protocol can be defined herein as a protocol specifically developed for loT devices, or constrained devices. As such, an loT protocol may exclude general protocols such as HTTP that may nonetheless be at least partially supported by some loT devices. As discussed in further detail below, the loT protocol may be a User Datagram Protocol (UDP)-based protocol, and may be operable to be transported over SMS.

[0054] MQTT is an loT messaging protocol that defines different types of messages for improving the reliability of message exchange between MQTT devices. MQTT is a data centric protocol using a publish / subscribe paradigm. MQTT is event driven, with messages pushed to subscribed client devices. MQTT may offer improvements in reliability compared to CoAP, and the MQTT and CoAP protocols demonstrate significant differences, both architecturally and in terms of semantics.

[0055] As mentioned above, the delivery confirmation of the method 100 specifies only that the first message has been transmitted to the computing device, but does not provide any information about whether or not the computing device has begun parsing the first message. The delivery confirmation message is therefore distinguished from a normal response message. For example, although a normal response message may allow a server node such as an application server to infer that delivery has taken place, a normal response message may additionally specify other information relating to the result of the computing device actually parsing the message.

[0056] The method 100 described above therefore enables the provision of delivery confirmation to the server node without requiring a response from the computing device. Furthermore, as the delivery confirmation can be provided earlier than a response would be available from the computing device, the method 100 offers particular advantages for scenarios requiring low latency. That is, the method 100 provides for a server node to be made aware of delivery confirmation earlier than a response could be provided by the computing device. Figure 3 is a flow chart illustrating process steps in a method 200 performed by a server node in accordance with an example of the present disclosure. The method is for communicating with a computing device over a communication network. The method 100 as described with reference to Figure 2 may be complemented by the method 200 of Figure 3.

[0057] With reference to Figure 3, in step 210, a first message is sent to a proxy node. An intended recipient of the first message is the computing device, and the first message is sent over a first application layer protocol, to be mapped to a second application layer protocol by the proxy node. In step 220, a delivery confirmation for the first message is received from the proxy node over the first application layer protocol. The delivery confirmation specifies that the first message has been transmitted to the computing device.

[0058] Figure 4 is a flow chart illustrating process steps in a method 300 performed by a management node in accordance with an example of the present disclosure. The method is for managing delivery of messages to a computing device over a communication network by a proxy node. The method 100 as described with reference to Figure 2 and / or the method 200 as described with reference to Figure 3 may be complemented by the method 300 of Figure 4.

[0059] With reference to Figure 4, in step 310, the management node determines that a condition is fulfilled for provision of delivery confirmation for messages sent to the computing device. In step 320, an instruction is sent, to the proxy node, to provide delivery confirmation for messages sent to the computing device. As illustrated at 320a, the delivery confirmation specifies that the first message has been transmitted to the computing device.

[0060] Methods according to examples of the present disclosure thus provide improvements in communication exchange in a communication network by using a proxy node that acts as a middleman or proxy interposed between a server node such as an application, and a computing device such as a constrained cellular endpoint. Example methods disclosed herein reduce the quantity of messages exchanged between the server node and the computing device, while still providing the server node with information regarding delivery of a message sent to the computing device. In this manner, fire-and forget semantics are supported by enabling the transmission, by a server node, of a message to a computing device that does not require a response, and ensuring that the server node is nonetheless able to know whether the message has been delivered to the computing device.

[0061] In a particular example, example methods disclosed herein allow a server node to be made aware of the delivery status of a CoAP NoResponse request. CoAP endpoints are required to honour the REST semantics and reply to requests, this applies both to Confirmable (CON) and Non Confirmable (NON) messages. The CoAP NoResponse Option (which can be used with either CON or NON messages, although NON would be the more usual choice) is not enabled by default on CoAP endpoints. That is, even if the response message is empty, a response message is still required in order to fulfil REST request / response semantics. Specifically, when using NON messaging, the computing device, for example a constrained endpoint, will still have to reply to the request with a Non-Confirmable response. This depletes the computing device’s battery and consumes spectrum. When the CoAP NoResponse option is enabled, the CoAP server can "safely" suppress responses. If a NoResponse message is used, the response from the computing device is consequently avoided, but the server node has no information about whether the computing device has received the message. By applying example methods disclosed herein to CoAP scenario, the proxy node can convert a NoResponse request to SMS, which can then be delivered to the computing device. The proxy node can then assess, on behalf of the server node, the delivery status of the message using for example a third generation partnership project (3GPP) SMS-C function. In this manner a degree of reliability is provided in the message exchange without placing additional burden on either the computing device or the network.

[0062] Figure 5 is a flow chart illustrating process steps in a further example of a method 400 performed by a proxy node. The steps of the method 400 of Figure 5 illustrate example ways in which the steps of the method 100, described with reference to Figure 2, may be implemented and supplemented in order to achieve the above discussed and additional functionality.

[0063] With reference to Figure 5, in step 410, a first message is received from a server node. The receipt of the first message can be as described with reference to step 110 of Figure 2. In steps 420 and 430, in some examples, on receipt of the first message from the server node, the proxy node may determine whether the first message is to be forwarded to the computing device with delivery confirmation. In step 440, in some examples, if the first message is to be forwarded to the computing device with delivery confirmation, then the proxy node may proceed with subsequent method steps. For example, the proxy node may proceed with subsequent steps of the method as described with reference to steps 120 to 160 of Figure 2. In step 450, in some examples, if the first message is not to be forwarded to the computing device with delivery confirmation, the proxy node may map the first message to a second application layer protocol, different to the first application layer protocol. In step 460, in some examples, the proxy node may then forward the mapped first message to the computing device.

[0064] Steps 420 and 430 may thus enable the proxy node to determine whether delivery confirmation should be provided. As such, the carrying out of subsequent steps (including for example the encoding step as described with reference to step 130 of Figure 2) may be dependent on this determination. For example, if the proxy node determines that the delivery confirmation should not be provided, then the proxy node may simply map the first message to the second application layer protocol and then forward it directly to the computing device. Therefore, determining whether the first message is to be forwarded to the computing device with delivery confirmation provides a greater degree of flexibility in the application of the method. Greater flexibility can allow the method to be used alongside and support existing reliability mechanisms of the second application layer protocol (e.g., CoAP or MQTT-SN).

[0065] In step 420, in some examples, determining whether the first message is to be forwarded to the computing device with delivery confirmation may comprise at least one of the steps illustrated at 420a, 420b and 420c. In 420a, in some examples, determining whether the first message is to be forwarded to the computing device with delivery confirmation may comprise identifying a request for delivery confirmation included in the first message. Thus, the server node may include a request for delivery confirmation in the first message sent (e.g., via an API) to the proxy node. Alternatively, or in addition, in 420b, determining whether the first message is to be forwarded to the computing device with delivery confirmation may comprise determining that an instruction to provide delivery confirmation applies to the first message. Alternatively, or in addition, in 420c, determining whether the first message is to be forwarded to the computing device with delivery confirmation may comprise determining that a condition for provision of delivery confirmation is fulfilled. A request to provide delivery confirmation may be included in the first message in a variety of different ways. For example, a payload of the first message may comprise a value of a new attribute, for example “message type”. The value may be indicative that the provision of delivery confirmation is requested. In some examples, an instruction to provide delivery confirmation may be received by the proxy node separately from the first message. In some of these examples, the instruction to provide delivery confirmation may be received from a different entity to the server node that sent the first message. This entity may be referred to herein as an instructing or management entity. In some examples, the instructing or management entity may be a management node, such as a device management platform which may have responsibility for the computing device, or a data management platform. The instructing or management entity may instruct provision of delivery confirmation for a range of reasons, as described in more detail below.

[0066] As mentioned above, in some examples, determining whether the first message is to be forwarded to the computing device with delivery confirmation may comprise determining that a condition for provision of delivery confirmation is fulfilled. In some examples, the condition may be a device condition. For example, the condition may be that a device battery level meets a criterion, such as a minimum threshold value. In some examples, the condition may be a network condition. For example, the condition may be that network congestion meets a criterion, such as a threshold congestion level. Although some types of condition have been described above, it will be understood that the condition may be any type of condition.

[0067] Figure 6 is a flow chart illustrating further process steps that may be carried out by the proxy node as part of the method 400, and in the event that the proxy node determines that the first message should be forwarded to the computing device with delivery confirmation. The process steps illustrated in Figure 6 this provide further examples of how the steps of the method 100 may be implemented and supplemented to provide the above discussed and additional functionality.

[0068] With reference to Figure 6, and following completion of steps 120, 130 and 140 (mapping and encoding the received first message, and forwarding to an SMS-C), the proxy node may in step 442 send, to the server node and over the first application layer protocol, a delivery status for the first message. Therefore, an early notification may be transmitted to the server node that indicates that delivery of the first message is in progress. As illustrated at 442a, in some examples, the delivery status for the first message may be sent on fulfilment of a condition. As illustrated at 442ai, in some examples, the condition may comprise at least one of (i) receipt of the first message from the server node, or (ii) receipt from the SMS-C of confirmation that the SMS-C has received the encoded first message for forwarding to the computing device.

[0069] Thus, in some examples, there may be one or more conditions to be fulfilled in order for the delivery status for the first message to be sent to the server node. For example, the delivery status may be sent substantially immediately on receipt of an HTTP message from the server node. In another example, the delivery status may be sent following an SMS-C response but before receipt of an SMS-C delivery report.

[0070] In step 444, in some examples, the proxy node may request, from the SMS-C, delivery status information for the encoded first message. In some examples, the request to the SMS-C for delivery status information may be an explicit one-off request. Alternatively, or in addition, in some examples the request may be a function triggering provision by the SMS-C of delivery status for any encoded message sent to the SMS-C for forwarding (for example a webhook or call back function). The delivery report received form the SMS-C in step 160 may in some examples be provided by the SMS-C in response to the request of step 444. In some examples, the delivery report for the encoded first message may confirm that the encoded first message has been transmitted to the computing device.

[0071] In some examples, the second application layer protocol may comprise an Internet of Things (loT) application layer protocol as defined herein. For example, an loT application layer protocol may comprise an loT protocol that uses an unreliable transport protocol. As such, an loT protocol may have other means, built into the loT protocol, to provide a degree of reliability. Reliability functionality imposes some demands on an loT device, and thus the ability to provide reliability information without requiring action by the loT device offers considerable advantage.

[0072] According to examples of the present disclosure, the second application layer protocol may comprise loT protocol that uses an unreliable transport protocol, and so has other means, built into the loT protocol, to provide some degree of reliability. This reliability functionality will inevitably pose some demands on an loT device, and so the ability of methods of the present disclosure to provide reliability information without requiring action by the loT device offers considerable advantage. In some examples, the second application layer protocol may comprise at least one of a Constrained Application Protocol (CoAP), a Message Queuing Telemetry Transport (MQTT), or a MQTT for sensor networks (MQTT-SN). In some examples, the first application layer protocol may not be an loT (that is an loT specific) protocol. For example, the first application layer protocol may be HTTP.

[0073] According to examples of the present disclosure, the computing device may comprise a constrained device as described herein. In some examples, the computing device may run at least one of a CoAP server, an MQTT client, or an MQTT-SN client. In some examples, the server node may run at least one of an application server, an MQTT Broker, or an MQTT-SN Broker.

[0074] In some examples, mapping the first message to a second application layer protocol, different to the first application layer protocol, may comprise mapping the first message to a CoAP No Response message. In some examples, encoding the mapped first message into SMS PDlls may comprise mapping a Unique Resource Identifier (URI) of the computing device to an SMS transport layer number.

[0075] Figure 7 is a flow chart illustrating process steps in a further example of a method 600 performed by a server node. The steps of the method 600 of Figure 7 illustrate example ways in which the steps of the method 200, described with reference to Figure 3, may be implemented and supplemented in order to achieve the above discussed and additional functionality.

[0076] With reference to Figure 7, in step 602, the server node may determine that delivery confirmation for a first message is to be requested. In some examples, the determination may be made on the basis of the nature of an application running on the server node, the nature of the first message (e.g., if the first message comprises a fire and forget message), or any other condition of which the server node is aware. In step 610, the server node sends the first message to the proxy node. The sending of the first message can be as described with reference to step 210 of Figure 3. In step 610a, if the server node has determined that delivery confirmation should be requested, the server node may include in the first message a request for confirmation of delivery of the first message to the computing device. As described above, in some examples, the request to provide delivery confirmation may be included in the first message payload, such as a value of a new attribute (e.g., “message type”).

[0077] In step 612, in some examples the server node may receive, from the proxy node and over the first application layer protocol, a delivery status for the first message. In step 620, the server node receives, from the proxy node and over the first application layer protocol, a delivery confirmation for the first message, as described herein. The receipt of the delivery confirmation can be as described with reference to step 220 of Figure 3.

[0078] Figure 8 is a flow chart illustrating additional detail relating to the method 300 performed by a management node. As set out above, the method 300 performed by the management node comprises determining that a condition is fulfilled for provision of delivery confirmation for messages sent to the computing device in step 310, and sending to the proxy node an instruction to provide delivery confirmation for messages sent to the computing device in step 320, wherein the delivery confirmation specifies that the first message has been transmitted to the computing device.

[0079] Figure 8 illustrates examples of what may be comprised within the provision of delivery confirmation for a message sent to the computing device, which provision is instructed by the management node in step 320. As illustrated 320a, in some examples, providing the delivery confirmation may comprise, performing steps 320a to 320e. In step 320a, on receipt of the first message from a server node over a first application layer protocol, the message is mapped to a second application layer protocol, different to the first application layer protocol. Step 3202b comprises, encoding the mapped message into SMS PDlls. Step 320c comprises forwarding the encoded message to a communication network SMS-C. Step 320d comprises receiving, from the SMS-C, a delivery report for the encoded message, and step 320e comprises sending, to the server node over the first application layer protocol, a delivery confirmation for the first message. As illustrated at 320f, the delivery confirmation may specify that the first message has been transmitted to the computing device.

[0080] In some examples, the condition for provision of delivery confirmation for messages sent to the computing device may comprise at least one of a computing device condition as described herein, or a communication network condition as described herein. A computing device condition may include for example a condition relating to device battery power, device processing load, and / or device free memory. A communication network condition may include for example a condition relating to network congestion, network signal strength to the device, and / or network power saving measures.

[0081] Example methods disclosed herein thus reduces the number of messages issued by a computing device such as a constrained cellular endpoint or cellular loT device, and therefore reduces device energy consumption and improves spectrum efficiency.

[0082] Figures 2 to 8 discussed above provide an overview of methods 100, 200, 300, 400, and 600 which may be performed according to different examples of the present disclosure. There now follows a detailed discussion of how the methods described above may be implemented. In particular, the following detailed discussion describes how one or more of the methods discussed above may be implemented with regards to standard protocols including for example CoAP (request-response) and MQTT-SN (publisher-subscriber).

[0083] Many of the examples of the method presented herein are described with reference to standard protocols, such as CoAP. However, it will be understood that the techniques can be applied to other scenarios and application layer protocols, and may offer particular advantages when used in connection with application layer protocols that are suitable for loT, use an unreliable transport layer protocol, and consequently have additional reliability measures that pose requirements on a constrained device executing the protocol. Example methods of the present disclosure provide reliability without requiring additional action form the computing device, and thus for example can maintain the benefits to the device of a CoAP NoResponse message, while also providing an application server corresponding with the device with a degree of reliability.

[0084] Figure 9 is a diagram illustrating an exchange of signals in a system according to an example of the present disclosure. The system illustrated in Figure 9 comprises a server node (“application”), a proxy node (“Proxy”), a computing device (“Device”), and an SMS- C. The server node and the proxy node can be configured to operate in accordance with the methods as described herein in respect of the server node and proxy node respectively. In the example illustrated in Figure 9, the proxy node and the SMS-C may be configured to be at the same location in a communication network (e.g. located within the same entity). However, it will be understood that the configuration illustrated in Figure 9 is merely an example and that, in other examples, the proxy node and the SMS- C may be configured at different locations in the communication network. For example, the proxy node and the SMS-C may be configured in a distributed fashion (e.g. the proxy node and SMS-C can be, or can be comprised in, different network entities).

[0085] As illustrated in Figure 9, in some examples, the server node may be configured to support a first suite of protocols (e.g., HTTP, TCP and IP). As also illustrated in Figure 9, in some examples, the computing device may be configured to support a second suite of protocols (e.g., CoAP, SMS, category M (CatM), and Narrowband-loT (NB-loT).

[0086] As illustrated in Figure 9, the server node sends a first message to a proxy node. The intended recipient of the first message is the computing device, and the first message is sent over a first application layer protocol, to be mapped to a second application layer protocol by the proxy node (step 210 of method 200). Thus, the proxy node receives the first message from the server node (step 110 of method 100). As illustrated in Figure 9, in some examples, the first application layer protocol may be HTTP, and the second application layer protocol may be CoAP. As also illustrated in Figure 9, in some examples, the first message may comprise a request (e.g., “http req”). In some examples, the request may be an API request. In some examples, the first message may comprise a specific attribute. For example, the server node may inject the specific attribute into an HTTP request comprised in the first message (step 610 of method 600). The specific attribute may be, for example, an HTTP header extension or a JavaScript object notation (JSON) attribute comprised in a payload of the first message. The specific attribute can raise awareness among the network entities in the communication path, including for example the proxy node, that the destination node for the message, that is the computing device or constrained cellular endpoint, does not need to reply. As mentioned above, removing the requirement to reply to the first message beneficially extends the battery life of the computing device. Specific HTTP responses can be used to ensure that the server node requirements are fulfilled.

[0087] As an example, using the KNX loT API, the server node may trigger the proxy node to provide delivery confirmation by adding to the first message, for example in the message payload, a JSON attribute “message_type” with value “constrained”, as shown in the listing below:

[0088] HTTP POST https: / / iotapi.company.com / ep / ep123

[0089] Content-Type: application / json

[0090] Payload: {

[0091] "from": "iotapi.app123.company.com",

[0092] "to": "coap: / / [2001 :0db8: : : :85a3]",

[0093] "message_type": "constrained",

[0094] "template":{

[0095] "name":"knxiot:technology:device",

[0096] "parameters": [

[0097] { "path": " / .well-known / knx",

[0098] "2": "restart"}

[0099] }

[0100] }

[0101] As illustrated in Figure 9, the proxy node maps the first message to a second application layer protocol, different to the first application layer protocol (step 120 of method 100). In the example illustrated in Figure 9, the mapping can be referred to as an HTTP-CoAP mapping (e.g. HTTP-CoAP translation). In some examples, the proxy node may perform the mapping in response to receiving the first message (e.g., comprising a server node request). In some examples, the proxy node may create a second application layer CoAP message that uses a No Response flag, instead of a NON message. The proxy node encodes the mapped first message into SMS PDlls (step 130 of method 100). In some examples, the proxy node may map a URI of the computing device (e.g., constrained cellular endpoint) to the number used by an SMS transport layer. This action may suppress all the responses from the computing device, which may then perform requested operation(s) and may switch to power saving mode.

[0102] The proxy node forwards the encoded first message to the SMS-C (step 140 of method 400). The proxy node may query the SMS-C to request information about message delivery status (e.g., “submitted but not delivered”, rather than “delivered”). The proxy node receives, from the SMS-C, a delivery report for the encoded first message (step 150 of method 100). In some examples, after receiving the SMS-C delivery report (e.g., response), or just after receipt of the first message if latency is particularly important, the proxy may send to the server node a response (for example an HTTP response) with the information that the delivery is in process (step 442 of method 400). The proxy node sends to the server node over the first application layer protocol (e.g., HTTP), a delivery confirmation for the first message (step 160 of method 100). The delivery confirmation specifies that the first message has been transmitted to the computing device. Therefore, when the first message, encoded in SMS PDlls, is delivered to the computing device, the SMS-C sends a message to the proxy, which in turn sends to the server node a reliability message that maps to the SMS-C current status. The delivery confirmation may comprise a specific HTTP response code, such as “103 Early Hints”. In some examples, in response to the receipt of the delivery confirmation, the server node may fulfil one or more requirements. For example, the server node may start to execute one or more other tasks, and / or prepare for a next interaction with one or more other devices and / or the rest of the system.

[0103] Figure 10 is a diagram illustrating an exchange of signals in a system according to an example. The system illustrated in Figure 10 may be understood with reference to the system illustrated in Figure 9 above. The example illustrated in Figure 10 shows an interaction between a server node such as an application server and a computing device such as a CoAP constrained cellular endpoint, through a proxy node.

[0104] The interaction illustrated in Figure 10 can enable the server node to execute one or more other application tasks upon reception of a response (e.g., an HTTP code with code 103). Below is an example of an HTTP “103 Response” from the proxy node, which may be included in a response payload received from the proxy node:

[0105] {

[0106] “request Jd”: “400677017b6d4d5388f26ba517d8a4c0”,

[0107] “accountjd”: “6f73XXXX”,

[0108] “number”: “3584429XXXXX”,

[0109] “date_submitted”: “2022-10-13 07:40:51”,

[0110] “date_finalized”: “2022-10-13 07:43:20”,

[0111] “request_status”: “PROCESSI NG”,

[0112] “status”: “delivered”

[0113] }

[0114] Figures 9 and 10 above illustrate examples in which the methods disclosed herein may be used in a request-response architecture. However as mentioned above, the techniques disclosed herein can be used in other scenarios. For example, the techniques disclosed herein may be similarly used in a publisher-subscriber architecture such as MQTT-SN. The methods disclosed herein can be used to provide quality of service (QoS) 1 and 2 delivery (e.g., at least once and / or exactly once), while implementing features of MQTT that normally result in QoS 1 (e.g. at most once with no acknowledgement (ack)).

[0115] Figure 11 is a diagram illustrating an exchange of signals in a system according to an example of the present disclosure. The system illustrated in Figure 11 comprises a first server node (“application”), a second server node (“Broker”), a proxy node (“Proxy”), a computing device (“Device”), and an SMS-C. The first server node and the second server node can be configured to operate in accordance with the methods as described herein in respect of the server node. The proxy node can be configured to operate in accordance with the methods as described herein in respect of the proxy node. In the example illustrated in Figure 11 , the proxy node and the SMS-C may be configured to be at the same location in a communication network (e.g., located within the same entity). However, it will be understood that the configuration illustrated in Figure 11 is merely an example and that, in other examples, the proxy node and the SMS-C may be configured at different locations in the communication network. For example, the proxy node and the SMS-C may be configured in a distributed fashion (e.g., the proxy node and SMS-C can be, or be comprised in, different network entities).

[0116] As illustrated in Figure 11 , in some examples the application may communicate with the device via the broker (second server node, which may be an MQTT-SN broker) and the proxy node. The application may publish information to one or more channels maintained by the broker, and may subscribe to one or more information channels maintained by the broker. The computing device may publish information, such as sensor updates for example, to one or more information channels maintained by the broker, and may be subscribed to one or more control channels. A control channel can be used to instruct a constrained device (e.g., the computing device) to cease or to resume sending updates, such as sensor updates, according to whether or not there is at least there is at least one active subscriber application for such updates. As such, a computing device subscribed to a control channel may pause sending updates to prolong battery life of the computing device. A control channel can also be used to shut down update transmissions when no active subscriber application is present in the system.

[0117] As illustrated in Figure 11 , in some examples, the second server node (e.g., the MQTT- SN Broker) may instruct the computing device to suspend and / or resume the transmission of messages such as sensor updates. The proxy node may leverage the SMS-C interface to know whether the message from the broker was received at the computing device. In response to delivery completion, the proxy node may inform the broker of the successful reception of the first message.

[0118] The broker can consequently be made aware of whether or not the computing device has received the control message without requiring the computing device to send an acknowledgment, thus preserving energy for the device. After sending the control message on behalf of the broker, the proxy node can leverage the SMS-C interface to understand whether the computing device received the message, based on an SMS-C delivery status. Upon successful delivery, the proxy can confirm to the broker that its message was delivered. In this manner, a higher MQTT-SN QoS level (1 and 2) may be provided without any burden on the computing device.

[0119] Examples of the methods disclosed herein may be optimized for minimal latency. For example, the proxy node may implement a webhook or call back function to the SMS-C to ensure delivery status notifications are provided automatically. Alternatively, or in addition, the proxy node may send an immediate (e.g., HTTP) response to the server node (e.g. application) with delivery status information (i.e. , delivery in progress).

[0120] As discussed above, the methods 100, 400 may be performed by a proxy node, and the present disclosure provides a proxy node that is adapted to perform any or all of the steps of the above discussed methods.

[0121] Figure 12 is a block diagram illustrating a proxy node 800 which may implement the methods 100, 400, described herein in respect of the proxy node 800, for example on receipt of suitable instructions from a computer program 850. Referring to Figure 12, the proxy node 800 comprises a processor or processing circuitry 802, and may comprise a memory 804 and interfaces 806. The processing circuitry 802 is operable to perform some or all of the steps of the methods 100, 400, as discussed above with reference to Figures 2, 5 and 6. The memory 804 may contain instructions executable by the processing circuitry 802 such that the proxy node 800 is operable to perform some or all of the steps of the methods 100, 400. The instructions may also include instructions for executing one or more telecommunications and / or data communications protocols. The instructions may be stored in the form of the computer program 850. The interfaces 806 may comprise one or more interface circuits supporting wired or wireless communications according to one or more communication protocols. The interfaces 806 may support exchange of messages in accordance with examples of the methods disclosed herein.

[0122] As discussed above, the methods 200, 600 may be performed by a server node, and the present disclosure provides a server node that is adapted to perform any or all of the steps of the above discussed methods.

[0123] Figure 13 is a block diagram illustrating a server node 900 which may implement the methods 200, 600 described herein in respect of the server node 900, for example on receipt of suitable instructions from a computer program 950. Referring to Figure 13, the server node 900 comprises a processor or processing circuitry 902, and may comprise a memory 904 and interfaces 906. The processing circuitry 902 is operable to perform some or all of the steps of the methods 200, 600 as discussed above with reference to Figures 3 and 7. The memory 904 may contain instructions executable by the processing circuitry 902 such that the server node 900 is operable to perform some or all of the steps of the methods 200, 600. The instructions may also include instructions for executing one or more telecommunications and / or data communications protocols. The instructions may be stored in the form of the computer program 950. The interfaces 906 may comprise one or more interface circuits supporting wired or wireless communications according to one or more communication protocols. The interfaces 906 may support exchange of messages in accordance with examples of the methods disclosed herein.

[0124] As discussed above, the method 300 may be performed by a management node, and the present disclosure provides a management node that is adapted to perform any or all of the steps of the above discussed method.

[0125] Figure 14 is a block diagram illustrating a management node 1000 which may implement the method 300 described herein in respect of the management node 1000, for example on receipt of suitable instructions from a computer program 1050. Referring to Figure 14, the management node 1000 comprises a processor or processing circuitry 1002, and may comprise a memory 1004 and interfaces 1006. The processing circuitry 1002 is operable to perform some or all of the steps of the method 300 as discussed above with reference to Figures 4 and 8. The memory 1004 may contain instructions executable by the processing circuitry 1002 such that the management node 1000 is operable to perform some or all of the steps of the method 300. The instructions may also include instructions for executing one or more telecommunications and / or data communications protocols. The instructions may be stored in the form of the computer program 1050. The interfaces 1006 may comprise one or more interface circuits supporting wired or wireless communications according to one or more communication protocols. The interfaces 1006 may support exchange of messages in accordance with examples of the methods disclosed herein.

[0126] The present disclosure also provides a computer program product 1500 comprising a computer readable medium 1510, the computer readable medium having computer readable code 1520 embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform a method according to any one or more of the examples disclosed herein.

[0127] The present disclosure also provides a computer program 1520 comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one or more of the examples disclosed herein.

[0128] Examples of the present disclosure thus provide methods for communication exchange in a communication network which reduce the number of messages issued by a computing device such as a constrained cellular endpoint or a cellular loT device, therefore reducing the energy consumption of the computing device and improving spectrum efficiency. As a consequence, when the methods disclosed herein are applied to wireless constrained endpoints, spectrum efficiency on the endpoints’ local network is also improved. The methods disclosed herein enable a server node such as an application server to be provided with delivery confirmation of a message sent to a computing device, which may be a constrained endpoint, without the computing device responding to the message. In this manner, the methods enable the semantics of request-response protocols without a receiver having to respond to the request. The methods also improve the response time for a server node making requests toward constrained endpoints. In the case of an HTTP request, for example, the methods allow for faster response time in III and APIs, as a proxy node responds on behalf of the constrained endpoint.

[0129] It will be appreciated that examples of the present disclosure may be virtualized, such that the methods and processes described herein may be run in a cloud environment. Figure 16 shows an example of a communication system 1600 in accordance with some embodiments.

[0130] In the example, the communication system 1600 includes a telecommunication network 1602 that includes an access network 1604, such as a radio access network (RAN), and a core network 1606, which includes one or more core network nodes 1608. The access network 1604 includes one or more access network nodes, such as network nodes 1610a and 1610b (one or more of which may be generally referred to as network nodes 1610), or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 1602 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 1602 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 1602, including one or more network nodes 1610 and / or core network nodes 1608.

[0131] Examples of an ORAN network node include an open radio unit (0-Rll), an open distributed unit (0-Dll), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1 , F1 , W1 , E1 , E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes 1610 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1612a, 1612b, 1612c, and 1612d (one or more of which may be generally referred to as UEs 1612) to the core network 1606 over one or more wireless connections.

[0132] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1600 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 1600 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0133] The UEs 1612 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1610 and other communication devices. Similarly, the network nodes 1610 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 1612 and / or with other network nodes or equipment in the telecommunication network 1602 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 1602.

[0134] In the depicted example, the core network 1606 connects the network nodes 1610 to one or more hosts, such as host 1616. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1606 includes one more core network nodes (e.g., core network node 1608) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1608. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (ALISF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0135] The host 1616 may be under the ownership or control of a service provider other than an operator or provider of the access network 1604 and / or the telecommunication network 1602, and may be operated by the service provider or on behalf of the service provider. The host 1616 may host a variety of applications to provide one or more services. Examples of such applications include the provision of live and / or pre-recorded audio / video content, data collection services, for example, retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0136] As a whole, the communication system 1600 of Figure 16 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0137] In some examples, the telecommunication network 1602 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1602 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1602. For example, the telecommunications network 1602 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0138] In some examples, the UEs 1612 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1604 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1604. Additionally, a UE may be configured for operating in single- or multi-RAT or multistandard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR- DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0139] In the example illustrated in Figure 16, the hub 1614 communicates with the access network 1604 to facilitate indirect communication between one or more UEs (e.g., UE 1612c and / or 1612d) and network nodes (e.g., network node 1610b). In some examples, the hub 1614 may be a controller, router, a content source and analytics node, or any of the other communication devices described herein regarding UEs. For example, the hub 1614 may be a broadband router enabling access to the core network 1606 for the UEs. As another example, the hub 1614 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1610, or by executable code, script, process, or other instructions in the hub 1614. As another example, the hub 1614 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1614 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1614 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1614 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1614 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0140] The hub 1614 may have a constant / persistent or intermittent connection to the network node 1610b. The hub 1614 may also allow for a different communication scheme and / or schedule between the hub 1614 and UEs (e.g., UE 1612c and / or 1612d), and between the hub 1614 and the core network 1606. In other examples, the hub 1614 is connected to the core network 1606 and / or one or more UEs via a wired connection. Moreover, the hub 1614 may be configured to connect to an M2M service provider over the access network 1604 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1610 while still connected via the hub 1614 via a wired orwireless connection. In some embodiments, the hub 1614 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 1610b. In other embodiments, the hub 1614 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1610b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0141] The methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

[0142] It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative examples without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

CLAIMS1 . A method for facilitating delivery of a first message to a computing device over a communication network, the method, performed by a proxy node (800), comprising: receiving (110, 410) the first message from a server node (900), wherein an intended recipient of the first message is the computing device, and wherein the first message is received over a first application layer protocol; mapping (120) the first message to a second application layer protocol, different to the first application layer protocol; encoding (130) the mapped first message into Short Messaging Service, SMS, Protocol Data Units, PDUs, forwarding (140) the encoded first message to a communication network SMS Centre, SMS-C; receiving (150) from the SMS-C a delivery report for the encoded first message; and sending (160), to the server node (900) over the first application layer protocol, a delivery confirmation for the first message, wherein the delivery confirmation specifies that the first message has been transmitted to the computing device.

2. A method as claimed in claim 1 , further comprising: on receipt of the first message from the server node (900), determining (420) whether the first message is to be forwarded to the computing device with delivery confirmation; and: if the first message is to be forwarded to the computing device with delivery confirmation, proceeding (440) with subsequent method steps; and if the first message is not to be forwarded to the computing device with delivery confirmation, mapping (450) the first message to a second application layer protocol, different to the first application layer protocol, and forwarding (460) the mapped first message to the computing device.

3. A method as claimed in claim 2, wherein, determining (420) that the first message is to be forwarded to the computing device with delivery confirmation comprises at least one of: identifying (420a) a request for delivery confirmation included in the first message;determining (420b) that an instruction to provide delivery confirmation applies to the first message; and determining (420c) that a condition for provision of delivery confirmation is fulfilled.

4. A method as claimed in any one of claims 1 to 3, wherein the delivery report for the encoded first message confirms that the encoded first message has been transmitted to the computing device.

5. A method as claimed in any one of the preceding claims, further comprising: sending (510), to the server node (900) over the first application layer protocol, a delivery status for the first message.

6. A method as claims in claim 5, further comprising: sending the delivery status for the first message on fulfillment of a condition comprising at least one of: receipt of the first message from the server node (900); or receipt from the SMS-C of confirmation that the SMS-C has received the encoded first message for forwarding to the computing device.

7. A method as claimed in claim 6, further comprising requesting (520), from the SMS-C, delivery status information for the encoded first message.

8. A method as claimed in any one of the preceding claims, wherein the second application layer protocol comprises an Internet of Things application layer protocol.

9. A method as claimed in any one of the preceding claims, wherein the second application layer protocol comprises at least one of:Constrained Application Protocol, CoAP;Message Queuing Telemetry Transport, MQTT;MQTT for Sensor networks, MQTT-SN.

10. A method as claimed in any one of the preceding claims, wherein the computing device comprises a constrained device.

11. A method as claimed in any one of the preceding claims, wherein the computing device is running at least one of: a CoAP server; an MQTT client; an MQTT-SN client.

12. A method as claimed in any one of the preceding claims, wherein the server node (900) is running at least one of: an application server; an MQTT Broker; an MQTT-SN Broker.

13. A method as claimed in any one of the preceding claims, wherein mapping (120) the first message to a second application layer protocol, different to the first application layer protocol, comprises mapping the first message to a CoAP No Response message.

14. A method as claimed in any one of the preceding claims, wherein encoding (130) the mapped first message into SMS PDlls comprises mapping a Unique Resource Identifier, URI, of the computing device to an SMS transport layer number.

15. A method for communicating with a computing device over a communication network, the method, performed by a server node (900), comprising: sending (210) a first message to a proxy node (800), wherein an intended recipient of the first message is the computing device, and wherein the first message is sent over a first application layer protocol, to be mapped to a second application layer protocol by the proxy node (800); and receiving (220, 640), from the proxy node (800) over the first application layer protocol, a delivery confirmation for the first message, wherein the delivery confirmation specifies that the first message has been transmitted to the computing device.

16. A method as claimed in claim 15, further comprising: including in the first message a request for confirmation of delivery of the first message to the computing device.

17. A method as claimed in claim 16, further comprising:determining (620) that delivery confirmation for the first message is to be requested.

18. A method as claimed in claim 15 or 16, further comprising: receiving (630), from the proxy node (800) over the first application layer protocol, a delivery status for the first message.

19. A method as claimed in any one of claims 15 to 17, wherein the second application layer protocol comprises an Internet of Things application layer protocol.

20. A method as claimed in any one of claims 15 to 18, wherein the second application layer protocol comprises at least one of:Constrained Application Protocol, CoAP;Message Queuing Telemetry Transport, MQTT;MQTT for Sensor networks, MQTT-SN.

21. A method as claimed in any one of claims 15 to 20, wherein the computing device comprises a constrained device.

22. A method as claimed in any one of claims 15 to 21 , wherein the computing device is running at least one of: a CoAP server; an MQTT client; an MQTT-SN client.

23. A method as claimed in any one of claims15 to 22, wherein the server node (900) is running at least one of: an application server; an MQTT Broker; an MQTT-SN Broker.

24. A method for managing delivery of messages to a computing device over a communication network by a proxy node (800), the method, performed by a management node (1000), comprising: determining (310) that a condition is fulfilled for provision of delivery confirmation for messages sent to the computing device; andsending (320) to the proxy node (800) an instruction to provide delivery confirmation for messages sent to the computing device; wherein the delivery confirmation specifies that the first message has been transmitted to the computing device.

25. A method as claimed in claim 24, wherein providing delivery confirmation for a message sent to the computing device comprises: on receipt of the first message from a server node (900) over a first application layer protocol, mapping (710a) the message to a second application layer protocol, different to the first application layer protocol; encoding (710b) the mapped message into Short Messaging Service, SMS, Protocol Data Units, PDUs, forwarding (710c) the encoded message to a communication network SMS Centre, SMS-C; receiving (71 Od) from the SMS-C a delivery report for the encoded message; and sending (71 Oe), to the server node (900) over the first application layer protocol, a delivery confirmation for the first message, wherein the delivery confirmation specifies that the first message has been transmitted to the computing device.

26. A method as claimed in claim 2 or 25, wherein the condition for provision of delivery confirmation for messages sent to the computing device comprises at least one of: a computing device condition; or a communication network condition.

27. A proxy node (800) comprising: processing circuitry (802) configured to operate in accordance with any of claims 1 to 14, and / or claim 26 when dependent on claim 2.

28. A proxy node (800) as claimed in claim 27, wherein: the proxy node (800) comprises: at least one memory (804) for storing instructions which, when executed by the processing circuitry (802), cause the proxy node (800) to operate in accordance with any of claims 1 to 14, and / or claim 26 when dependent on claim 2.

29. A server node (900) comprising: processing circuitry (902) configured to operate in accordance with any of claims 15 to 23.

30. A server node (900) as claimed in claim 29, wherein: the server node (900) comprises: at least one memory (904) for storing instructions which, when executed by the processing circuitry (902), cause the server node (900) to operate in accordance with any of claims 15 to 23.31 . A management node (1000) comprising: processing circuitry (1002) configured to operate in accordance with any of claims 24 to 26.

32. A management node (1000) as claimed in claim 27, wherein: the management node (1000) comprises: at least one memory (1004) for storing instructions which, when executed by the processing circuitry (1002), cause the management node (1000) to operate in accordance with any of claims 24 to 26.

33. A computer program product (1500) comprising a computer readable medium (1510), the computer readable medium having computer readable code (1520) embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform a method as claimed in any one of claims 1 to 26.

34. A computer program (1520) comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 to 26.

Images