Technical Field The present disclosure relates to nodes and methods for managing transport addresses associated with a computing device. The nodes include a storage node, a fetching node, an invoking node, a generating node, a management node and the computing device itself. The present disclosure also relates to a computer program and a computer program product configured, when run on a computer to carry out methods for managing transport addresses associated with a computing device.

Background

The “Internet of Things” (loT) refers to 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. Such 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. In loT deployments, constrained devices frequently require one or more gateways to enable them to connect to other networks, including local networks and wider networks which may be accessed via the Internet. Information collected from the constrained devices may then be used to create value in cloud environments. Many gateways via which an loT device may connect to a network employ Network Address Translation (NAT) between a local, private, network of the loT deployment and a wider network such as the Internet.

The functionality of an loT device can be described to other devices, management servers, application servers and any other entities or functions using a data structure. The data structure describes the capabilities of the device, and how to interact with them. This data structure may be given a variety of names depending on the protocols and frameworks used by the device. For the purposes of the present disclosure, a data structure describing capabilities of a device is referred to as a “Thing Description”, which is consistent with terminology used in the World Wide Web Consortium (W3C) Web of Things Architecture, as set out at https://w3c.github.io/wot-architecture/. There are different types of capabilities that may be associated with a device, as set out below:

“Action” capabilities enable triggering actions on a device, for example to request to reboot the device.

“Property” capabilities enable reading and writing values, for example to read a sensor value from the device.

“Event” capabilities enable subscribing to notifications associated with device state and device state changes etc., for example a notification may be triggered when a sensor value is reaching a defined threshold value.

If a device is using the Open Mobile Alliance Lightweight Machine to Machine (LwM2M) framework, the device may be referred to as a “Smart Object”, and its capabilities may be referred to as “Resources”. An IPSO Smart Object is a specified collection of reusable resources that has a defined object ID and which represents a particular type of physical sensor, actuator, connected object or other data source. The Web of Things also uses the term “Resource” to refer to capabilities of devices or “Things”. Each resource associated with a device is named using a unique Uniform Resource Identifier (URI), that can be used to address the resource by any function that seeks to invoke the resource in some way, referred to herein as an Invoking function or invoking node. IETF RFC 3986 establishes the generic syntax for a URI, which must include at least a scheme name and a path, and may additionally include an authority, a query and other components.

Typically the URI of a resource is associated, either directly by inclusion within the URI or indirectly via a Domain Name System (DNS) query, with a local IP address and port number of the device with which the resource is associated, together with the path that points to that particular resource on the device.

An example resource URI may read as follows: coap://192.156.456.34:5683/5/0/1

“coap” is the scheme component of the URI and provides the name of the protocol used by the device associated with the resource. “192.156.456.34:5683” is the authority component of the URI and indicates the IP address and port number of the device associated with the resource.

75/0/1” is the path component of the URI and indicates the specific resource of the device. If an loT device is located behind one or more Network Address Translators (NATs), and if the device has been assigned a private IP network IP address and port, devices and servers that are not located within that private IP network will not be able to reach the loT device using the Thing Description associated with that device. This is because the IP address and port number pair in the Thing Description are the local IP address and port in the private IP network, and consequently are not accessible from an IP-address space outside of that private network, for example on the public Internet. This inaccessibility will prevent agents, including application and management servers, from initiating connections with the loT device in order to perform Actions, read Property values etc.

A NAT binding may exist between the local, private, IP address and port of the device and a public IP address and port assigned to the device by the NAT and via which an agent in the public IP network may communicate with the device behind the NAT. However, when IP addresses are used in URIs of resources on the device, this binding would lead to the device and the agent having different URIs for the same resource, as the device would use its local, private, IP address and port in the URI whereas the agent in the public network would use the public address and port assigned by the NAT in the URI of the resource. The device and agent would thus assume that the URIs refer to two different resources.

DNS could be used to provide indirection from a host name of an loT device. However, this would assume that the DNS server has been updated with the public IP address assigned by the NAT to the loT device. In addition, if an loT device can be reached using multiple public IP addresses, an application has very little control over which of the resolved IP addresses a network protocol stack is using. In some cases, an application may not be able to retrieve the address, for example if it needs to inform a peer about the address using a signaling protocol. In addition, DNS returns only an IP address, and assumes that a protocol will use a default port that has been assigned to that protocol, for example 8080 in the case of HTTP. However, a NAT might assign different port numbers to its NAT bindings, meaning the default port number for a transport protocol, assumed by DNS, may not be correct. Finally, the use of DNS would impact the HTTP stack, and if a DNS query were to return multiple IP address options an application would have little or no control over which address option should be used.

Summary

It is an aim of the present disclosure to provide nodes, a device, methods and a computer readable medium which at least partially address one or more of the challenges discussed above.

According to a first aspect of the present disclosure, there is provided a storage node for managing transport addresses associated with a computing device. The storage node comprises processing circuitry configured to receive, from a fetching node, a request for candidate transport addresses associated with a target computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol, and wherein the request includes an identification of the target computing device. The processing circuitry is further configured to retrieve from a memory at least one candidate transport address that is associated in the memory with the received identification of the target computing device, and send the retrieved candidate transport address to the fetching node.

According to another aspect of the present disclosure, there is provided a fetching node for managing addresses associated with a computing device. The fetching node comprises processing circuitry configured to receive, from an invoking node, a request for candidate transport addresses associated with a target computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. The processing circuitry is further configured to send, to a storage node, a request for candidate transport addresses associated with the target device, the request including an identification of the target computing device, receive, from the storage node, at least one candidate transport address associated with the target device, and send the received at least one candidate transport address to the invoking node. According to another aspect of the present disclosure, there is provided an invoking node for contacting a computing device. The invoking node comprises processing circuitry configured to obtain an identification of a target computing device and send, to a fetching node, a request for candidate transport addresses associated with the target device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol, and wherein the request includes the obtained identification of the target computing device. The processing circuitry is further configured to receive, from the fetching node, at least one candidate transport address associated with the target computing device, and send a message to the target computing device using the at least one candidate transport address.

According to another aspect of the present disclosure, there is provided a generating node for managing addresses associated with a computing device. The generating node comprises processing circuitry configured to generate a description of the computing device wherein the description comprises a URI of a resource hosted on the computing device, wherein the authority component of the URI comprises a placeholder identifier of the computing device, and wherein the URI specifies a scheme that supports candidate transport addresses, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol.

According to another aspect of the present disclosure, there is provided a computing device for managing addresses associated with a computing device. The computing device comprises processing circuitry configured to obtain candidate transport addresses for the computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. The processing circuitry is further configured to send the candidate transport addresses to a storage node. According to another aspect of the present disclosure, there is provided a management node for managing addresses associated with a computing device, wherein the management node has management responsibility for the computing device. The management node comprises processing circuitry configured to obtain candidate transport addresses for the computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. The processing circuitry is further configured to send the candidate transport addresses to a storage node.

According to further aspects of the present disclosure, there are provided methods, a computer program, carrier and computer program product as set out in the appended claims.

Brief Description of the Drawings

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:

Figure 1 illustrates a functional architecture which may implement examples of the present disclosure;

Figure 2 is a message flow diagram illustrating example methods of the present disclosure;

Figure 3 is flow chart illustrating process steps in a method performed by a storage node;

Figure 4 is flow chart illustrating process steps in another example of method performed by a storage node;

Figure 5 is flow chart illustrating process steps in a method performed by a fetching node;

Figure 6 is flow chart illustrating process steps in another example of method performed by a fetching node;

Figure 7 is flow chart illustrating process steps in a method performed by an invoking node;

Figures 8a and 8b are flow charts illustrating process steps in another example of method performed by an invoking node; Figure 9 is flow chart illustrating process steps in a method performed by a generating node; Figure 10 is flow chart illustrating process steps in a method performed by a computing device;

Figure 11 is flow chart illustrating process steps in a method performed by a management node;

Figure 12 is a block diagram illustrating functional units in a storage node;

Figure 13 is a block diagram illustrating functional units in another example of storage node;

Figure 14 is a block diagram illustrating functional units in a fetching node;

Figure 15 is a block diagram illustrating functional units in another example of fetching node;

Figure 16 is a block diagram illustrating functional units in an invoking node;

Figure 17 is a block diagram illustrating functional units in another example of invoking node;

Figure 18 is a block diagram illustrating functional units in a generating node;

Figure 19 is a block diagram illustrating functional units in another example of generating node;

Figure 20 is a block diagram illustrating functional units in a computing device;

Figure 21 is a block diagram illustrating functional units in another example of computing device;

Figure 22 is a block diagram illustrating functional units in a management node; and Figure 23 is a block diagram illustrating functional units in another example of management node. Detailed Description

Aspects of the present disclosure provide nodes, and methods performed by such nodes, which enable the management of transport addresses associated with a computing device. The device may be an loT device and may in some examples be subject to constraints on any one or more of size, weight, power, memory, and processing resources. According to examples of the present disclosure, candidate transport addresses associated with a target computing device may be stored by a storage node, with an identification of the computing device being associated in the storage of the storage node with the corresponding candidate transport addresses. The candidate transport addresses for the target computing device may be requested from the storage node by a fetching node, and provided by the fetching node to an invoking node that seeks to contact one or more resources on the target device.

Examples of the present disclosure may be implemented using a URI scheme that supports candidate transport addresses. According to such implementation, the identification of the target computing device may comprise a placeholder identifier of the target computing device, wherein a placeholder identifier of a computing device comprises the authority component of a URI of a resource hosted on the computing device. The placeholder identifier comprises a set of characters serving as an identifier of a part of the URI that is replaced with information obtained from a candidate transport address. The URI may further be used in a Thing Description of the computing device that can give additional information on how the URI can be used.

In one example of the present disclosure, a new URI scheme is proposed. The new URI scheme provides indirection from the host name/I P address and port of a device, where indirection has its standard meaning in computer networking of enabling referring to a value using a name, reference, or container instead of the value itself. In the present example, the URI scheme indicates that the authority part of the URI can be replaced with one or more candidates transport addresses, referred to below as “candidates”. The proposed new URI scheme is referred to as “Web of Things Interactive Connectivity Establishment”, with the scheme name “WICE”. An example resource URI using the new scheme is presented below: wice://example-device-42/5/0/1

In the example URI, the authority part “example-device-42” is a placeholder identifier, which may be replaced with candidate transport addresses for the device. Operation of the WICE URI scheme may be facilitated by the introduction of a new “property” type device capability. This new property identifies a storage node from which candidates may be obtained for a given target device. This new property, which may be included in a “Thing Description” for the device is referred to in the present disclosure as a “wice service”.

As discussed above, the URI of the wice service property points to a storage node, which may be a physical or virtual network server. The storage node is assumed to be located in a public IP network, so that it can be reached by other devices. A node, service or function that is seeking to obtain candidates for a device, referred to in the present disclosure as a fetching node, may obtain the URI of an appropriate storage node for the device from the “wice service” property in the Thing Description of the device. The fetching node may then use that URI to request a list of candidates associated with the device, and may provide those candidates to a node, service or function seeking to contact a resource on the device.

A candidate transport address, or candidate, for a device comprises an IP address and an indication of a port number and a transport protocol that may be used to contact the device. In some examples, one or more of the port number or transport protocol may be implicitly indicated in the candidate as opposed to explicitly stated. For example, if a transport protocol is explicitly stated but not a port number, then it may be assumed that the default port number for the stated transport protocol is implicitly indicated. Alternatively, if a port number is explicitly stated but not a transport protocol and if the port number is the default port number for a transport protocol, then that transport protocol may be considered to be implicitly indicated. In still further examples, specific URI schemes may be envisaged for individual protocols, each scheme being specific to a particular transport protocol, as discussed in further detail below. A range of different candidate types may be envisaged, corresponding to different addressing options and deployment configurations of a device. For example, one candidate type may correspond to a local network interface through which the device is operable to communicate, while another may correspond to a translated, public IP address and port allocated to the device by a NAT. Still another candidate type may correspond to a public IP address and port allocated to the device by a relay node, wherein the relay node is configured to receive and forward traffic to and from the device.

Candidates may be encoded for communication and storage using a range of different mechanisms, including for example JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR) or any other encoding mechanism that is supported by both the node, service or function seeking to invoke a resource on the device and the candidate storage server.

Once the candidates have been fetched for a particular device, the IP address, port number and indicated transport protocol indicated by the one or more candidates can replace the authority part of a wice URI for resources on the device. The node, service or function seeking to contact a resource on the device can then use the updated URIs to try to reach the resources using any appropriate procedure. If there are multiple candidates for a device, for example owing to a device having a local, NAT assigned and relay assigned candidate, this can result in multiple URIs for the same resource. The invoking node may decide in which order it will use the different URIs in order to try to reach a given resource on the device.

An overview of node and device behavior according to different examples of the present disclosure is provided below, together with discussion of details which may be incorporated in different implementations of these examples, and an example message sequence. There then follows a discussion of example methods according to the present disclosure, which methods may be implemented by processing circuitry in a storage node, fetching node, invoking node, generating node, computing device and management node.

Figure 1 illustrates a functional architecture which may implement examples of the present disclosure. As illustrated in Figure 1 , a computing device 102, which may be an loT device, is deployed in a private IP network 120 and has a private IP address 112. The computing device 102 is deployed behind a NAT 116 which has established a NAT binding between the private IP address 112 of the computing device 102 and a public IP address 114 that the NAT 116 has assigned to the computing device 102. Within a public IP network 122 are deployed a storage node 104, an invoking node 106, a fetching node 108 and a Thing Description generating node 110. Each of these nodes are functional entities, and may be deployed on one or more physical or virtual nodes. It will be appreciated that one or more of the invoking node 106, fetching node 108 and Thing Description generating node 110 may be co-located with any one or more of these functions or with another function. For example the invoking node 106 and fetching node 108 may be functions running on the same physical or virtual node. In such an example, an application server may comprise both invoking and candidate fetching functionality. In another example, the storage node 104 may be implemented in or controlled by a management node such as a LwM2M management server. In a still further example, the Thing Description generating node 110 may also be implemented within a management node, and may be configured to generate a Thing Description for a device when the device is deployed, as discussed in further detail below.

A range of different mechanisms may be used to collect candidates associated with an loT or other device and provide those candidates to the storage node, which may for example comprise a candidate storage server. The present disclosure does not mandate a specific solution for how candidates should be collected, where the storage node should be located or how the candidates should be provided to the storage node. In some examples, if the loT device communicates with a management server such as a LwM2M management server, that server may check the public IP address and port from which the loT device sends traffic towards the server, and may create candidates based on this information. In such examples, the loT device may take no active part in the collection of candidates, with this action being taken exclusively by the management server on the basis of existing communication with the device. However, the loT device might have to ensure that it sends data, or at least a keep-alive or similar message, with sufficient frequency in order to maintain a NAT binding between itself and the server. If the NAT binding times out, it may no longer be possible to use the IP address and port associated with the candidate to reach the loT device.

In another example, the loT device may collect its candidates, for example using a procedure similar to that employed in the Interactive Connectivity Establishment (ICE) mechanism for establishing communication sessions between peers, as disclosed in IETF RFC 8445. According to ICE, each device, or endpoint, seeking to establish a peer-to-peer connection with another endpoint collects its own candidates and exchanges its collected candidates with the other endpoint. After candidate exchange, the endpoints trial the candidates of the remote endpoint to try to establish peer-to-peer connectivity. Candidate collection by an loT device according to example of the present disclosure may thus be performed according to candidate collection methods used for ICE, and the candidates collected by the device and provided to the storage node according to examples of the present disclosure may also be used in connection with the ICE mechanism for peer-to-peer connectivity establishment.

Figure 2 is a message flow diagram illustrating one example of how an loT computing device 202 (which may be an example of an loT computing device 102 illustrated in Figure 1 ) may collect one or more candidates and provide them to a suitable storage node 204, and how a fetching/invoking node 206 may request, using one or more WICE- URI(s) from a Thing Description associated with the loT computing device 202, candidates associated with the loT Device. The fetching/ invoking node may then use the candidates when it tries to establish a connection with the loT computing device 202.

Referring to Figure 2, in a first step 1 , the loT computing device 202 collects its candidates, for example using one or more of the procedures set out in section 2.1 “Gathering Candidates” of IETF RFC 8445. In step 2, the loT computing device 202 provides its candidates to a suitable storage node. The URI of a suitable storage node may be configured in the loT computing device at manufacture or deployment, together with a placeholder identifier of the computing device. The placeholder identifier comprises a set of characters serving as an identifier of a part of the URI that is replaced with information obtained from a candidate transport address. The storage node 204 stores the candidates for the computing device in step 3 and associates the candidates with an identifier of the computing device in its memory. The identifier may be the placeholder identifier of the device, comprising the authority part of a wice URI for resources on the device, as discussed in further detail below. The placeholder identifier of the device may be specified in a Thing Description of the device which is accessible to the storage node, in addition to being configured in the loT computing device.

The invoking node 206, which is illustrated in Figure 2 as co-located with the fetching node 206, seeks to access a resource on the computing device 102. The invoking node requests the fetching node 206 to obtain candidates for the computing device. In step 4, the fetching node 206 retrieves the Thing Description of the computing device, which includes within it the placeholder identifier of the computing device and the URI of the appropriate storage node, listed as the property “wice server” as discussed above and explained in further detail below. The fetching node 206 then sends a request to the storage node in step 5, using the obtained URI, requesting candidates for the computing device 202. The storage node 204 returns the requested candidates in step 6. The fetching node 206 provides the returned candidates to the invoking node 206, and the invoking node 206 may then seek to access one or more resources on the computing device 102 using the returned candidates. As the function seeking to connect to the device, the invoking node may determine in which order candidates are used, in the event that more than one candidate is returned by the storage node 204.

An example Thing Description for an loT computing device, such as the computing device 102, is illustrated below. The example loT computing device is a lamp and is located behind a NAT, in a private IP network, as illustrated in the example architecture of Figure 1. The example Thing Description includes three capabilities: one property, one action and one event. Each capability represents a web resource, with an associated URI. The authority part of a URI may include user information as well as a host and optional port number. In the illustrated example, the scheme of the resource URIs is "https", and the authority part of the resource URIs contains the IP address of the lamp. As no specific port number is indicated, it may be assumed that the default port number for the HTTP over TLS (HTTPS) transfer protocol may be used. As mentioned above, the lamp loT computing device is located behind a NAT, in a private network. The lamp has therefore been assigned an IP address from a private address space and cannot be reached from another network. In the illustrated example, the IP address is an IPv4 address, although it will be appreciated that the address may alternatively be an IPv6 address.

{

"id": "urn:dev:wot:com:example:servient:lamp ",

"name": "MyLampThing",

"security": [{"scheme": "basic"}],

"properties": {

"status": {

"type": "string",

"forms": [{"href": "https://10.10.10.10/status"}]

}

},

"actions": {

"toggle": {

"forms": [{"href": "https://10.10.10.10/toggle"}]

} },

"events": {

"overheating": {

"type": "string",

"forms ": [{

"href": "https://10.10.10.10/oh",

"subProtocol ": "LongPoll "

}]

}

}

In the above example, 10.10.10.10 is the private IPv4 address assigned to the lamp. The example below illustrates how the Thing Description may be modified when using example methods according to the present disclosure, implemented using the new wice URI scheme. In the modified example, the scheme of each resource URI has been replaced with the wice scheme. In addition, the authority part of the resource URIs, including the private IP address of the lamp device has been replaced with a placeholder identifier. This placeholder identifier may be replaced with a candidate for the device. A “wice-service” property has also been added to the Thing Description. The “wice-service” property contains the address of a storage node where candidates for the lamp are stored. The storage node is located in a public IP network, and is reachable by a fetching node that will contact the server in order to fetch candidates associated with the lamp loT computing device.

{

"id": "urn:dev:wot:com:example:servient:lamp ", "name": "MyLampThing", "security": [{"scheme": "basic"}],

"properties": {

"status": {

"type": "string",

"forms": [{"href": "wice://example-device- 42/status "}]

},

"wice-service": {

"type": "string",

"forms": [{"href": "http://192.10.10.5 "/J },

},

"actions": {

"toggle": {

"forms": [{"href": "wice://e ample-device- 42/toggle"}]

} },

"events": {

"overheating": {

"type": "string", "forms ": [{

"href": "vice://example-device-42/oh ",

"subProtocol ": "LongPoll "

}]

} }

}

The fetching node will obtain the URI of the storage node from the Thing Description of the device and contact the storage node, using the IP address (and port if included) in the “wice-service” property, and request candidates associated with the lamp loT computing device.

The protocol used between the fetching node and the storage node, and the associated protocol procedures, may be established according to the needs of particular implementations. The fetching node should provide enough information for the storage node to identity the loT computing device for which candidates are requested. The fetching node may provide the placeholder identifier that forms the authority part of the wice URIs of the resources ("example-device-42" in the above example). In addition, the fetching node may indicate which transfer protocols (HTTP, CoAP etc.) can be used by the invoking node to communicate with the loT computing device, so that the storage node only returns candidates that can be used for those transfer protocols (while different transfer protocols may share the same IP address, they may use different ports).

As the original scheme of each resource has been replaced by a “wice” scheme, the fetching node may be required to find out what transfer protocol the invoking node and the loT computing device support in order to provide this information to the storage node. Either the fetching node may obtain this information by means of configuration, or the information may be available in the Thing Description. In many scenarios a single transfer protocol will always be used. One mechanism for making this information available in the Thing Description is, as discussed above, to have specific URI schemes for different transfer protocols. For example the “wice” scheme could be combined with the original transfer scheme of a device, e.g., “wice-http”. Another mechanism is to add the original transfer protocol as a separate information model in the Thing Description. Continuing the present example, if the storage node has one or more candidates associated with the lamp loT computing device, it will return them to the fetching node. The fetching node will then provide the candidates to the invoking node. The fetching node may simply forward the candidates to the invoking node, for example as a list, or may update the URIs of resources on the device with the one or more candidates, as well as replacing the wice scheme name in the URIs with the original scheme name, before sending the updated URIs to the invoking node.

The example below shows the Thing Description for the lamp loT computing device with the authority part of the resource URIs replaced with a candidate (for example the public address and port number assigned by the NAT) and the scheme part replaced with the relevant URI scheme (HTTP in this case). It will be appreciated that in practice, it is not envisaged that the Thing Description itself will be updated, either by the fetching node or the invoking node, and so the updated Thing Description shown below is merely for the purposes of illustration. The Thing Description for a computing device is typically intended to be a static data object that continues to be relevant for a computing device throughout its working life. In contrast, a public IP address assigned by a NAT or a relay node such as a TURN (Traversal Using Relays around NAT) server may change over the lifetime of a computing device. For example a NAT binding for a computing device may expire and be reestablished, with a different IP address and/or port being assigned by the NAT to the computing device. The updated Thing Description below is therefore merely a demonstration of how resource URIs for a computing device may be updated to include a candidate for the device. In practice a fetching node or invoking node will merely update the resource URIs for a computing device within its internal processing and memory, and will store the updated URI version that results in successful contact with a resource.

Referring to the example updated Thing Description below, it can be seen that the scheme of the resource URIs have been updated from wice to https, and the placeholder identifier “example-device-42” has been replaced with an a public IPv4 address and port number assigned by the NAT. The port number is explicitly stated as it is not the default port number for a transport protocol.

{

"id": "urn:dev:wot:com:example:servient:lamp ",

"name": "MyLampThing",

"security": [{"scheme": "basic"}], "properties": {

"status": {

"type": "string",

"forms": [{"href": "https://198 . 20 . 20 . 1 : 9432/status "}] }

},

"actions": {

"toggle": {

"forms": [{"href": "https: //198 . 20 . 20 . 1 : 9432/toggle "}] }

},

"events": {

"overheating": {

"type": "string", "forms": [{

"href": "https:// 198 .20 . 20 . 1 : 9432/oh",

"subProtocol ": "LongPoll "

}]

} }

}

Once the invoking node obtains the candidates from the fetching node, either as updated URIs or as a list, the invoking node can try to access the resources on the device using the candidates, either using the updated URIs provided by the fetching node or first obtaining updated URIs by performing the above described substitutions using the provided list of candidates.

It will be appreciated that the storage node may return multiple candidates, each associated with a different IP address and port, for example if the computing device is deployed with multiple interfaces, NATs, and/or relay nodes. One or both of the fetching node and/or invoking node may prioritize the candidates based on local policy. Metadata associated with a candidate, including for example information on how the candidate has been created, may be stored in the storage node and provided to the fetching node with the candidates, and so may be used as input for such prioritization. Examples of metadata include candidate type ("host", "relayed", "server reflexive" (i.e., address given by a NAT), etc.) and priority value given by the device to control order of connection attempts. It will be appreciated that examples of the above described behaviors may be realised through the performance of cooperating methods on one or more of a computing device, a storage node, a fetching node, an invoking node, a management node, and a generating node. Figures 3 to 11 are flow charts illustrating methods 300 to 1100 that may be conducted at such nodes according to examples of the present disclosure.

Figure 3 is flow chart illustrating process steps in a method 300 for managing transport addresses associated with a computing device. The method 300 is performed by a storage node, which may be a physical node or a virtual node running in a cloud, edge cloud or fog deployment. As discussed above, the storage node may be implemented in or managed by a management node, such as a LwM2M management server for example. Referring to Figure 3, the method 300 comprises, in a first step 310, receiving, from a fetching node, a request for candidate transport addresses associated with a target computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol, and wherein the request includes an identification of the target computing device. The method further comprises, in step 320, retrieving from a memory at least one candidate transport address that is associated in the memory with the received identification of the target computing device, and, in step 330, sending the retrieved candidate transport address to the fetching node.

As discussed above, the port number and identification of a transport protocol of a candidate transport address may be explicitly included in the candidate transport address or may be implicit. For example, either of the port number or transport protocol may be implicit on the basis of the other of the port number or transport protocol. In other examples, the port number may not be a default port number for a transport protocol and so the port number and/or transport protocol may be explicitly including in the candidate transport address. A candidate transport address may also be referred to as a candidate in the present disclosure.

According to examples of the present disclosure, the computing device 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.

Figure 4 is a flow chart illustrating process steps in a further example of method 400 for managing addresses associated with a computing device. The method 400, as for the method 300, is performed by a storage node, which may be a physical ora virtual storage node as discussed above with reference to Figure 3. The steps of the method 400 illustrate one example way in which the steps of the method 300 may be implemented and supplemented in order to achieve the above discussed and additional functionality.

Referring to Figure 4, according to the method 400, in a first step 402, the storage node receives an identification of a computing device and at least one candidate transport address associated with the identified computing device. As illustrated at 402a, the candidate transport address and identification may be received from at least one of the identified computing device and/or a management node having management responsibility for the computing device. In the case of a constrained device, the device may be running a LwM2M client, and the management node may comprise a LwM2M server.

In step 404, the storage node stores the received identification and candidate transport address in a memory, such that the identification is associated with the candidate transport address in the memory. The identification may be associated with the candidate transport address or addresses via a mapping and/or any suitable storage format such as a database format. In step 406, the storage node received one or more updated candidate transport addresses associated with the identified computing device, and in step 408, the storage node updates its memory to include the updated candidate transport addresses. Updates to candidate transport addresses may for example occur in the case of a NAT binding that expires and is re-established by the NAT, deployment of a new or additional NAT or relay node etc.

In step 410, the storage node receives, from a fetching node, a request for candidate transport addresses associated with a target computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol, and wherein the request includes an identification of the target computing device. As illustrated at step 410, the request may additionally include an identification of a transport protocol with which both an invoking node and the target computing device are compatible.

The identification of a target computing device included in the request may comprise a placeholder identifier of the target computing device, wherein a placeholder identifier of a computing device comprises the authority component of a URI of a resource hosted on the computing device that is specified in a description of the computing device; and wherein the URI of the resource specifies a scheme that supports candidate transport addresses. The placeholder identifier comprises a set of characters serving as an identifier of a part of the URI that is replaced with information obtained from a candidate transport address. The description of the device may comprise a specification of functionality of the device, which specification may conform to a data structure, and may comprise a Thing Description, as discussed earlier in the present disclosure. The data structure may for example be a Web of Things (WoT) Thing Description (TD), an IPSO Smart Object, etc. It will be appreciated that when receiving candidate transport addresses in step 402, the device identifier received with such candidate transport addresses may be a placeholder identifier as discussed herein. It will further be appreciated that the wice URI scheme discussed above is an example of a URI scheme that supports candidate transport addresses.

As illustrated at 410a and as discussed above, the IP address of a candidate transport address may comprise at least one of an IP address of a network interface through which the device is operable to communicate, a public IP address allocated to the device by a NAT and/ora public IP address allocated to the device by a relay node, wherein the relay node is configured to receive and forward traffic to and from the device. An example of a relay node may include a TURN server (Traversal Using Relays around NAT).

Referring still to Figure 4, in step 420, the storage node retrieves from a memory at least one candidate transport address that is associated in the memory with the identification of the target computing device received from the fetching node. In step 430, the storage node sends the retrieved candidate transport address or addresses to the fetching node. In the illustrated example, the storage node sends only those candidate transport addresses that are compatible with the identified transport protocol from the request for candidate transport addresses received in step 410.

It will be appreciated that the methods 300, 400 may be complimented by methods as discussed below performed in other nodes, so as to cooperate to achieve examples of the functionality described herein.

Figure 5 is a flow chart illustrating process steps in a method 500 for managing addresses associated with a computing device. The method is performed by a fetching node, which may be a physical node or a virtual node running in a cloud, edge cloud or fog deployment. In some examples, the fetching node could be co-located with an invoking node, such that the fetching node and invoking node comprise communicating functional or logical entities within the same physical or virtual node. As discussed above, the computing device with which the candidate transport addresses are associated may be a constrained device.

Referring to Figure 5, in a first step 510, the method 500 comprises receiving, from an invoking node, a request for candidate transport addresses associated with a target computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. In step 520, the method 500 comprises sending, to a storage node, a request for candidate transport addresses associated with the target device, the request including an identification of the target computing device. The method 500 further comprises, at step 530, receiving, from the storage node, at least one candidate transport address associated with the target device, and, at step 540, sending the received at least one candidate transport address to the invoking node. Figure 6 is a flow chart illustrating process steps in a further example of method 600 for managing addresses associated with a computing device. The method 600, as for the method 500, is performed by a fetching node, which may be a physical or a virtual fetching node and may be co-located with other nodes, as discussed above with reference to Figure 5. The steps of the method 600 illustrate one example way in which the steps of the method 500 may be implemented and supplemented in order to achieve the above discussed and additional functionality.

Referring to Figure 6, according to the method 600, in a first step 610, the fetching node receives, from an invoking node, a request for candidate transport addresses associated with a target computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. As illustrated at 610, the received request for candidate transport addresses associated with a target device may identify the target device using a placeholder identifier, wherein a placeholder identifier of a computing device comprises the authority component of a URI of a resource hosted on the computing device that is specified in a description of the device; and wherein the URI of the resource specifies a scheme that supports candidate transport addresses. The placeholder identifier comprises a set of characters serving as an identifier of a part of the URI that is replaced with information obtained from a candidate transport address. As discussed above, the wice scheme disclosed herein is an example of a scheme that supports candidate transport addresses.

As illustrated at 610a, the IP address of a candidate transport address may comprise at least one of an IP address of a network interface through which the device is operable to communicate, a public IP address allocated to the device by a NAT and/or a public IP address allocated to the device by a relay node, wherein the relay node is configured to receive and forward traffic to and from the device.

In step 612, the fetching node obtains an identification of a storage node for the target computing device from a description of the target computing device, the identification including a URI of the storage node. As discussed above, the description of the device may comprise a specification of functionality of the device, which specification conforms to a data structure. The data structure may for example be a Web of Things (WoT) Thing Description (TD), an IPSO Smart Object, etc. In step 614, the fetching node obtains an identification of at least one transport protocol supported by the invoking node and the target device. Options for obtaining this identification of a supported transport protocol may include reading this from the description of the device, either via a combined scheme name (e.g. wice-http) or from a dedicated entry in the device description.

In step 620, the fetching node sends, to the storage node whose identification was obtained and using the obtained URI of the storage function, a request for candidate transport addresses associated with the target device. The request includes an identification of the target computing device and may include the obtained identification of a transport protocol with the request for candidate transport addresses sent to the storage node. The identification of the target device may include a placeholder identification of the target device as discussed above.

In step 630, the fetching node receives, from the storage node, at least one candidate transport address associated with the target device, and in step 640, the fetching node sends the received at least one candidate transport address to the invoking node. As illustrated in step 640a, in one example, sending the candidate transport address or addresses may comprise sending a list comprising the candidate transport address or addresses to the invoking node. As illustrated in step 640b, in another example, sending the candidate transport address or addresses may comprise obtaining, from a description of the target device, URIs of resources hosted at the target device, updating the obtained URIs by replacing the authority component of the obtained URIs with at least one of the received candidate transport addresses, and sending the updated URIs to the invoking node.

Figure 7 is a flow chart illustrating process steps in a method 700 for contacting a computing device. The method is performed by an invoking node which may be a physical node or a virtual node running in a cloud, edge cloud or fog deployment. In some examples, the invoking node may be co-located in the same physical or virtual node as another of the nodes described herein, such as a fetching node. In such examples, the fetching node and invoking node may comprise communicating functional or logical entities within the same physical or virtual node. Such a node may for example comprise an application server. In some examples of the present disclosure, the method 700 may be performed by functionality within the invoking node that is running in the Application layer or the Internet layer of the Internet Protocol Suite. As such, the method 700 may be implemented in software and/or in middleware. As discussed above, the computing device may be a constrained device.

Referring to Figure 7, the method 700 comprises, in a first step 710, obtaining an identification of a target computing device and, in step 720, sending, to a fetching node, a request for candidate transport addresses associated with the target device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol, and wherein the request includes the obtained identification of the target computing device. In step 730, the method 700 comprises receiving, from the fetching node, at least one candidate transport address associated with the target computing device. In step 740, the method 700 comprises sending a message to the target computing device using the at least one candidate transport address.

Figures 8a and 8b are a flow charts illustrating process steps in a further example of method 800 for contacting a computing device. The method 800, as for the method 700, is performed by an invoking node, which may be a physical or a virtual invoking node, and may be co-located with another node, as discussed above with reference to Figure 7. The steps of the method 800 illustrate one example way in which the steps of the method 700 may be implemented and supplemented in order to achieve the above discussed and additional functionality.

Referring initially to Figure 8a, according to the method 800, in a first step 810, the invoking function obtains an identification of a target computing device. The identification may comprise a placeholder identifier as discussed above. As illustrated in step 810a, obtaining the identification of the target device may comprise obtaining, from a description of the target device, a URI of at least one resource hosted on the device, wherein the URI includes, as authority component, the placeholder identifier of the device, and wherein the URI of the resource specifies a scheme that supports candidate transport addresses. As discussed above, the description of the device may comprise a specification of functionality of the device, which specification conforms to a data structure. The data structure may for example be a Web of Things (WoT) Thing Description (TD), an IPSO Smart Object, etc. The wice scheme disclosed herein is an example of a scheme that supports candidate transport addresses. In step 810, the invoking node sends, to a fetching node, a request for candidate transport addresses associated with the target device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol, and wherein the request includes the obtained identification of the target computing device. As illustrated at 820a and as discussed above, the IP address of a candidate transport address may comprise at least one of an IP address of a network interface through which the device is operable to communicate, a public IP address allocated to the device by a NAT and/or a public IP address allocated to the device by a relay node, wherein the relay node is configured to receive and forward traffic to and from the device.

In step 830, the invoking node receives, from the fetching node, at least one candidate transport address associated with the target computing device. This may comprise receiving from the fetching node a list comprising the at least one candidate transport addresses, as illustrated at 830a, or receiving from the fetching node updated URIs of resources hosted on the target computing device, the updated URIs including at least one candidate transport address as the authority component of the URIs, as illustrated at 830b.

In step 832, the invoking node determines an order in which the at least one candidate transport addresses are to be used, and, in step 840, the invoking node sends a message to the target computing device using the at least one candidate transport address. The message may be addressed to one of the resources hosted on the device. The nature of the message may depend on the nature of the resource.

Steps that may be involved in sending a message to the target computing device are illustrated in Figure 8b. The steps of Figure 8b assume that the invoking node has received the candidate transport addresses from the fetching node as a list. It will be appreciated that the steps of Figure 8b may be modified in the event that the candidate transport addresses are received as updated URIs.

Referring to Figure 8b, the invoking node may initially select a next candidate transport address to be used in accordance with the determined order at step 840a. In 840b, the invoking node obtains, from a description of the target device, a URI of a resource hosted at the target device. The invoking node then updates the obtained URI by replacing the authority component of the obtained URI with the selected candidate transport address in step 840c. In step 840d, the invoking node sends a message to the updated URI. The message can be, for example, a request message for request/response protocols (e.g., HTTP or CoAP), a publication for pub/sub protocols (e.g., MQTT), or a remote procedure call (RPC) for RPC protocols (e.g., XML-RPC). In step 840e, the invoking node determines whether the message sent to the updated URI was received, and, if the message was received, the invoking node stores the updated URI as the correct URI for the resource at step 840f. If the message sent to the updated URI was not received, the invoking node returns to step 840a and selects a next candidate transport address to be used in accordance with the determined order, updating the resource URI by replacing the authority component of the resource URI with the newly selected candidate transport address, and sends a message to the updated URI.

In some examples, an invoking node may in fact comprise a proxy node that is acting on behalf of an original invoker of the computing device. In such examples, the original invoker may be unaware of candidate transport addresses, and may simply send a request to a URI including a placeholder identifier, such as a wice-URI, to a proxy. For example, an original invoker may use a wice URI in HTTP requests to an HTTP proxy. The proxy then performs the steps of the method 700 or 800, acting as a “proxy invoking node”. The proxy invoking node thus obtains the identification of the target computing device in step 710 or 810 from the request received from the original invoker. The proxy invoking node then completes steps 720 to 740, or 820 to 840, substantially as set out above, requesting and receiving candidate transport addresses from a fetching node, determining an order in which to use the received candidate transport addresses and sending the request received from the original invoker using a received candidate transport address. On receiving a response to the request from the computing device, and thus establishing a candidate transport address that may be used successfully to contact the computing device, the proxy invoking node then forwards the received response to the original invoker.

Figure 9 is a flow chart illustrating process steps in a method 900 for managing addresses associated with a computing device. The method 900 is performed by a generating node, which may be a physical node or a virtual node running in a cloud, edge cloud or fog deployment, and may be co-located with one or more other nodes. The device with which the candidate transport addresses are associated may be a constrained device as discussed above. Referring to Figure 9, in a first step 910, the method 900 comprises generating a description of the computing device, the description including a URI of a resource hosted on the computing device. The description may also include a URI of a storage node operable to store candidate transport addresses for the computing device. As illustrated at 910a and 910b, the authority component of the URI comprises a placeholder identifier of the computing device and the URI specifies a scheme that supports candidate transport addresses, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. The placeholder identifier comprises a set of characters serving as an identifier of a part of the URI that is replaced with information obtained from a candidate transport address.

The description of the device may comprise a Thing Description as disclosed herein and discussed in detail above. That is, the description of the device may comprise a specification of functionality of the device, which specification conforms to a data structure. The data structure may for example be a Web of Things (WoT) Thing Description (TD), an IPSO Smart Object, etc. The wice scheme disclosed herein is an example of a scheme that supports candidate transport addresses, and the property “wice service” is an example of a capability that may be used to identify a storage node for the candidate transport addresses for the device. As discussed above, the I P address of a candidate transport address may comprise at least one of an IP address of a network interface through which the device is operable to communicate, a public IP address allocated to the device by a NAT, and/or a public IP address allocated to the device by a relay node, wherein the relay node is configured to receive and forward traffic to and from the device.

Figure 10 is a flow chart illustrating process steps in a method 1000 for managing addresses associated with a computing device. The method 1000 is performed by device, which may be a constrained device as discussed above.

Referring to Figure 10, in a first step 1010, the method 1000 comprises obtaining candidate transport addresses for the computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. The method further comprises, in step 1020, sending the candidate transport addresses to a storage node. The device may be configured with a URI of the storage node to which it should send candidate transport addresses. In some examples, the method may further comprise, in step 1030, sending at least one keep-alive message to maintain a NAT binding for the computing device. The keep-alive message may be any heartbeat type message intended to maintain a connection. In some examples, a NAT binding may be sufficiently long to perform its required function without a keep-alive message, and so the sending of a keep-alive message may be omitted. As illustrated at 1010a, the an IP address of a candidate transport address may comprise at least one of an IP address of a network interface through which the device is operable to communicate, a public IP address allocated to the device by a NAT and/or a public IP address allocated to the device by a relay node, wherein the relay node is configured to receive and forward traffic to and from the device. An example of a relay node may include a TURN server.

Figure 11 is a flow chart illustrating process steps in a method 1100 for managing addresses associated with a computing device. The method 1100 is performed by a management node having management responsibility for the computing device, which management node may be a physical node or a virtual node running in a cloud, edge cloud or fog deployment, and may be co-located with one or more other nodes. The management node may for example comprise a LwM2M management server. The device with which the candidate transport addresses are associated may be a constrained device as discussed above.

Referring to Figure 11, the method 1100 comprises, in step 1110 obtaining candidate transport addresses for the computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. The method further comprises, in step 1120, sending the candidate transport addresses to a storage node. The management node may obtain a URI of the storage node to which it should send candidate transport addresses from a description of the device. As illustrated at 1110a, the IP address of a candidate transport address may comprise at least one of an IP address of a network interface through which the device is operable to communicate, a public IP address allocated to the device by a NAT and/or a public IP address allocated to the device by a relay node, wherein the relay node is configured to receive and forward traffic to and from the device.

Together, the methods described above may enable an invoking node to obtain candidate transport addresses for a device and use the candidate transport addresses to access a resource hosted on the device. As discussed above, the methods 300 to 1100 are performed by a storage node, a fetching node, an invoking node, a generating node, and computing device and a management node respectively. The present disclosure provides a storage node, a fetching node, an invoking node, a generating node, and computing device and a management node which are adapted to perform any or all of the steps of the above discussed methods.

Figure 12 is a block diagram illustrating a storage node 1200 which may implement the method 300 and/or 400 according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 1250. Referring to Figure 12, the storage node 1200 comprises a processor or processing circuitry 1202, and may comprise a memory 1204 and interfaces 1206. The processing circuitry 1202 is operable to perform some or all of the steps of the method 300 and/or 400 as discussed above with reference to Figures 3 and 4. The memory 1204 may contain instructions executable by the processing circuitry 1202 such that the storage node 1200 is operable to perform some or all of the steps of the method 300 and/or 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 1250.

Figure 14 is a block diagram illustrating a storage node 1400 which may implement the method 500 and/or 600 according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 1450. Referring to Figure 14, the storage node 1400 comprises a processor or processing circuitry 1402, and may comprise a memory 1404 and interfaces 1406. The processing circuitry 1402 is operable to perform some or all of the steps of the method 500 and/or 600 as discussed above with reference to Figures 5 and 6. The memory 1404 may contain instructions executable by the processing circuitry 1402 such that the storage node 1400 is operable to perform some or all of the steps of the method 500 and/or 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 1450.

Figure 16 is a block diagram illustrating a storage node 1600 which may implement the method 700 and/or 800 according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 1650. Referring to Figure 16, the storage node 1600 comprises a processor or processing circuitry 1602, and may comprise a memory 1604 and interfaces 1606. The processing circuitry 1602 is operable to perform some or all of the steps of the method 700 and/or 800 as discussed above with reference to Figures 7 and 8. The memory 1604 may contain instructions executable by the processing circuitry 1602 such that the storage node 1600 is operable to perform some or all of the steps of the method 700 and/or 800. 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 1650.

Figure 18 is a block diagram illustrating a storage node 1800 which may implement the method 900 according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 1850. Referring to Figure 18, the storage node 1800 comprises a processor or processing circuitry 1802, and may comprise a memory 1804 and interfaces 1806. The processing circuitry 1802 is operable to perform some or all of the steps of the method 900 as discussed above with reference to Figure 9. The memory 1804 may contain instructions executable by the processing circuitry 1802 such that the storage node 1800 is operable to perform some or all of the steps of the method 900. 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 1850.

Figure 20 is a block diagram illustrating a storage node 2000 which may implement the method 1000 according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 2050. Referring to Figure 20, the storage node 2000 comprises a processor or processing circuitry 2002, and may comprise a memory 2004 and interfaces 2006. The processing circuitry 2002 is operable to perform some or all of the steps of the method 1000 as discussed above with reference to Figure 10. The memory 2004 may contain instructions executable by the processing circuitry 2002 such that the storage node 2000 is operable to perform some or all of the steps of the method 1000. 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 2050.

Figure 22 is a block diagram illustrating a storage node 2200 which may implement the method 1100 according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 2250. Referring to Figure 22, the storage node 2200 comprises a processor or processing circuitry 2202, and may comprise a memory 2204 and interfaces 2206. The processing circuitry 2202 is operable to perform some or all of the steps of the method 1100 as discussed above with reference to Figure 11. The memory 2204 may contain instructions executable by the processing circuitry 2202 such that the storage node 2200 is operable to perform some or all of the steps of the method 1100. 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 2250.

In some examples, the processor or processing circuitry 1202, 1402, 1602, 1802, 2002, 2202 described above may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, etc. The processor or processing circuitry 1202, 1402, 1602, 1802, 2002, 2202 may be implemented by any type of integrated circuit, such as an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) etc. The memory 1204, 1404, 1604, 1804, 2004, 2204 may include one or several types of memory suitable for the processor, such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, solid state disk, hard disk drive etc.

Figure 13 illustrates functional units in another example of storage node 1100 which may execute examples of the methods 300 and/or 400 of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in Figure 13 are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to Figure 13, the storage node comprises a receiving module 1302 for receiving, from a fetching node, a request for candidate transport addresses associated with a target computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol, and wherein the request includes an identification of the target computing device. The storage node further comprises a memory module 1304 for retrieving from a memory at least one candidate transport address that is associated in the memory with the received identification of the target computing device, and a transmitting module 1306 for sending the retrieved candidate transport address to the fetching node. The storage node may also comprise interfaces 1308.

Figure 15 illustrates functional units in another example of fetching node 1500 which may execute examples of the methods 500 and/or 600 of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in Figure 15 are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to Figure 15, the fetching node comprises a receiving module 1502 for receiving, from an invoking node, a request for candidate transport addresses associated with a target computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. The fetching node also comprises a transmitting module 1504 for sending, to a storage node, a request for candidate transport addresses associated with the target device, the request including an identification of the target computing device. The receiving module 1502 is also for receiving, from the storage node, at least one candidate transport address associated with the target device. The transmitting module is also for sending the received at least one candidate transport address to the invoking node. The fetching node may also comprise interfaces 1508.

Figure 17 illustrates functional units in another example of invoking node 1700 which may execute examples of the methods 700 and/or 800 of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in Figure 17 are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to Figure 17, the invoking node 1700 comprises an identification module 1702 for obtaining an identification of a target computing device. The invoking node also comprises a transmitting module 1704 for sending, to a fetching node, a request for candidate transport addresses associated with the target device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol, and wherein the request includes the obtained identification of the target computing device. The invoking node also comprises a receiving module 1706 for receiving, from the fetching node, at least one candidate transport address associated with the target computing device. The transmitting module 1704 is also for sending a message to the target computing device using the at least one candidate transport address. The invoking node may further comprise interfaces 1708.

Figure 19 illustrates functional units in another example of generating node 1900 which may execute examples of the method 900 of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in Figure 19 are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to Figure 19, the generating node 1900 comprises a description module 1902 for generating a description of the computing device wherein the description comprises a URI of a resource hosted on the computing device, wherein the authority component of the URI comprises a placeholder identifier of the computing device, and wherein the URI specifies a scheme that supports candidate transport addresses, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. The generating node may also comprise interfaces 1904.

Figure 21 illustrates functional units in another example of computing device 2100 which may execute examples of the method 1000 of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in Figure 21 are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to Figure 21 , the computing device comprises an address module 2102 for obtaining candidate transport addresses for the computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. The computing device further comprises a transmitting module 2104 for sending the candidate transport addresses to a storage node. The computing device 2100 may also comprise interfaces 2106. Figure 23 illustrates functional units in another example of management node 2300 which may execute examples of the method 1100 of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in Figure 23 are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to Figure 23, the management node 2300 comprises an address module 3202 for obtaining candidate transport addresses for the computing device, wherein a candidate transport address comprises an IP address, a port number and an identification of a transport protocol. The management node further comprises a transmitting module 2304 for sending the candidate transport addresses to a storage node. The management node may also comprise interfaces 2306.

Examples of the present disclosure provide nodes and methods that may be performed by such nodes that enable the integration of NAT traversal connectivity establishment procedures in existing loT Thing Description formats and methods. Examples of the present disclosure also provide a new URI scheme via which certain of the methods may be implemented. It will be appreciated that the NAT traversal provided by examples of the present disclosure enables an invoking node to access loT devices that are located behind one or more NATs and/or relay nodes when the invoking node itself is on the other, public side of the NAT or relay node. Examples of the present disclosure enable loT devices to implement only minimal NAT traversal solutions themselves, so saving energy and processing resources. Examples of the methods proposed herein are dynamic and can adapt to changes in the network, for example if a device behind a NAT is assigned a new IP address and port number. Examples of the methods proposed herein thus enable devices and agents to have consistent URIs for resources, independent of their network topology.

Examples of the methods disclosed herein can be performed in the application layer, meaning there is no impact on the underlying HTTP stack. Thus for example, the methods can be implemented using the new wice URI scheme without requiring the HTTP stack to support the wice URI, or to contact the candidate storage node. Instead, it is the application server that supports wice URI and contacts the storage node, and this can be implemented in software or middleware, without requiring hardware changes or modifications to standard components of protocol stacks. Implementation as a middleware between the HTTP stack and an application offers the advantage of being able to use the same handler for multiple applications.

It will be appreciated that examples of the present disclosure may be virtualised, such that the methods and processes described herein may be run in a cloud environment.

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.

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 embodiments 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.