Providing network access information for a computing device

Abstract

A computing device including processing circuitry is disclosed, the processing circuitry being configured to cause the computing device to: expose (110) at least one resource hosted by the computing device to an application server; and provide (120) to the application server a hypermedia document that provides access to values of parameters that characterize access to a communication network on which the computing device is operable to communicate. The hypermedia document conforms to a data model for use by constrained devices. An application server is also disclosed that is operable to use the values of the parameters provided in the hypermedia document to prepare for an interaction with a resource hosted by the computing device. Methods performed by the computing device and the application server are also disclosed.

Description

Technical Field

[0001] The present disclosure relates to computing devices, application servers, methods performed by computing devices, methods performed by application servers, and to corresponding computer programs and computer program products. Background Art

[0002] The "Internet of Things" (IoT) refers to devices that can be connected to a communication network so that these devices can be remotely managed and data collected by or required for the devices can be exchanged between individual devices and between the devices and an application server. Such devices (examples of which can include sensors and actuators) are typically (but 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 operating situation, and can therefore be referred to as constrained devices. Constrained devices can operate according to a range of protocols, including widely used protocols such as Internet Protocol (IP) v4 or IPv6 and Hypertext Transfer Protocol (HTTP), as well as dedicated protocols for constrained devices such as Constrained Application Protocol (CoAP).

[0003] In many cases, the best way to interact with IoT devices depends on the capabilities of the communication network to which the devices are connected. Different communication network access technologies are optimized for different types of interaction patterns at different times. For example, 3rd Generation Partnership Project (3GPP) Cellular IoT (C-IoT) devices can use a range of different settings for discontinuous reception (DRX) cycles, or LoRaWAN devices can sometimes have only one-way network access. Overall, 5th Generation (5G) networks and access technologies include a rich set of capabilities that can be used in IoT scenarios if relevant applications are made aware of such capabilities and can utilize them.

[0004] Among the functions defined by 3GPP to work on the network, the Service Capability Enabling Function (SCEF) exposes limited user equipment (UE) information such as (approximate) location, subscription status, uptime, etc. This information is stored in the SCEF and can be accessed by an application server via a dedicated Application Programming Interface (API). However, this API is specific to the SCEF and therefore an SCEF API implementation is required for an application to utilize the API. An additional challenge in the IoT context is that IoT devices currently do not provide network access information and therefore there is no vocabulary that allows such information to be represented. API specification formats (such as OpenAPI) can be used to provide a static description of the Uniform Resource Locator (URL) and interaction of IoT devices. However, such formats cannot provide dynamic information such as information related to changing network conditions. Summary of the Invention

[0005] An object of the present disclosure is to provide a computing device, an application server, a method, and a computer-readable medium that at least partially solve one or more of the above challenges.

[0006] According to a first aspect of the present disclosure, there is provided a computing device including a processing circuit configured to cause the computing device to: open at least one resource hosted by the computing device to an application server; and provide the application server with a hypermedia document that provides access to values of parameters characterizing access of the computing device to a communication network on which the computing device is operable to communicate. The hypermedia document conforms to a data model used by a constrained device.

[0007] According to another aspect of the present disclosure, there is provided an application server including a processing circuit configured to cause the application server to: discover at least one resource hosted by a computing device; receive from the computing device a hypermedia document that provides access to values of parameters characterizing access of the computing device to a communication network on which the computing device is operable to communicate, wherein the hypermedia document conforms to a data model used by a constrained device. The processing circuit is further configured to cause the application server to: use the values of the parameters characterizing access of the computing device to the communication network to prepare an interaction with the resource hosted by the computing device; and initiate the prepared interaction with the resource hosted by the computing device.

[0008] According to another aspect of the present disclosure, there is provided a method performed by a computing device, the method including: opening at least one resource hosted by the computing device to an application server; and providing the application server with a hypermedia document that provides access to values of parameters characterizing access of the computing device to a communication network on which the computing device is operable to communicate. The hypermedia document conforms to a data model used by a constrained device.

[0009] According to another aspect of the present disclosure, there is provided a method performed by an application server, the method including: discovering at least one resource hosted by a computing device; and receiving from the computing device a hypermedia document that provides access to values of parameters characterizing access of the computing device to a communication network on which the computing device is operable to communicate, wherein the hypermedia document conforms to a data model used by a constrained device. The method further includes: using the values of the parameters characterizing access of the computing device to the communication network to prepare an interaction with the resource hosted by the computing device; and initiating the prepared interaction with the resource hosted by the computing device.

[0010] According to another aspect of the present disclosure, there is provided a computer program including instructions that, when executed on at least one processor, cause the at least one processor to execute a method according to any one of the aspects or examples of the present disclosure.

[0011] According to another aspect of the present disclosure, there is provided a carrier containing a computer program according to the foregoing aspect of the present disclosure, wherein the carrier includes one of an electrical signal, an optical signal, a radio signal, or a computer-readable storage medium.

[0012] According to another aspect of the present disclosure, there is provided a computer program product including a non-transitory computer-readable medium having stored thereon a computer program according to the foregoing aspect of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] To better understand the present disclosure and to more clearly illustrate how the present disclosure may be implemented, reference will now be made, by way of example, to the following drawings, in which:

[0014] Figure 1 is a flowchart showing process steps in a method executed by a computing device;

[0015] Figure 2 is a flowchart showing process steps in a method executed by an application server;

[0016] Figure 3a and 3b is a flowchart showing process steps in another example of a method executed by a computing device;

[0017] Figure 4 is a flowchart showing process steps in another example of a method executed by an application server;

[0018] Figure 5 is a message flow diagram showing communication between a computing device and an application server;

[0019] Figure 6 is a block diagram showing functional modules in a computing device; and

[0020] Figure 7 is a block diagram showing functional modules in an application server. DETAILED DESCRIPTION

[0021] Aspects of the present disclosure provide methods, computing devices, and application servers, according to which network access information of a computing device is provided to an application server via a hypermedia document. For the purposes of the present disclosure, a "document" includes a set of structured information. Information may be generated and / or input into the structured set when providing the document, and / or information may be stored in a document in a structured form. A hypermedia document includes a document that contains at least one hypermedia element, as described below.

[0022] Hypermedia concepts for the Internet of Things (IoT) can facilitate the discovery, access, and interoperability of heterogeneous IoT devices. Based on network technologies familiar to humans for browsing the web, hypermedia for IoT can be used to describe how IoT devices can access and operate other IoT devices ("machine-to-machine"). A hypermedia document provides a runtime mapping from the abstract interactions that an IoT device is allowed to perform to the specific protocol operations that enable the device to perform such interactions. This includes the network transport protocol to be used (e.g., CoAP or HTTP), the protocol method to be invoked, and the data to be submitted.

[0023] The core of a hypermedia document includes a list of Uniform Resource Locators (URLs) from which a client can select the "best" URL for a given interaction. What constitutes the "best" URL depends on the specific application and the current application state. The selection of a suitable URL is facilitated by metadata associated with each URL, and the metadata and the URL together form the hypermedia controls of the document. The metadata typically includes key-value pairs, where the keys are obtained from a standardized vocabulary.

[0024] Constrained RESTful Application Language (CoRAL) is an evolving hypermedia document standard. CoRAL is optimized for IoT use cases by encoding the list of URLs and the associated metadata in a compact and easy-to-process format that is even suitable for devices with limited system resources (such as microcontrollers).

[0025] Examples of the present disclosure propose that access to network access information for a computing device can be provided via a hypermedia document provided to an application server. The network access information may be included in the hypermedia document, or the hypermedia document may include a pointer to the network access information. The network access information exchanged in this way may include dynamic information, such as information related to changing network conditions, which may be updated periodically in a new hypermedia document.

[0026] Many hypermedia formats, including CoRAL, do not know about application-specific vocabularies that can be used to describe metadata for the various URLs included in a hypermedia document. For example, in the current version of CoRAL, CoRAL defines only a minimal vocabulary for the most common metadata items. In particular, CoRAL does not define a vocabulary for the various access technology capabilities used to best interact with a given IoT device. Additionally, there is no definition for the use of network capabilities by a hypermedia proxy that uses CoRAL (e.g., an application server operable to exchange hypermedia documents and use the information provided therein) for any access network.

[0027] Examples of the present disclosure propose an application server that can sense network capabilities and is able to use a new vocabulary (which can be a CoRAL vocabulary) for discovering and using information about network capabilities related to REST resources on a computing device. Examples of the hypermedia formats and vocabularies proposed in the present disclosure can enable the use of this information as part of application data (hypermedia) exchange. Hypermedia clients that know the format and vocabulary will be able to optimize their communication with IoT devices accordingly.

[0028] Figure 1 is a flowchart showing the process steps in method 100 performed by a computing device. Refer to Figure 1 According to method 100, in a first step 110, at least one resource hosted by the computing device is opened to an application server. Method 100 also includes providing to the application server a hypermedia document that provides access to values of parameters that characterize the access of the computing device to a communication network on which the computing device is operable to communicate. As shown in 120a, the hypermedia document conforms to a data model used by constrained devices. The communication network on which the computing device is operable to communicate and to which the computing device's access is characterized by parameters can be a communication network on which the computing device is operable to communicate with any other logical or physical entity. Thus, the computing device is operable to communicate with the application server over the communication network. In another example, the computing device can be configured to communicate specifically with the application server over the communication network.

[0029] According to method 100, providing access to values of parameters that characterize the access of the computing device to a communication network on which the computing device is operable to communicate can enable the application server to adjust its behavior to optimize its interaction with the computing device. The interaction with the computing device can be over the communication network between the application server and the computing device, or the application server can initiate an interaction with the computing device via another entity (e.g., another server).

[0030] According to an example of the present disclosure, a computing device may include an Internet of Things (IoT) or machine-to-machine (M2M) device, and the IoT or M2M device may include a constrained device. For the purposes of the present disclosure, a constrained device includes a device that conforms to the definition described in Section 2.1 of RFC 7228 for a "constrained node".

[0031] According to the definition in RFC 7228, a constrained device is a device "where, at the time of writing, some of the features taken for granted in Internet nodes cannot be implemented, typically due to cost constraints and / or physical constraints on features such as size, weight, available power, and energy. Severe restrictions on power, memory, and processing resources result in hard upper bounds on state, code space, and processing cycles, making optimization of energy and network bandwidth usage a major consideration in all design requirements. Additionally, some Layer 2 services may be missing, such as full connectivity and broadcast / multicast". Thus, constrained devices are significantly different from server systems, desktops, laptops, or tablets, and powerful mobile devices such as smart phones. Constrained devices may include, for example, machine-type communication devices, battery-powered devices, or any other devices with the above limitations. Examples of constrained devices may include sensors that measure temperature, humidity, and gas content (e.g., in a room or when goods are being transported and stored), motion sensors for controlling light bulbs, sensors that measure light that can be used to control blinds, heart rate monitors, and other sensors for personal health (continuously monitoring blood pressure, etc.), actuators, and connected electronic door locks. A constrained network correspondingly includes "a network where, at the time of writing, some of the features taken for granted in the link layer commonly used in the Internet cannot be implemented", and more generally, may include a network that includes one or more constrained devices as defined above.

[0032] Resources hosted by a computing device may include digital interfaces that provide access to information or actuation capabilities. In some examples, the information may relate to one or more aspects of a physical entity, and the actuation capabilities may be performed on the physical entity. One or more resources hosted by a computing device may be organized into data objects and may conform to one or more object models. Examples of resources may include: sensor readings such as temperature, pressure, or humidity; the entity state (open, closed, etc.) of a physical entity (such as a valve or a door); or a physical or chemical process (completed x%) and actuation capabilities, including opening, closing, ignition, heating, cooling, etc.

[0033] The data models used by constrained devices and to which hypermedia documents conform include data models suitable for, intended for, or appropriate for constrained devices. Examples of data models used by constrained devices include the data models defined in the Constrained RESTful Application Language (CoRAL). Other examples include the Constrained RESTful Environment (CoRE) Link Format as defined in RFC 6690, and potential future versions of languages such as the Hypertext Application Language (HAL) that may be redesigned to be suitable for constrained environments.

[0034] Method 100 can be supplemented by method 200 that can be executed by an application server. Figure 2 is a flowchart showing the process steps in method 200 that can be executed by an application server, which can be a physical server or a virtualized function running in a cloud, edge cloud, or fog deployment. Refer to Figure 2 , method 200 includes discovering at least one resource hosted by a computing device in a first step 210. In step 220, method 200 includes receiving a hypermedia document from the computing device, the hypermedia document providing access to values of parameters that characterize the access of the computing device to a communication network on which the computing device is operable to communicate, wherein the hypermedia document conforms to a data model used by a constrained device. Method 200 also includes using the values of the parameters that characterize the access of the computing device to the communication network to prepare an interaction with the resource hosted by the computing device in step 230, and initiating the prepared interaction with the resource hosted by the computing device in step 240. As discussed above with reference to Figure 1 , the communication network on which the computing device is operable to communicate and to which the access of the computing device is characterized by parameters can be the communication network on which the computing device is operable to communicate with any other logical or physical entity. Thus, the computing device is operable to communicate with the application server over the communication network. In another example, the computing device can be configured to communicate specifically with the application server over the communication network. The interaction initiated by the application server with the computing device can be carried out between the application server and the computing device over the communication network, or the application server can initiate an interaction with the computing device via another entity (such as another server).

[0035] According to method 200, the application server thus obtains the hypermedia document provided by the computing device according to method 100, and uses the network access information provided by the hypermedia document to provide access to it to prepare an interaction with the resource according to this information. This can include, for example, selecting a time or method for the interaction based on the provided information in order to optimize the execution of the interaction according to one or more parameters.

[0036] Figure 3a and 3bis a flowchart showing process steps in another example of method 300 executed by a computing device. The computing device can be, for example, the constrained device discussed above with reference to Figure 1 The steps of method 300 illustrate an example way in which the steps of method 100 can be implemented and supplemented to achieve the functions discussed above and additional functions.

[0037] First referring to Figure 3a , according to method 300, in a first step 302, the computing device obtains a value of a parameter characterizing the computing device's access to a communication network from the communication network. For example, the computing device is operable to access a 3GPP network and can query the network (e.g., using the 3GPP SCEF API discussed above) to obtain information about the network, which includes at least one value of at least one parameter characterizing the device's access. An example of what the parameter may include is discussed in more detail below with reference to Figure 3b .

[0038] In step 310, the computing device exposes at least one resource hosted by the computing device to an application server. The computing device can expose the resource, for example, by registering the resource in a suitable resource directory function or by responding to a discovery request. In some examples, exposing the resource can include providing a hypermedia document (e.g., a CoRAL document) to the application server, the hypermedia document including a representation of the resource, including, for example, one or more URLs for accessing the resource. In some examples, as shown in 310a, such a hypermedia document can also include information about the device's network access, including a value of a parameter characterizing the device's network access. In other examples, as shown in step 310b, the hypermedia document can include a resource hypermedia document and can include a representation of the resource hosted by the computing device and a pointer to a metadata resource hosted by the computing device, the metadata resource including a value of a parameter characterizing the computing device's access to the communication network.

[0039] In step 320, the computing device provides a hypermedia document to the application server, the hypermedia document providing access to a value of a parameter characterizing the computing device's access to a communication network on which the computing device is operable to communicate, the hypermedia document conforming to a data model used by a constrained device, as discussed above with reference to Figure 1As discussed. As shown in 320, the hypermedia document may include a CoRAL document. The value of a parameter to which the hypermedia document provides access may be, for example, the value obtained in step 302, and / or may include values of parameters that are available to the computing device other than via the communication network. The hypermedia document may provide access to a plurality of key-value pairs, each key-value pair including a parameter identifier (key) and a parameter value (value). The hypermedia document may provide access to the values of a plurality of parameters that characterize the access of the computing device to the communication network. In some examples, the computing device may access a plurality of communication networks, and the hypermedia document may provide access to the values of one or more parameters that characterize the access of the computing device to the respective communication network for each of the plurality of communication networks.

[0040] In some examples, as shown in 320, a vocabulary specified in a data model may be used to represent parameters that characterize the access of a computing device to a communication network over which the computing device is operable to communicate. The use of the vocabulary specified in the data model may help ensure that the application server can understand the representation of the parameters and parameter values. In a first option according to the present disclosure, the parameter or parameter values may be included in a hypermedia document that may also include a representation of a resource, and the parameter values may be included, for example, as an annotation into the resource representation. In a second option according to the present disclosure, the parameter values may be exposed as a metadata resource hosted by the computing device, and the hypermedia document may provide access to the parameter values by including a pointer to the metadata resource. In such an example, the parameter values may be included in a separate metadata document provided to the application server, which document itself may or may not be a hypermedia document.

[0041] The first of the options discussed above is illustrated in steps 310a and 320a of FIG. 3, according to which the hypermedia document provided in step 320 includes a representation of a resource hosted by the computing device, and the values of the parameters that characterize the access of the computing device to the communication network are included as an annotation in the resource representation of the hypermedia document. The representation of the resource includes at least one hypermedia control for the resource. According to this option, steps 310 and 320 may be performed in a single interaction, according to which a single hypermedia document is provided to the application server, the hypermedia document including a representation of the hosted resource and one or more parameter values that characterize the network access of the computing device, the one or more parameter values being included as an annotation into the resource representation.

[0042] The second of the options discussed above is illustrated in steps 310b and 320b of FIG. 3. According to this option, the hypermedia document provided in step 320 is a resource hypermedia document that includes a representation of a resource and a pointer to a metadata resource hosted by a computing device and including values of parameters. According to this option, in step 330, the computing device may provide a metadata document that includes a representation of the metadata resource, where the metadata resource includes values of parameters characterizing the computing device's access to one or more communication networks. The metadata document may or may not be a hypermedia document, as shown at 330a. Thus, the second option contemplates providing access to parameters characterizing network access via indirection in the hypermedia document, using a pointer to direct the application server to a separate resource containing the network access information. Although this second option contemplates additional interaction with the application server to provide two separate documents (the hypermedia document and a second document that may or may not be a hypermedia document), the second option provides economies of scale because the network access information is provided in a separate resource rather than being included as an annotation in each resource hosted by the computing device. The relative advantages of the first and second options may vary depending on the specific use case, deployment, or implementation scenario.

[0043] Figure 3b A series of options for parameters characterizing a computing device's access to a communication network are shown. It will be understood that the computing device may provide one or more values for any number of suitable parameters in step 120 or 320 of the methods discussed above, and any one or more of the parameters may fall within Figure 3b any one or more of the categories shown. Referring to Figure 3b , parameters characterizing a computing device's access to a communication network may include at least one of the following:

[0044] a) The capabilities of the computing device for interacting with the communication network

[0045] b) The conditions of the communication network experienced by the computing device

[0046] c) The configuration of the computing device for accessing the communication network

[0047] d) The subscription status of the computing device relative to the communication network.

[0048] The following discussion of example parameters is for illustrative purposes only and includes parameters suitable for C-IoT networks and parameters suitable for LoRaWAN networks.

[0049] Interaction capability parameters may include, for example, non-IP data transfer (NIDD) availability, supported radio capabilities, supported frequency bands, supported uplink data rates, supported downlink data rates, device classes, etc.

[0050] Network condition parameters can include, for example, signal strength, bandwidth, spreading factor, beacon interval, availability of multicast, etc.

[0051] Access configuration parameters can include, for example, power saving mode (PSM) status, discontinuous reception (DRX) and extended discontinuous reception (eDRX) modes, synchronization, network slice identifier, Ethernet segment, etc.

[0052] Subscription status parameters can include, for example, roaming status.

[0053] As discussed above, parameters characterizing a computing device's access to a communication network can be represented in a hypermedia document or a metadata document using a vocabulary specified in a data model. Multiple key-value pairs can be used to represent one or more parameters, and the vocabulary terms (i.e., the keys of the key-value pairs) can conform to the same data model as the hypermedia document that is used by the constrained device. Thus, for example, if the hypermedia document is a CoRAL document, the vocabulary terms used to represent one or more parameters can conform to the CoRAL specification. The vocabulary terms can include globally unique identifiers that are typically constructed as URIs. Details of CoRAL vocabulary terms can be found in Section 6.2 of the CoRAL specification: https: / / www.ietf.org / id / draft-ietf-core-coral-03.html#name-minting-vocabu lary. The vocabulary used to represent one or more parameters can be an extension of an existing vocabulary or a new vocabulary. It will be understood that multiple vocabularies can be used together, and identifiers that are not globally unique in an existing vocabulary can be made globally unique by providing a globally unique prefix for those identifiers. The example provided below uses the globally unique prefix "http: / / vocabulary.example.org / lte#", but it will be understood that "example.org" can be replaced by the domain name of an organization (e.g., an organization that seeks to standardize the vocabulary).

[0054] As referenced above Figure 2 as discussed, the methods performed at the computing device as discussed herein can be supplemented by the method 200 performed by an application server. Figure 4 is a flowchart showing process steps in another example of a method 400 performed by an application server, which can be a physical server device or a virtualized application server running in a cloud, edge cloud, or fog deployment. The application server can include a hypermedia proxy as it is operable to use hypermedia documents.

[0055] The steps of method 400 illustrate an example manner in which the steps of method 200 discussed above can be implemented and supplemented to achieve the functions discussed above and additional functions.

[0056] Referring Figure 4 , according to method 400, in a first step 410, the application server discovers at least one resource hosted by the computing device. This can include, for example, querying a resource directory function or sending a discovery request to a suitable unicast or multicast address and receiving a discovery response. In some examples, discovering the resource can include receiving a hypermedia document (e.g., a CoRAL document) from the computing device, the hypermedia document including a representation of the resource, the representation including, for example, one or more URLs for accessing the resource. In some examples, as shown in 410a, such a hypermedia document can also include information about the device's network access. In other examples, as shown in step 410b, the hypermedia document can include a resource hypermedia document and can include: a representation of the resource hosted by the computing device; and a pointer to a metadata resource hosted by the computing device and including a value of a parameter characterizing the computing device's access to the communication network.

[0057] In step 420, the application server receives a hypermedia document from the computing device, the hypermedia document providing access to values of parameters characterizing the computing device's access to a communication network over which the computing device is operable to communicate, the hypermedia document conforming to a data model used by a constrained device, as referred to above Figure 1 discussed. As discussed above, the communication network over which the computing device is operable to communicate and to which the computing device's access is characterized by the parameter can be the communication network over which the computing device is operable to communicate with any other logical or physical entity. Thus, the computing device is operable to communicate with the application server over the communication network. In another example, the computing device can be configured to communicate specifically with the application server over the communication network.

[0058] As shown in 420, the hypermedia document can include a CoRAL document. The hypermedia document can provide access to a plurality of key-value pairs, each key-value pair including a parameter identifier (key) and a parameter value (value). The hypermedia document can provide access to values of a plurality of parameters characterizing the computing device's access to the communication network. In some examples, the computing device can access multiple communication networks, and the hypermedia document can provide access to values of one or more parameters characterizing the computing device's access to each of the multiple communication networks. Examples of what one or more parameters might include are discussed in more detail above Figure 3b with reference to.

[0059] In some examples, as shown in 420, a vocabulary specified in a data model can be used to represent parameters that characterize a computing device's access to a communication network over which the computing device is operable to communicate. The use of the vocabulary specified in the data model can help ensure that an application server can understand the representation of the parameters and parameter values. As discussed above with reference to Figure 3a In a first option according to the present disclosure, as discussed, a parameter or parameter values can be included in a hypermedia document that can also include a representation of a resource, and the parameter values can be included, for example, as an annotation into the resource representation. In a second option according to the present disclosure, the parameter values can be exposed as a metadata resource hosted by the computing device, and the hypermedia document can provide access to the parameter values by including a pointer to the metadata resource. In such an example, the parameter values can be received in a separate metadata document, which itself can or can not be a hypermedia document.

[0060] In Figure 4 The first of the options discussed above is illustrated in steps 410a and 420a of

[0061] In Figure 4 The second of the options discussed above is illustrated in steps 410b and 420b of

[0062] In step 430, the application server uses one or more values of one or more parameters that characterize the computing device's access to the communication network to prepare an interaction with the resource hosted by the computing device. AsFigure 4 As shown, this can include selecting at least one of a time or a method for interaction with a resource hosted by a computing device based on the value. As shown in steps 430a and 430b, selecting at least one of a time or a method for interaction with a resource hosted by a computing device based on the value can include: determining, based on the value, at least one of a time or a method for interaction that will optimize a performance parameter related to the interaction, and selecting the determined time or method.

[0063] A suitable performance parameter for interaction with a resource can be selected or defined according to the nature of the resource and the interaction, use cases, etc. Example performance parameters for resource interaction can include cost, chance of success, network resource usage, etc. For example, an application server can delay or advance a planned interaction with a resource to synchronize with a DRX cycle of a computing device, or can delay execution of a non-critical command until network conditions are favorable. In other examples, an application server can select polling information or use an observation process according to network conditions and / or access availability of a computing device. In yet another example, an application server can balance the computational cost of compressed data with the available bandwidth for communicating with a computing device, and thus can select a suitable method (compress or not compress data) and / or a suitable time (delay sending of data until more bandwidth is available) according to the operation priority of the application server and network access information obtained in a hypermedia document.

[0064] In step 440, the application server initiates the prepared interaction with the resource hosted by the computing device. This can include sending a message to the computing device, instructing another entity to send a message, etc. In some examples, the interaction with the computing device can be carried out between the application server and the computing device via a communication network. In other examples, the application server can initiate an interaction with the computing device via another entity (such as another server).

[0065] The following discussion provides example details of how the above methods can be implemented to facilitate providing network access information for a computing device to an application server using a hypermedia document. As described above, in some examples, the network access information can be included in the hypermedia document as metadata about a resource URL, or included as a separate metadata resource. To include this metadata, it is helpful to define a vocabulary to describe the network-related capabilities and characteristics that need to be defined. The vocabulary can include, for example, terms for information related to a 3GPP C-IoT user equipment (UE) regarding the following items: the roaming state of the UE, the power saving mode (PSM) state, the DRX or eDRX cycle length, NIDD availability, signal strength (e.g., when the signal quality is judged to be sufficient, allowing the application server to select communication), synchronization, allowing communication to skip the initial synchronization search, supported radio capabilities (modulation methods, etc.), supported frequency bands, supported uplink data rates, supported downlink data rates, etc. For LoRaWAN devices, the information can include the device class (A, B, or C), bandwidth, spreading factor, beacon interval, or availability of multicast.

[0066] As discussed above, a device on a 3GPP network can query the network (e.g., using the 3GPP SCEF API) to obtain information about the network and, when acting as a server, publish this information as metadata using the recommended vocabulary in CoRAL or other hypermedia documents, or publish a resource indicated by such a document. Similarly, a device on a LoRaWAN network can indicate the beacon period or unicast / multicast availability of the network in CoRAL or other hypermedia documents. A client (application) interacting with these computing devices will use the published information to select how to interact with these computing devices.

[0067] Example Use Case 1: Firmware Update via 3GPP

[0068] When performing a device firmware update, the device management protocol typically only considers the attributes of the device (device type, battery, IP connection, etc.) and not the network attributes (roaming, PSM, DRX, eDRX, NIDD availability, reachability, etc.). According to an example of the present disclosure, the device management protocol can also consider network attributes. For example, if a heterogeneous group of devices needs to perform a firmware update within a specific period, the following steps can be performed, as Figure 5 shown:

[0069] 1. The application server (AS) performs a discovery operation on the device.

[0070] 2. The device returns a CoRAL document that has information on how to update the firmware of the device, including specific device attributes and (bold) network attributes.

[0071]

[0072] In this example document, network attributes include whether the device is roaming (using the term e:roaming from an exemplary vocabulary) and its PSM state (using the term e:psm).

[0073] 3. To ensure that firmware updates are successful and not costly, the AS does not perform firmware updates when the device is roaming, the battery level is low, or PSM is active.

[0074] 4. Once the AS has verified that the device is in a suitable condition and is experiencing appropriate network conditions to receive its firmware update, the AS triggers the firmware update process (using the PUT method for resources or instructing another server to perform the update on behalf of the AS).

[0075] Example Use Case 2: Firmware Update via LoRaWAN

[0076] When using LoRaWAN, firmware updates can also consider LoRa network attributes, including for example device class, beacon period, unicast / multicast mode, transmit power, channels, ping period, etc.

[0077] Continuing with the previous example, the following steps can be used to optimize the firmware update for a group of mobile or wall-mounted devices for battery consumption (LoRaWAN Class B):

[0078] 1. The updating party performs a discovery operation on the LoRaWAN device.

[0079] 2. The device returns a CoRAL document that has information on how to update the firmware of the device, including specific device attributes and (bold) network attributes.

[0080]

[0081] In this example document, network attributes include whether the device belongs to LoRaWAN Class B (using the term w:device-class from an exemplary vocabulary), and if so, include information for synchronizing receive windows (w:b-period).

[0082] 2. To ensure that firmware updates are successful and not costly, these updates can be performed only on Class B devices using the specified synchronization window (in this example, synchronization occurs every 400 seconds).

[0083] 3. Once the updater has verified that the device is in a suitable condition and is experiencing appropriate network conditions to receive its firmware update, the updater triggers the firmware update process (using the PUT method for the resource, or instructing another server to perform the update on behalf of the AS).

[0084] The above two example use cases illustrate the first option for providing network access information as referred to above. That is, in the above example, the key-value pairs of the parameters characterizing the network access of the computing device are included as annotations in the firmware update resource representation. This option contemplates that all resources opened by the computing device and for which the application server needs to be allowed to consider network access information should be annotated with appropriate network access information. The following example considers the second option, where the network access information is provided as a separate metadata resource. Figure 3a and Figure 4 discussed for providing network access information. That is, in the above example, the key-value pairs of the parameters characterizing the network access of the computing device are included as annotations in the firmware update resource representation. This option contemplates that all resources opened by the computing device and for which the application server needs to be allowed to consider network access information should be annotated with appropriate network access information. The following example considers the second option, where the network access information is provided as a separate metadata resource.

[0085] Example Use Case 3: Network Information Indirection

[0086] Instead of annotating multiple or all hypermedia controls (resource representations and metadata) with network information, the computing device can provide pointers to resources with that information in the hypermedia document. As discussed above, this results in more interactions with the device (fetching additional resources), but avoids duplicating information in all exchanged hypermedia documents. Suitable pointers are as follows:

[0087]

[0088] As shown in the above example use cases, methods 100, 300, 200, and 400 are executed by the computing device and the application server respectively. The present disclosure provides a computing device and an application server adapted to perform any or all of the steps of the methods discussed above.

[0089] Figure 6 is a block diagram showing a computing device 600 that can implement methods 100 and / or 300 according to examples of the present disclosure when receiving appropriate instructions from a computer program 650, for example. Referring to Figure 6 , the computing device 600 includes a processor or processing circuit 602 and may include a memory 604 and an interface 606, such as a CoAP, HTTP, 3GPP radio, or other interface. The processing circuit 602 is operable to execute as referred to above in Figure 1 , 3aSome or all of the steps of methods 100 and / or 300 discussed with 3b. Memory 604 may contain instructions executable by processing circuitry 602 such that computing device 600 is operable to perform some or all of the steps of methods 100 and / or 300. The instructions may also include instructions for performing one or more telecommunication and / or data communication protocols. The instructions may be stored in the form of a computer program 650.

[0090] Figure 7 is a block diagram showing application server 700, which may implement methods 200 and / or 400 according to examples of the present disclosure, for example, when receiving appropriate instructions from computer program 750. Refer to Figure 7 , application server 700 includes a processor or processing circuitry 702 and may include a memory 704 and an interface 706, such as CoAP, HTTP, 3GPP radio, or other interfaces. Processing circuitry 702 is operable to perform some or all of the steps of methods 200 and / or 400 as discussed above with reference to Figure 2 and 4 discussed. Memory 704 may contain instructions executable by processing circuitry 702 such that application server 700 is operable to perform some or all of the steps of methods 200 and / or 400. The instructions may also include instructions for performing one or more telecommunication and / or data communication protocols. The instructions may be stored in the form of a computer program 750.

[0091] In some examples, the above-mentioned processor or processing circuitry 702, 802 may include one or more microprocessors or microcontrollers and other digital hardware, which may include a digital signal processor (DSP), dedicated digital logic, etc. The processor or processing circuitry 702, 802 may be implemented by any type of integrated circuit, such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc. Memory 704, 804 may include one or several types of memory suitable for the processor, such as read only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, solid state disks, hard disk drives, etc.

[0092] Accordingly, aspects and examples of the present disclosure present computing devices, application servers, and associated methods that can enable a device to provide network access information so that an application server can optimize interactions between the application server and the device based on the device's access network conditions and capabilities. These methods, devices, and application servers can be supported by a vocabulary for representing parameters characterizing a computing device's access to a communication network. The vocabulary can, for example, allow for a concise representation of parameters and is thus suitable for use by constrained devices and can be compatible with the CoRAL application language, e.g., be standardized within the CoRAL application language. Examples of the present disclosure enable a computing device to direct an application server, acting as a hypermedia client, to communicate with the device in a network-level optimized manner. For example, the computing device can indicate that the best way to interact with it is for the client to defer execution of non-time-critical commands until network conditions permit optimal execution. In another example, the client can choose not to poll IoT sensors but instead receive periodic notifications when the sensor network is congested, the sensors have a high uplink cost, or the uplink is unavailable. In yet another example, the client can choose whether to compress data to be sent to the device based on link conditions (encoding complexity versus network access usage) and characteristics (available bandwidth, etc.). Using hypermedia documents to provide network access information ensures that the information can be dynamically updated to reflect changing conditions in the network, changing device environments, etc.

[0093] It will be understood that examples of the present disclosure can be virtualized such that the methods and processes described herein can be run in a cloud environment.

[0094] The methods of the present disclosure can be implemented in hardware or as software modules running on one or more processors. These methods can also be performed in accordance with the instructions of a computer program, and the present disclosure also provides a computer-readable medium having stored thereon a program for performing any of the methods described herein. A computer program embodying the present disclosure can be stored on a computer-readable medium, or it can, for example, take the form of a signal, such as a downloadable data signal provided from an Internet website, or it can take any other form.

[0095] It should be noted that the above examples illustrate rather than limit the present disclosure, and 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 and steps other than those listed in the claims, "a" or "an" does not exclude a plurality, and a single processor or other unit can implement the functions of a plurality of units recited in the claims. Any reference signs in the claims shall not be construed as limiting the scope of the claims.

Claims

1. A computing device (600) including a processing circuit (602), the processing circuit being configured to cause the computing device to: Opening at least one resource (110) hosted by the computing device to the application server by providing a hypermedia document to the application server, wherein, The hypermedia document includes: A representation of the resource hosted by the computing device; and A pointer to a metadata resource, the metadata resource being hosted by the computing device and including values of parameters characterizing the computing device's access to a communication network, the communication network being a communication network on which the computing device is operable to communicate; Wherein, the hypermedia document conforms to a data model (120a) used by a constrained device.

2. The computing device according to claim 1, wherein The parameters characterizing the computing device's access to the communication network include at least one of the following: The computing device's ability (352) to interact with the communication network; The condition (354) of the communication network experienced by the computing device; The computing device's configuration (356) for accessing the communication network; The computing device's subscription status (358) relative to the communication network.

3. The computing device according to claim 1, wherein, The hypermedia document includes a resource hypermedia document, and wherein the processing circuit is further configured to cause the computing device to: provide a metadata document including a representation of the metadata resource, the metadata resource including the values of the parameters characterizing the computing device's access to the communication network, to an application server (330).

4. The computing device according to claim 3, wherein, The metadata document includes a multimedia document (330a).

5. The computing device according to claim 1, wherein, The parameters characterizing the computing device's access to the communication network on which the computing device is operable to communicate are represented using a vocabulary specified in the data model.

6. The computing device according to claim 1, wherein, The processing circuit is further configured to cause the computing device to: Obtain the values of the parameters characterizing the computing device's access to the communication network from the communication network (302).

7. The computing device according to claim 1, wherein, The hypermedia document includes a Constrained RESTful Application Language CoRAL document (320).

8. An application server (700) including a processing circuit (702), the processing circuit being configured to cause the application server to: By receiving a hypermedia document from a computing device, at least one resource (210) hosted by the computing device is discovered, wherein, The hypermedia document includes: A representation of the resource hosted by the computing device; and A pointer to a metadata resource, the metadata resource being hosted by the computing device and including values of parameters characterizing the computing device's access to a communication network, the communication network being a communication network on which the computing device is operable to communicate, wherein the hypermedia document conforms to a data model (220) used by a constrained device; Prepare an interaction with the resource hosted by the computing device using the values of the parameters characterizing the computing device's access to the communication network (230); and Initiate the prepared interaction with the resource hosted by the computing device (240).

9. The application server according to claim 8, wherein, The processing circuit is configured to cause the application server to: prepare an interaction with the resource hosted by the computing device using the values of the parameters characterizing the computing device's access to the communication network by: Based on the value, select at least one of a time or a method for the interaction with the resource hosted by the computing device (430).

10. The application server according to claim 9, wherein, The processing circuitry is configured to cause the application server to select at least one of a time or a method for the interaction with the resource hosted by the computing device based on the value by: Based on the value, determine at least one of a time or a method for the interaction that will optimize a performance parameter associated with the interaction (430a); And Select the determined time or method (430b).

11. The application server according to claim 8, wherein, The parameter characterizing the access of the computing device to the communication network includes at least one of the following: The ability of the computing device to interact with the communication network (352); The condition of the communication network experienced by the computing device (354); The configuration of the computing device for accessing the communication network (356); The subscription status of the computing device relative to the communication network (358).

12. The application server according to claim 8, wherein, The hypermedia document includes a resource hypermedia document, and wherein the processing circuitry is further configured to cause the application server to receive from the computing device a metadata document including a representation of the metadata resource, the metadata resource including the value of the parameter characterizing the access of the computing device to the communication network (425).

13. The application server according to claim 12, wherein, The metadata document includes a hypermedia document (425a).

14. The application server according to claim 8, wherein, The parameter characterizing the access of the computing device to the communication network on which the computing device is operable to communicate is represented using a vocabulary specified in a data model.

15. The application server according to claim 8, wherein, The hypermedia document includes a Constrained RESTful Application Language CoRAL document (420).

16. A method (100) performed by a computing device, the method comprising: Open at least one resource hosted by the computing device to an application server by providing a hypermedia document to the application server, wherein the hypermedia document includes: A representation of the resource hosted by the computing device; and A pointer to a metadata resource hosted by the computing device and including a value of a parameter characterizing the access of the computing device to a communication network on which the computing device is operable to communicate; Wherein the hypermedia document complies with a data model for use by constrained devices (120a).

17. The method according to claim 16, further comprising: Perform the steps described in any one of claims 2 to 7.

18. A method (200) performed by an application server, the method comprising: Discover at least one resource hosted by the computing device by receiving a hypermedia document from the computing device, wherein the hypermedia document includes: A representation of the resource hosted by the computing device; and A pointer to a metadata resource, the metadata resource being hosted by the computing device and including values of parameters characterizing the computing device's access to a communication network, the communication network being a communication network on which the computing device is operable to communicate, wherein the hypermedia document conforms to a data model (220) used by a constrained device; Preparing an interaction with the resource hosted by the computing device (230) using the values of the parameters characterizing the computing device's access to the communication network; and Initiating the prepared interaction with the resource hosted by the computing device (240).

19. The method according to claim 18, further comprising: Performing the steps described in any one of claims 9 to 15.

20. A computer-readable storage medium having instructions stored thereon, the instructions when executed on at least one processor causing the at least one processor to perform the method according to any one of claims 16 to 19.

21. A computer program product comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any one of claims 16 to 19.

Images