Mechanisms for semantics publishing and discovery
1. A device used for discovering semantics related resource identifiers, the device comprising:
- a processor; and
a memory coupled with the processor, the memory comprising executable instructions that when executed by the processor cause the processor to effectuate operations comprising;
receiving a request for a semantics related resource from a requesting device, the request comprising a first keyword;
determining that the requested semantics related resource is not locally stored on the device;
responsive to determining that the requested semantics related resource is not locally stored on the device, matching the first keyword with a second keyword, the second keyword associated with an identifier of the semantics related resource; and
forwarding, to the requesting device, an address of a semantics node contained in the identifier based on the matching of the first keyword with the second keyword, wherein the address comprises URI or URL.
Methods, devices, and systems may be used for semantics publishing and discovery. In an embodiment, a method for publishing semantics related resource identifiers may include adding a key word to an identifier of a semantics related resource and publishing the identifier to at least one of a sibling node and a child node. In another embodiment, a method may include using a Bloom filter to publish a semantics related resource. In another embodiment, a method may include publishing, by a semantics node, an identifier of a semantics related resource to a sibling node, while publishing a digest of the semantics node to a child node.
View as Search Results
|System and Method for Generating an Application Structure for an Application in a Computerized Organization|
Patent #US 20160364212A1
Current AssigneeServiceNow Incorporated
Sponsoring EntityServiceNow Incorporated
|System and method for generating an application structure for an application in a computerized organization|
Patent #US 10,048,943 B2
Current AssigneeServiceNow Incorporated
Sponsoring EntityServiceNow Incorporated
|System and method for generating an application structure for an application in a computerized organization|
Patent #US 10,394,527 B2
Current AssigneeServiceNow Incorporated
Sponsoring EntityServiceNow Incorporated
|Constructing and maintaining a personalized category tree, displaying documents by category and personalized categorization system|
Patent #US 7,865,530 B2
Current AssigneeInternational Business Machines Corporation
Sponsoring EntityInternational Business Machines Corporation
|Search engine for video and graphics|
Patent #US 7,987,174 B2
Current AssigneeRovi Guides Inc.
Sponsoring EntityGemstar Development Corporation
|METHOD AND APPARATUS FOR INTEGRATING APPLICATIONS ON DEMAND TO DISPLAY AND MANIPULATE A SEMANTIC RESOURCE|
Patent #US 20110289520A1
Current AssigneeNokia Technologies Oy
Sponsoring EntityNokia Corporation
|URL based communication protocol from a client computer to a network device|
Patent #US 7,761,500 B1
Current AssigneeCisco Technology Incorporated
Sponsoring EntityCisco Technology Incorporated
|URL reputation system|
Patent #US 8,229,930 B2
Current AssigneeMicrosoft Technology Licensing LLC
Sponsoring EntityMicrosoft Corporation
|Method and apparatus for integrating applications on demand to display and manipulate a semantic resource|
Patent #US 8,370,863 B2
Current AssigneeNokia Technologies Oy
Sponsoring EntityNokia Corporation
|METHOD AND APPARATUS FOR USING MULTIPLE UNIVERSAL RESOURCE IDENTIFIERS IN M2M COMMUNICATIONS|
Patent #US 20140067902A1
Current AssigneeInterDigital Patent Holdings Inc.
Sponsoring EntityInterDigital Patent Holdings Inc.
|Semantics Support and Management in M2M Systems|
Patent #US 20140330929A1
Current AssigneeConvida Wireless LLC
Sponsoring EntityConvida Wireless LLC
|Navigable semantic network that processes a specification to and uses a set of declaritive statements to produce a semantic network model|
Patent #US 9,087,296 B2
Current AssigneeAdobe Systems Incorporated
Sponsoring EntityAdobe Systems Incorporated
|METHOD AND SYSTEM FOR SEMANTICALLY QUERYING A DATABASE BY A MACHINE-TO-MACHINE APPLICATION|
Patent #US 20160004767A1
Current AssigneeNEC Corporation
Sponsoring EntityNEC Europe Ltd
|Optimized ontology based internet search systems and methods|
Patent #US 9,262,527 B2
Current AssigneeNew Jersey Institute of Technology
Sponsoring EntityNew Jersey Institute of Technology
|Method and apparatus for authenticating access authority for specific resource in wireless communication system|
Patent #US 9,654,971 B2
Current AssigneeLG Electronics Inc.
Sponsoring EntityLG Electronics Inc.
- 1. A device used for discovering semantics related resource identifiers, the device comprising:
a processor; and a memory coupled with the processor, the memory comprising executable instructions that when executed by the processor cause the processor to effectuate operations comprising; receiving a request for a semantics related resource from a requesting device, the request comprising a first keyword; determining that the requested semantics related resource is not locally stored on the device; responsive to determining that the requested semantics related resource is not locally stored on the device, matching the first keyword with a second keyword, the second keyword associated with an identifier of the semantics related resource; and forwarding, to the requesting device, an address of a semantics node contained in the identifier based on the matching of the first keyword with the second keyword, wherein the address comprises URI or URL.
- View Dependent Claims (2, 3, 4, 5)
- 6. A device comprising:
a processor; and a memory coupled with the processor, the memory comprising executable instructions that when executed by the processor cause the processor to effectuate operations comprising; sending, to a first semantics node, a request for a desired first semantics related resource, the request comprising a first keyword; and receiving, from the first semantics node, a response comprising an identifier for a second semantics node that has a second semantics related resource that is associated with a second keyword that matches the first keyword for the desired first semantics related resource; based on the response comprising the identifier, sending a second request to the second semantics node for the second semantics related resource; and in response to the another request, receiving the second semantics related resource from the second semantics node.
- View Dependent Claims (7, 8, 9, 10, 11, 12)
This application claims benefit under 35 U.S.C. §119(e) of Provisional U.S. Patent Application No. 61/842,030, filed Jul. 2, 2013, the content of which is incorporated herein by reference in its entirety.
The rapid increase in the number of network-enabled devices and sensors deployed in physical environments is changing communication networks. It is predicted that within the next decade billions of devices will generate a myriad of real world data for many applications and services by service providers in a variety of areas such as smart grids, smart homes, e-health, automotive, transport, logistics, and environmental monitoring. The related technologies and solutions that enable integration of real world data and services into the current information networking technologies are often described under the umbrella terms of the Internet of things (IoT) or machine-to-machine (M2M) communications. Because of the large amount of data created by devices there is a need for an efficient way to identify and query this data.
However, current M2M systems such as the ETSI M2M Architecture described in Draft ETSI TS 102 690 and TS 102 921, do not define mechanisms to support semantics (e.g., data stored within ETSI M2M defined container resources do not have any semantic information that can be stored along with it). As a result, devices and applications need to agree beforehand on a common definition of the exchanged containers as well as on the contained data. This makes re-use of M2M data across different applications difficult in current M2M systems.
Disclosed herein are methods, devices, and systems for semantics publishing and discovery. In an embodiment, a method for publishing semantics related resource identifiers may include adding a key word to an identifier of a semantics related resource and publishing the identifier to at least one of a sibling node and a child node.
In another embodiment, a method may include using a Bloom filter to publish a semantics related resource. In another embodiment, a method may include publishing, by a semantics node, an identifier of a semantics related resource to a sibling node, while publishing a digest of the semantic node to a child node.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
Semantics related resources that are hosted in a semantics node, may be discovered and used by other computing devices. When a semantics node receives a request for a semantics related resource, the semantics node may check its local semantics database. If there is no match, the semantics node may forward the request to other semantics nodes that have logical relationship with it, for example the sibling nodes or parent nodes.
Systems for semantics publishing and discovery of semantics related resources may include flooding or forwarding each discovery request that cannot be positively answered by a semantics node. If implemented in a large network, flooding or forwarding each request may cause significant overhead and bandwidth consumption on the network. In addition to the aforementioned flooding and forwarding environment, if semantics nodes do not cooperate in returning matching semantics related resources, there may be additional network issues. For example, no cooperation between semantics nodes may cause a semantics node to receive similar matching semantics related resources returned from multiple other semantics nodes, which may impose significant overhead and bandwidth consumption in the network. Disclosed herein are additional semantics related resources schemes that may facilitate discovering (searching for) the location of a semantics related resource and publishing (transmitting) the location of a semantics related resource.
A brief summary of semantics node architecture is presented below. More details with regard to semantics node architecture are provided in the descriptions corresponding to
In conventional machine-to-machine (M2M) systems, M2M applications (hosted on end devices as well as backend network servers) need to agree beforehand on a common definition of exchanged data. This is primarily due to a lack of semantic aware M2M service layers that are able to parse, interpret or process M2M data on behalf of applications. In current M2M systems, M2M service layers lack semantic awareness capabilities and hence data flowing through or stored within M2M service layers is treated as opaque information.
This lack of semantic awareness prevents M2M service layers from offering services which allow data produced by M2M applications to be effectively abstracted or virtualized by the M2M service layer such that it can be discovered, accessed, interpreted, and shared by different applications even if they do not have any prior knowledge of the application from which the data originated. As a result, the physical entities that are sensed and acted upon (e.g., appliances, people, cars, rooms of a building, etc.) may not be effectively virtualized/abstracted by M2M service layers and the physical entities are treated as generic entities, intrinsic to the environment, and not tied to a specific M2M application. In order to overcome this limitation, the data transmitted in M2M systems may be associated and integrated with semantic information, such that semantic aware M2M service layers can have the same knowledge of the data as M2M applications. In doing so, M2M service layers can better facilitate the sharing of data across applications and provide value-added semantic aware services to M2M applications (e.g., data aggregation, data sharing amongst different applications, etc.).
For example, in a patient monitoring application illustrated in
Semantics nodes may provide the following functionalities in an M2M system to support M2M service layer semantic awareness and data abstraction: (i) support for storing semantics information, and/or support for interfaces to servers storing semantics information; (ii) support for mechanisms for creating, retrieving, updating, and deleting semantics information; (iii) support for mechanisms for semantics information updates to local and remote resources; (iv) support for associating/linking semantics information with corresponding resources which may be stored either locally or remotely; and (v) capabilities to publish and discover semantics descriptions.
As described herein, a semantics node is a logical entity that may be hosted on a stand-alone computing device (e.g., server) in the network or hosted on an existing entity within the network, such as an M2M gateway, M2M device, M2M server, or the like. A semantics node may be seen as a repository that describes data. For example, a sensor device for blood pressure may want to understand how to describe its data, so it queries a nearby semantics node to find out if there is a blood pressure class already defined. If so, the semantics node responds to the sensor device with the blood pressure class it found locally. If not, the semantics node may query other semantics nodes (e.g., siblings or parents). The use of a semantics node may reduce the need to have end devices store descriptions of data.
A semantics node stores and manages semantics related resources. Semantics related resources usually describe other resources, such as, for example, the ETSI M2M resources that are stored under the resource tree, <SCL>, <application>, <container>, <contentInstance>, which need to have semantics related resources associated with them in order to enable an understanding of their semantics. In one embodiment, semantics related resources may have one of three types: class, relationship, and term. This categorization provides compatibility with current techniques of the semantics web and enables an M2M system to leverage existing semantics related resources.
As discussed herein, semantics nodes may be deployed in an M2M system in different levels, such as a M2M area network, a M2M access network, and a M2M core network, such that the different levels form into a hierarchical structure. Semantics nodes in the same level may be distributed and have a sibling relationship. Mechanisms are disclosed with regard to building and maintaining such a hybrid architecture of semantics nodes, which provides the benefits of different levels of abstraction and compatibility to an existing network hierarchy.
Efficient semantics related resource publishing schemes are disclosed to enable and facilitate the semantics related resource discovery and sharing. A semantic node may inform its siblings and children when semantics related resources are created, updated, or deleted by publishing or un-publishing the semantics related resources. A semantics node stores semantics related resources in its local databases or directories. These directories are exchanged such that other semantics nodes know which semantics related resources are stored and can be shared in the network. Other entities are able to discover the semantics related resources from a semantics node, which does not need to flood the request to the siblings or forward the request to the parent even if there is no matching resources in its local directories, instead it can search the published information from other semantics nodes. The semantics related resource publishing schemes, which are discussed in more detail below, may include publishing of semantics related resource identifier keywords, publishing of a semantics node digest, and publishing of hybrid identifier and digest publishing.
Disclosed below is the use of an identifier of the semantics related resource that includes keywords to notify neighboring semantic nodes (e.g., siblings, children, or non-related semantics nodes) of the semantics node that stores the semantics related resource. The semantics related resources stored and managed by a semantics node have a unique identifier, which may be a universal resource locator (URL) or a universal resource identifier (URI). In order to inform other semantics nodes of the semantics related resources stored in a semantics node, the existence of the semantics related resources may be published using keywords. The publishing may be triggered automatically based on reaching a threshold number of newly created semantics related resources (or identifiers) or after reaching a certain time threshold, among other ways. The existence of a semantics related resource on a semantics node may be published by using the identifier of the semantics related resource, the content of the semantics related resource, or the identifier and content of the semantics related resource.
With continued reference to
With reference to
A keyword may match to multiple semantics related resources with the same type, but with additional separate key words, which may differentiate the semantics related resources. For example, the class temperatureReading may have the keyword of temp, the class temperatureInC may have the keywords of temperature and Celsius, and the class temperatureInF may have the keywords of temperature and Fahrenheit. A keyword may match multiple semantics related resources with different types. For example, a relationship type hasCoreTemperature may be chosen with the keyword of temperature and the term type Celsius may be chosen with the keyword of temperature, as well. The host semantic node may select the keywords.
In addition, since a semantics node address for a publishing semantics node is the same for the semantics related resources published by it, identifiers in a sent publishing message may just have the type and keywords included and no host address (e.g., type1.keyword1). A semantics node that receives the publishing message may add the host address to its tables of the received identifiers based on IP or MAC layer information when no host address is included in the identifier (e.g., host1.type1.keyword1).
With continued reference to
With continued reference to
Table 3 and Table 4 show the overhead to the network, source semantics node, and sibling/parent semantics node that is incurred from semantics related resource identifier publishing and semantics related resource discovery, respectively. From Table 3 and Table 4, it can be observed that the network bandwidth is mainly used in transporting the publishing messages of separate/accumulated identifiers; the discovery process does not cause extra overhead between source/requested semantics node and its siblings/parent. The source/requested semantics node can search its locally maintained semantics related resource directories hosted by its own and the published resources, and return the matched identifiers directly.
Disclosed below is a semantics node digest mechanism that publishes stored semantics related resources in a semantics node, which, compared to whole identifier publishing to the network, may reduce the network overhead. The semantics digest may use a Bloom filter such that the storage to publish a semantics related resource may be as small as one bit. Bloom filters are compact data structures for probabilistic representation of a set in order to support membership queries (i.e., queries that ask: “Is element X in set Y?”). Although Bloom filters allow for compact representation, the tradeoff is a small rate of false positives in membership queries; that is, queries might incorrectly recognize an element as a member of the set.
A Bloom filter is defined by parameters K and N. There may be K independent hash functions and an array of M bits. The bits of a Bloom filter are used to encode a collection of N keywords (the max number of items that will be put in the filter). A published semantics node digest includes a collection of the keywords of the semantics related resources stored in a semantics node.
Below is an example of how the Bloom filter may be utilized using the semantics related resource identifiers of Table 1. K, the number of hash functions, may be 3, in this example. If K is 3, then there will be 3 hashing functions (e.g., f(x), g(x), and h(x)) that will be used on the keywords of the four semantics related resource identifiers of Table 1. Each hashing function may generate a hash value for each identifier. Each hash value represents a bit in the Bloom filter that should be turned on. M is the number of bits in the array of the Bloom filter. M should be less than the hash function range; otherwise, some bits may not be turned on. For this example, M is 16. N is the number of keywords. In our example, N is the maximum number of total keywords for all identifiers. M, K, and N may be determined based on a user preference or automatically determined by semantics node 723. The probability of false positives may be determined by Equation (1). The optimal size of the array (M) and the optimal number of hash functions (K) may be determined based on Equation 2 and Equation 3, respectively.
So, in our example, the keyword “temperature” and other keywords of Table 1 will be processed through the hash functions and have three results, as shown in Table 5. The results of the hash functions (e.g., f(x), g(x), h(x)) are positions that are turned on based on the results of the keywords passing through each hash function. As a result, a 16 bit Bloom filter will look like the following: 01101111 11001111. Bits 5, 6, 13, and 15 are off, so they remain zero.
If a threshold amount has been reached, at step 773, semantics node 723 may compile all keywords for all the semantics related resources to be published. At step 774, semantics node 723 may determine K and M based on Equation 1, Equation 2, or Equation 3. At step 775, semantics node 723 uses hash functions on all keywords. At step 776, a modulus operator may be applied to the hash function values of step 775, if a hash value is larger than M. Applying the modulus keeps the hash values within range of M. At step 777, semantics node 723 turns on the bits in the corresponding positions based on the results of step 775 or step 776 to create a digest message. The digest message may include the Bloom filter, a host address, as well as the class associated with the keywords that were processed in step 775.
With continued reference to
Un-publishing may be done in a similar manner as illustrated in
Table 6 and Table 7 show the overhead to the network, source semantics node, and sibling/parent semantics node, which may be incurred from semantics node digest publishing and semantics related resource discovery using a digest, respectively. The bandwidth used in the transport of the digest message (Bloom filter) may be significantly smaller than the semantics discovery identifier publishing message of
Discussed below is a RESTful embodiment of a semantics node digest in the context of
The filters 801 (i.e., Bloom filters) resource structure as shown in
The hashFunctions resource 805 stores the K hash functions used to generate the Bloom filter. Semantics node 724 also stores the semantics node digest 811 and semantics node digest 815, as shown in
With the semantics node digest stored in a RESTful way, it may be proactively retrieved by other hosts other than just being published to siblings and children. For example as shown in
Discussed below is a hybrid approach that may be used to take advantage of the digest and identifier message publishing (or unpublishing). The digest publishing may be used to reduce inter-level traffic. For example, semantics node 723 may just publish identifiers to sibling semantics nodes (e.g., see
Discussed below is an embodiment of semantics related resource publishing and discovery in a CoRE link format and CoRE resource directory (RD). The discovery of resources hosted by a constrained server is significant in M2M applications where there are no humans in the loop and static interfaces result in fragility. The discovery of resources provided by an HTTP Web Server is typically called Web Discovery and the description of relations between resources is called Web Linking (see RFC 5988). A significant function of such a discovery mechanism is to provide Universal Resource Identifiers (URIs, called links) for the resources hosted by the server, complemented by attributes about those resources and possible further link relations.
In constrained RESTful environments (CoRE), this collection of links is carried as a resource of its own (as opposed to HTTP headers delivered with a specific resource). The Core Link Format defined by IETF (e.g., RFC 6690) specifies a link format for use in CoRE Resource Discovery by extending the HTTP Link Header format (e.g., RFC 5988) to describe these link descriptions. The CoRE Link Format is carried as a payload and is assigned an Internet media type. A well-known relative URI “/.well-known/core” is defined as a default entry-point for requesting the list of links about resources hosted by a server, and thus performing CoRE Resource Discovery. The CoRE Link Format extends the HTTP Link Header field specified in RFC 5988.
In an embodiment, the proposed identifier for semantics related resources may leverage the web linking or CoRE link format introduced herein. A new CoRE link attribute called ‘kw’ may be defined. The resource type ‘kw’ attribute is used to associate the keyword(s) to a semantics related resource. As a result, the existing identifiers (e.g. URI/URL) to address the semantics related resources may be reused, but by adding the ‘kw’ attribute to the web linking or CoRE link format, the semantics related resources are published and maintained with keywords associated with them. The semantics related resource discovery can benefit from knowing the keywords of the semantics related resource, which is discussed in more detail herein.
CoRE Resource Directory specifies the web interfaces that a Resource Directory (RD) supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with a Resource Directory are defined.
A RD is used as a repository for Web Links about resources hosted on other web servers, which are called endpoints (EP). The RD implements a set of REST interfaces for endpoints to register and maintain sets of Web Links (called resource directory entries), for the RD to validate entries, and for clients to lookup resources from the RD. Endpoints themselves can also act as clients.
Resource discovery may be performed by sending either a multicast or unicast GET request to /.well-known/core and including a Resource Type (rt) parameter with the value “core.rd” in the query string. Resource publishing may be performed by resource registration. A POST from an endpoint contains the list of resources to be added to the directory as the message payload in the CoRE Link Format along with query string parameters indicating the name of the endpoint, its domain and the lifetime of the registration.
A semantics node may regard its siblings and children node as RDs, where it may publish its semantics related resources. To enable this, the semantics node may send a POST to an RD (its siblings and children). Discussed herein are the CoRE link format methods for publishing of semantics related resource identifier, publishing of semantics node digest, and hybrid identifier and digest publishing. In order to support all the three semantics related resource publishing, one URI template variable called a publishing method (pm) may be added to the CoRE RD resource registration request interface. The pm may be set to a particular value (e.g., 0, 1, or 2) to indicate the different publishing or digest methods. The hybrid approach is adopted when the pm is set up differently when RD is sibling or child (pm=identifier when RD is a sibling, pm=digest when RD is a child). The pm may be extensible for other publishing methods.
Above are multiple techniques for publishing and discovery of semantics related resources. Although the target of semantics related resource publishing and discovery are illustrated as siblings and children, the semantics node may choose other semantics nodes for publishing and discovery that may not have such relationships. The types of semantics related resources that are defined herein, such as class, relationship, and term, t should not be limited to the aforementioned types.
Disclosed above are mechanisms with regard to building and maintaining semantics publishing and discovery. Below are more details with regard to semantics node architecture. The semantics concept is commonly known in the area of Semantics Web, which is a collaborative movement led by the international standards body known as the World Wide Web Consortium (W3C). The standard promotes common data formats on the World Wide Web. By encouraging the inclusion of semantic content in web pages, the Semantic Web aims at converting the current web dominated by unstructured and semi-structured documents into a “web of data.” The Semantic Web stack builds on the W3C'"'"'s Resource Description Framework (RDF).
In various embodiments, the following functionalities may be enabled on a semantics node: (i) semantics related resources managed by the semantics node are capable of being discovered, retrieved, and validated; (ii) semantics nodes may be discovered by other nodes and semantics related resources may also be discovered with subscription mechanisms; (iii) semantics related resources may be linked and associated with resources in the M2M system such that the semantics related resources are provided with semantics information and universally understood; (iv) semantics related resources may be pushed to other semantics nodes in the hierarchy for the purpose of efficient discovery and easy access; (v) semantics related resource association and linking may be optimized based on the semantics similarity and grouping of semantics related resources being described; and (vi) semantics related resources may be moved from one semantics node to another semantics node, along with the data movement.
In one embodiment described hereinafter, the semantics node is implemented in the service capability layers (xSCLs) of the ETSI M2M/oneM2M architecture. In another embodiment, the semantics node is implemented in a service capability server (SCS) of the 3GPP Machine Type Communication (MTC) architecture.
As further shown, a network domain, such as network domain 122, may further comprise one or more devices, such as device 145 (which for example may be one of the M2M devices used in the patient monitoring application of
Still referring to
Typically, the device 145, gateway 140, and M2M server platform 125 comprise computing devices, such as the devices illustrated in
As further shown in
I. M2M Architecture with Semantics Nodes
One embodiment of a M2M system that includes semantics nodes is illustrated in
As shown in system 150, application 158 may be communicatively connected with M2M semantics node 160 located in area network 157 via reference point sIc 159. The sIc reference point is generally used by applications, other non-semantics node entities in the area network, access network, and core network entities to talk to a semantics node. M2M semantics node 160 is communicatively connected with external semantics node 163 via reference point sIe 162. The semantics nodes in M2M systems may interface with external semantics nodes via the sIe reference point. The external semantics nodes may manage other existing semantics related resources such as those defined by RDFS for the semantics web. M2M semantics node 160 is also communicatively connected with M2M semantics node 164 located in access network 153 via sIs reference point 161. M2M semantics node 164 is communicatively connected with M2M gateway 165 via sIc reference point 166 and communicatively connected with M2M semantics node 168 located in core network 151 via reference point sIs. In this embodiment, the M2M Gateway 165 itself is not a semantics node, but in other embodiments, the M2M Gateway 165 could incorporate the functionality of semantics node.
Semantics node(s) may be deployed at the area level for the purpose of offloading, load balancing, easy access, etc. At the area level, it is possible that there is no semantics node deployed if all the devices in the local area network communicate with a semantics node in the attached access or core networks. A semantics node at the area level may have a corresponding parent semantics node at the access level (e.g., M2M semantics node 160 connected with M2M semantics node 164) or at the core level (e.g., M2M semantics node 169 connected with M2M server 170 that includes a semantics node). Semantics nodes talk to each other through the sIs reference point. The details of the reference points are defined further hereinafter. A semantics node at the access level may also have a parent at the core level, which it communicates with over the sIs reference point. Likewise, a semantics node at the access level may have children semantics nodes at the area level, which it communicates with via the sIs reference point. Semantics nodes at the core level may also have children semantics nodes at the access or area level.
In addition to the parent-child relationships illustrated in
For a constrained device, due to the limit of capacity, the semantics can be a code referring to a specific semantic or a link pointing to the semantics stored in a remote semantics node. Such semantic information may be provided by the application that created the data or by the service layer.
At the access level, there might be one or more semantics nodes deployed in one access network. If so, the siblings may communicate with each other for semantics information notification, broadcast and discovery through the sIs reference point. A semantics node at the access level may also have a parent at the core level which it communicates with over the sIs reference point. Likewise, a semantics node at the access level may have children semantic nodes at the area level which it communicates with via the sIs reference point.
At the core level, there might be one or more semantics nodes deployed in the core network. These nodes may be siblings and communicate with each other over sIs reference point for sharing semantics information using notification, broadcast and discovery. Semantics nodes at the core level may also have children semantic nodes at the access or area level. Applications, other non-semantics-node entities in the area network, access network and core network talk to a semantics node via the sIc reference point.
As mentioned above, a semantics node may be a standalone physical node in a network (e.g., standalone M2M semantics node 160) or it can be a logical entity hosted on another physical node in the network, such as an M2M device 171, M2M gateway 172, or M2M server 170, as shown in system 150 of
A feature of the multi-layer semantics node hierarchy illustrated in
II. Semantics Node Architecture
More details regarding the architecture of a semantics node will now be discussed. As mentioned, a semantics node stores and manages semantics related resources. As defined herein, a semantics related resource comprises information that can be used to describe the semantics information of a thing, such as the meaning of data generated by an M2M device or application or the M2M device or application itself. In one embodiment, semantics related resources may be expressed in extensible markup language (XML) using existing schemas, such as XML Schema Definition (XSD), RDF Schema/Web Ontology Language (RDFS/OWL), or the like. In an embodiment, three types of semantics related resources may be stored in a semantics node—classes, relationships, and terms—each of which is described more fully below. The categorization of semantics related resources in this manner provides compatibility with the current techniques of the semantics web. This compatibility enables an M2M system to leverage existing semantics related resources, such as for example those core classes and core properties defined by W3C. Applications and entities external to the M2M system are able to use the semantics related resources hosted by the semantics node, without incurring any extra overhead due to format conversion or modification necessary to make the semantics compatible.
Discussed herein is the concept of classes of objects/things in an M2M domain. In the example health monitoring system of
Here, the class contains the fields “description,” “unit,” and “base,” and the information in those fields is “temperature in Celsius,” “Celsius,” and “integer,” respectfully. As another example, a BloodPressure class may contain two fields, one for systolic pressure and another for diastolic pressure. The class description for this BloodPressure class would include both fields'"'"' descriptions and may be expressed using XML/XSD as follows:
Again, however, it is understood that classes (and the other types of semantic related resources—relationships and terms) are not limited to expression using XML/XSD but rather may be expressed in any of a variety of suitable description languages, including, for example, RDFS/OWL and the like. Classes may also be related to each other. For example, “blood pressure” may be a subclass of “vitals”, or equivalently, “vitals” may be a superclass of “blood pressure.” The subclass/superclass relationships define a hierarchy of classes. In general, A is a subclass of B if every instance of A is also an instance of B. A class may have multiple super classes.
Relationships are a special kind of semantics related resource. Relationships describe relations between semantics related resources, for example “created by,” “lifetime,” “subscribed by,” and so on. A relationship can also be identified by a URI/URL, which gives a global and unique naming scheme to relationships of the M2M domain. Classes and inheritance are known in other fields of computing, for example in object-oriented programming But while there are similarities, differences exist too. In object-oriented programming, an object class defines the relationships or properties that apply to it. To add new relationships or properties to a class means to modify the class. However, here, relationships are defined globally, that is, they are not encapsulated as attributes in class definitions. A new relationship may be defined that applies to an existing class without changing the definition of the class itself. Like classes, the relationships can also be related to each other. For example, “energy mode” and “usage mode” are sub-relationships of “mode”. If a device has an “energy mode” of electric and a “usage mode” of manual, then it has a “mode” of electric and manual.
Terms are concepts that are commonly used in an M2M domain. As defined herein, a term is a value that may be used by many parties to describe the semantics of a resource. The definition of a term may be universally acknowledged in certain domains where it is published. For example, manual, user-directed, and autonomous are each examples of terms that may be used to describe, for example, an appliance'"'"'s usage mode. In general, the creator of a semantics related resource will determine whether that semantics related resource is a class, relationship, or term. A semantics node will then store the semantics related resources under the categories defined or determined by their creator. For example, in the patient monitoring example of
The semantics of a resource (including data, thing, etc.) can be described by a resource-relationship-value triple, consisting of a resource, a relationship and a value. Values can either be classes, terms, or other resources. The following are some examples,
- A content instance (resource) hasType (relationship) temperatureReading (class)
- An appliance (resource) hasUsageMode (relationship) user-directed (term)
- A content instance (resource) generatedBySameApplicationAs (relationship) another content instance (resource)
Through the proposed sIc, sIs and sIe reference points, requests to a semantics node'"'"'s class, relationship and term resources can be made.
III. M2M Semantics Node Functions and Reference Points
In this section, further details concerning the functions and reference points of a semantics node are provided. In one embodiment, a semantics node may perform the following functions: authenticating other semantics nodes including authenticating lower level children or parallel sibling semantics nodes in a semantic node hierarchy to allow them to register and make requests for a semantic node'"'"'s resources; authenticating applications, devices, and/or users to allow them to publish, create, delete, update, and retrieve semantics related classes, relationships and terms resources; storing and managing semantics related classes, relationships and terms resources; providing support for discovery of semantics related resources; and providing support for semantics nodes to communicate with one another (between parent-child, siblings) in order to collaborate on discovery queries and share semantics related resource information.
A semantics node may communicate with other entities in the network via one or more reference points or interfaces. In one embodiment, three reference points are defined—an sIs reference point, an sIc reference point, and sIe reference point. The sIs reference point is used for communication between semantics nodes. The sIs reference point may also be used by a semantics node to register to another semantics node to form parent-child or sibling relationships, to discover other semantics nodes, to notify others about its status (e.g., online, offline, overloaded, etc.), to trigger another semantics node to perform a particular operation (e.g., de-registration, registration), to publish, create, delete, update, and retrieve semantics related resources in another semantics node. In addition, a semantics node may use the sIs reference point to subscribe to semantics related resources in another semantics node and to receive corresponding notifications, to discover semantics related resources on the siblings and parent semantic nodes in its hierarchy, to move a group of semantics related resources from one semantics node to another semantics node, and to allow the semantics related resources stored in another semantics node to be linked and associated with a resource to provide the semantics to that resource, as described further below in connection with
In the present embodiment, the sIc reference point may be used by an application or non-semantics node to communicate with a semantics node from various network domains (e.g., area network, access network, or core network). The sIc reference point also allows an application or non-semantics node to publish, create, delete, update, retrieve, subscribe to, or discover semantics related resources in a semantics node and to receive notifications from the semantics node. In addition, the sIc reference point allows the semantics related resources stored in a semantics node to be linked and associated with a resource to provide the semantics to that resource.
The sIe reference point may be used for communication between a semantics node that is part of an existing hierarchy of nodes in an M2M system and an external semantics node. An external semantics node stores semantics-related resources outside of the M2M domain. One example of an external semantics node may be a server that stores the semantics-related resources for Semantic Sensor Network Ontology that is defined by the W2C Semantic Sensor Network Incubator Group, as described at http://www.w3.org/2005/Incubator/ssn. The sIe reference point allows a semantics node to retrieve, discover, and subscribe to semantics related resources in an external semantics node and vice versa. Also via the sIe reference point, external semantics nodes may discover semantics nodes in the M2M system and receive notifications.
One embodiment of the messages associated with the sIs, sIe, and sIc reference points, which effectively define those reference points, are set forth below in Table 8.
Table 8 lists semantics node related messages, there corresponding meanings, and reference points used.
Protocols such as hypertext transfer protocol (HTTP) or constrained application protocol (CoAP) may be used as an underlying transport protocol for carrying the different types of messages. Examples are presented below of the use of these messages to perform the various semantic node functionalities discussed above
IV. M2M Semantics Node Procedures
A. Build Semantics Node Hierarchy
In this section, additional details are provided regarding how a hierarchy of semantics nodes (hereinafter “semantics node hierarchy”) may be built, in accordance with one embodiment. In this embodiment, a semantics node hierarchy is built up by determining the parent-child and sibling relations between the semantics nodes located at the different area, access, and core levels in a network.
The discovery of sibling semantics nodes may be based on sending out semantics node discovery requests (e.g., multicast, broadcast, anycast) where a discovery request can be issued in an attempt to discover sibling semantics nodes. The request can have a defined hop-limit that limits the flooding of discovery request and response messages, which may congest the network. Alternatively, the discovery can leverage existing discovery mechanisms available within the network, such as domain name system (DNS), DNS service discovery (DNS-SD), service location protocol (SLP), etc., if available. A semantics node may store the returned information of the neighboring sibling semantics nodes, such as IP address or type(s) of semantics information managed. As discussed further below, the sibling semantics node discovery response message may also piggyback the address of a higher-level semantics node discovery server, the address of a parent semantics node of the sibling, or both.
Referring still to
In the present embodiment, at each level, there may be one semantics node discovery server, which accepts a higher-level semantics node discovery request by default. The address of the semantics node discovery server may be well known to the lower level semantics nodes. As shown in
If the new semantics node is provisioned with the upper level semantics node discovery server'"'"'s address, it can perform the semantics node discovery directly (control passes from step 604 to step 614). Otherwise, it decides whether it wants to choose from the siblings'"'"' parent list and whether it wants to retrieve the default semantics node discovery server'"'"'s address from siblings (steps 608 and 610). If the new semantics node chooses an upper-level semantics node from the siblings'"'"' parents (step 618), it may choose not to perform the semantics node discovery further. Otherwise, it decides the criteria of choosing the parent (nearest in hop count, supporting the same type(s) of semantics related resources, etc.) (step 614). Based on the criteria, it sets up the information it wants to discover in addition to the semantics nodes'"'"' addresses in the upper level (distance, supported type(s) of semantics related resources, etc.) (step 616).
At step 620, the new semantic node may register to the higher level parent semantics node it discovered or otherwise selected. If the new semantic node is unable neither to learn the address of a higher-level semantic node discovery server nor to identify any higher-level parent semantic nodes of its siblings to which it might register, it may determine that no higher level parent semantic nodes are available and end the process at step 612.
Referring back to
Semantics node discovery server 183 may be considered a centralized point for storing information of the semantics nodes scattered in the same level or a rendezvous point to flood the discovery request in the same level of a network and collect the returned responses of semantics nodes. Semantics node discovery server 183 may be a server that resides in a network at a higher, same, or lower level network level than the network level of new semantics node 181. This example assumes that semantics node discovery server 183 is in an upper level in relation to the network level of new semantics node 181. The address of the semantics node discovery server 183 can be well known to lower level semantics nodes (e.g., sibling semantics node 182). If new semantics node 181 is not provisioned with semantics node discovery server 183, then new semantics node 181 may perform sibling semantics node discovery. If new semantics node 181 is provisioned with the address of the semantics node discovery server 183, it can perform the semantics node discovery directly.
At step 186 of
At step 187, new semantics node 181 extracts the received address of semantics node discovery server 183. At step 188, new semantics node 181 sends a semantics node discovery request to semantics node discovery server 183. The request at step 188 may be a query for one or more parent semantics nodes that new semantics node 181 may connect with. At step 189, semantics node discovery server 183 sends a semantics node discovery response to new semantics node 181. The response at step 189 may contain one or more parent semantics nodes. At step 190, new semantics node 181 chooses one parent semantics node to register with. At step 191, semantics node 181 sends a request for registration with its chosen parent semantics node 184. At step 192, parent semantics node 184 sends a response to the request for registration at step 191.
Generally, if new semantics node 181 is provisioned with the address of semantics node discovery server 183, it can perform the semantics node discovery directly. Otherwise new semantics node 181 decides whether it wants to choose from the list of parent semantics node received from one or more siblings and whether it wants to retrieve the default address of semantics node discovery server 183 from siblings. At each level, there may be one or more semantics node discovery servers, which accepts the higher-level semantics node discovery request by default. If new semantics node 181 chooses an upper-level semantics node from the siblings'"'"' parents, new semantics node 181 may choose not to perform the semantics node discovery further. New semantics node 181 may have the option to decide the criteria of choosing the parent (e.g., choosing from options, such as nearest in hop count, supporting the same type(s) of semantics related resources, etc.). Based on the criteria, new semantics node 181 sets up the information it wants to discover in addition to the addresses of semantics nodes in the upper level (e.g., distance, supported type(s) of semantics related resources, etc.).
At step 206, semantics node 201 sends a de-register request to current parent semantics node 203, which includes a request to end the parent-child relationship. At step 207, semantics node 201 may receive a response to the de-register request sent in step 206 from current parent semantics node 203 or another device that is able to communicate a perceived status of current parent semantics node 203. Similar to the steps illustrated with regard to
In an embodiment (not shown, but with reference to elements in
Generally, parent-child relationships of semantics nodes are terminated by de-registering to the current parent semantics node when the child semantics node goes offline or when the child semantics node registers to another higher level parent semantics node.
If a neighboring sibling semantics node joins a network, the corresponding sibling information is updated by adding the new semantics node. If a neighboring sibling semantics node leaves a network, the corresponding sibling information is updated by deleting the semantics node or otherwise updating a table to indicate the status of the sibling semantics node that left the network (e.g., status=offline). A semantics node may broadcast or otherwise communicate its status to sibling semantics nodes using, for example, the SEMANTICS_NODE_STATUS_NOTIFY( ) message shown above in Table 8. The status update may affect how a sibling and parent-child relationships are maintained.
B. Semantics Related Resource Discovery, Retrieval, and Validation
An application, a device, a user, a peer semantics node, an external semantics node, or a non-semantics node may send semantics related resource discovery requests to a semantics node through the sIc, sIs, and sIe reference points. The discovery request message may include the type of the semantics related resource (class, relationship, or term) and search string(s). For example, assume a temperature sensing application (App1) in an M2M system that needs to report its temperature reading data—as an integer in units of Celsius—to its M2M gateway. In order to enable the gateway service capability layer (GSCL) to understand the data, App1 needs to associate the data with proper semantics information. In accordance with the procedures described herein, App1 may discover a semantic node that stores a semantic related resource class—the temperatureReading class—that represents temperature data as an integer in units of Celsius. After discovery, App1 will retrieve the representation of the temperatureReading class, and validate that it is the one it wants to use to provide semantics for its temperature data. It will then link the data with the temperatureReading class as one of its attributes (semantics attribute). In the GSCL, the data may be stored under a <tempData> container for App1, which will have a semantics attribute that links to the temperatureReading class using a hasType relationship—as illustrated for example in
If there is not a matching semantics related resource found locally, the semantics node will try to find a matching semantics related resource from its sibling semantics nodes. As indicated by block 226 and block 227, the semantics node forwards the discovery request to the siblings and sets up a time window it will wait for the response to come back. At block 228, it is determined whether a matching semantics related resource is found from the contacted siblings. If matching semantics related resources are returned from its siblings, the corresponding address (e.g., URI/URL) of the semantics related resource(s) is sent back to the issuer with a successful discovery response (block 225).
If there are no matching semantics related resources returned from siblings of the semantics node, then it is determined whether a parent semantics node can be contacted, as indicated by block 229. If there is no parent semantics node, then a discovery response indicating a negative outcome will be returned to the issuer (block 233). If there is a parent semantics node, the semantics node will try to find a matching semantics related resource from its parent semantics nodes. As indicated by block 230 and block 231, respectively, the semantics node forwards the discovery request to the parent semantics node and sets up a time window it will wait for the response to come back. At block 232, it is determined if a matching semantics related resource is found from the contacted parent. If matching semantics related resources are returned from the contacted parent, the corresponding address (e.g., URI/URL) of the semantics related resources is sent back to the issuer with a successful discovery response (block 225). If there are no matching semantics related resources returned from the parent of the semantics node, then a discovery response indicating a negative outcome will be returned to the issuer (block 233).
After the issuer receives a successful discovery response, which contains the address (e.g. URL/URI) of the matching semantics related resource, the issuer can retrieve the representation of the semantics related resource.
In one embodiment, the semantics node may support a RESTful architecture style (representational state transfer), which consist of clients and servers. Clients (e.g., Issuers) initiate semantic requests to servers (e.g., semantics nodes). In this embodiment, servers (e.g., semantics nodes) process requests for semantics and return appropriate semantic responses. Requests and responses are built around the transfer of representations of semantics related resources. A client can be an application, a user, a device, a semantics node, etc., which can request RESTful operations on the semantics related resources (e.g., classes, relationships, or terms) to a semantics node.
When handling resources in a RESTful architecture, there are four basic methods that may be applied to the semantic related resources:
- CREATE: Create a class, relationship, or term resource.
- RETRIEVE: Read the content of a class, relationship, or term resource.
- UPDATE: Write the content of a class, relationship, or term resource.
- DELETE: Delete a class, relationship, or term resource.
A semantics node acting as a RESTful server may validate a received request. The operation is allowed, if the issuer is authorized with the proper access rights.
At step 244, semantics node 242 acts as a server and validates and otherwise processes the received request. The received request is allowed, if issuer 241 is authorized with the proper access rights. If the create operation is allowed by the semantics node 242, the new semantics related resource is created under the proper resource pool based on whether it is a class, relationship, or term. And the semantics related resource is assigned a unique identity or address by semantics node 242. If the update operation is allowed by semantics node 242, the representation of the semantics related resource is updated. If the retrieve operation is allowed by semantics node 242, the representation of the semantics related resource is prepared in the format issuer 241 requests. If the delete operation is allowed by semantics node 242, the requested semantics related resource is deleted.
At step 245, semantics node 242 returns a response to issuer 241. For a create operation, the identity or address of the newly created semantics related resource is returned to the issuer. For an update operation, a response code is returned to issuer 241 whether the operation is successful or not. For a retrieve operation, the representation of the semantics related resource in a format issuer 241 requests are returned to issuer 241. For a delete operation, a response code is returned to issuer 241 to indicate whether the operation is successful or not.
At step 257, semantics node 252 then sends a semantics related resource discovery response back to the Issuer 251, which includes the address (e.g., URI/URL) of the semantics related resource(s) from the parent semantics node 254 that matched the Issuer'"'"'s request. At step 259, issuer 251 sends a semantics related resource retrieve request based on the received URL. At step 260, parent semantics node 254 sends a semantics related resource retrieve response that contains the requested semantics information which may include a class, relationship, or term.
At step 261, issuer 251 checks (validates) the representation of the received semantics information from step 260. There is a possibility that the received semantics related resource sent at step 260 is not exactly what issuer 251 wants. For example, if issuer 251 requested a temperature class and the returned matching resource is a class called temperatureReading with an associated unit of Fahrenheit, but issuer 251 desires a temperature class with unit of Celsius, then issuer 251 can request that parent semantics node 254 modify the semantics. This can be supported by sending a semantics related resource modify request at step 262 to parent semantics node 254 to modify the semantics related resource. At step 263, the address (e.g., URL/URI) of the newly added or modified semantics related resource will be returned to issuer 251.
With reference to modification of semantics related resources, generally, the semantics node may collaborate with its siblings or parent to perform the modification, if the semantics node does not support modification itself. If the semantics node supports modification, then the semantics node may modify the class locally by adding a new class or extending the current one.
C. Subscribing to Semantics Related Resources
In one embodiment, a semantics node can support a client (e.g., an application, another semantics node, a device, a user, or the like) subscribing to it. As one example, a client may subscribe to the semantic node to be notified when any update to a subscribed semantic related resource. When an update occurs, the subscribing client will be notified with the new representation of the resource. In the case of a client that is a semantic node itself, the subscribed semantics related resource might be stored in another semantics node that the subscriber semantics node has no relation with (e.g., not a parent-child or sibling). In this example, a client may issue a SEMANTICS_RESOURCE_SUBSCRIBE_REQ message to a semantics node. The message identifies the semantics related resource for which the client wishes to receive notifications when the resource is updated. The semantics node will respond to the request with a SEMANTICS_RESOURCE_SUBSCRIBE_RESP message acknowledging the subscription. When the semantics related resource to which the client has subscribed is updated, the semantics node will send a SEMANTICS_RESOURCE_SUBSCRIBER_NOTIFY message to notify the client of the update.
As another example, a semantics node may be interested in being updated with the semantics related resources stored and managed by one of its sibling, parent, or child semantics nodes.
At step 274, semantics node 271 sends a semantics node resource subscribe request to the target semantics node 272. At step 275, the target semantics node 272 determines whether to accept the semantics subscription request of step 274. to the target semantics node 272 can decide whether to accept a subscription request, based on the existing subscribers, load of handling the subscription (e.g., load with regard to collecting update information or bandwidth used to send a notification), etc. At step 276, the target semantics node 272 sends a semantics node subscription response to semantics node 271. The response at step 276 may include confirmation of the subscription and parameters that will be used in processing the subscription. At step 277, at some point in time after step 276, the target semantics node 272 detects a semantic notification trigger condition that matches the requested trigger received at step 274. At step 278, the target semantics node 272 sends a semantics node resource subscribe notify message to update semantics node 271 with regard to a particular semantics related resource.
Generally, a semantics related resource subscription can facilitate the semantics related resource discovery from a peer semantics node or parent semantics node. For example, based on the notification messages (which would include the URIs of newly created or updated semantics related resources stored on a semantics node), a semantics node may be able to perform discovery on semantics related resources of other nodes without sending discovery requests.
D. Linking and Association to Semantics Related Resources
The semantics related resources of a semantic node can be used in various ways. For example, semantics related resource representations may be retrieved from a semantics node and may be stored in a co-located manner in a network location where the data is stored (e.g., on a network server, on a device, on a gateway, etc.). Alternatively, the semantics of a resource may be stored on a semantic node and a link to the semantics may be co-located and stored along with the data. This semantic link may be stored in-line (i.e., embedded) within the data or may be stored separately (e.g. in a separate resource or attribute) alongside the data. Thus, through this linking to semantics-related resources, semantics can be applied to normal resources in an M2M system (e.g., <SCL>, <application>, <container> etc.). Typically, this linking will be created by the resource creator/generator, when the resources are created.
Continuing with the earlier example of a patient health monitoring application in
- example/health/patient/data1 hasType semanticsNode1/class/patient
- example/health/doctor/data2 hasType semanticsNode1/class/doctor
- example/health/bp/data1 hasType semanticsNode1/class/bloodpressure
- example/health/temp/data1 hasType semanticsNode1/class/temperature
- example/health/hr/data5 hasType semanticsNode1/class/heartrate
The hasType relationship may also be identified by a URL/URI which references a semantic description of the hasType relationship stored on the semantic node.
E. Grouping Optimization
If a group of resources have some similar semantics (e.g., all resources in the same application have the same semantics), the similar semantics may be applied to the application, instead of to each individual resource under that application.
For example, multiple instances of blood pressure monitoring data have the same semantics. Hence each instance may be associated with the same semantics (semanticsNode1/class/bloodpressure) as shown below:
- example/health/bp/data1 hasType semanticsNode1/class/bloodpressure
- example/health/bp/data2 hasType semanticsNode1/class/bloodpressure
- example/health/bp/data3 hasType semanticsNode1/class/bloodpressure
- . . .
By supporting this grouping optimization, the following association may also be valid:
- example/health/bp hasType semanticsNode1/class/bloodpressure
F. Pushing Semantics Related Resources
As mentioned above, the classes, relationships, and terms that are hosted in a semantics node may be discovered and used by others. Based on the frequency of the requests, some of the semantics related resources may be pushed or mirrored in another semantics node for easier discovery and access. For example, after one semantics node detects the same forwarded discovery request from another semantics node a certain number of times (e.g., exceeding a policy defined threshold); it may decide to push a mirrored copy of the semantics related resource to that semantics node.
The semantics related resource pushing can happen between siblings, or between parent and child semantic nodes, as shown in
The following options may be used in order to keep the semantics related resource up-to-date. With reference to
The semantics related resource pushing can happen between siblings, or between a parent and child in either direction. For example, with reference to
G. Data/Semantics Related Resources Movement
At step 317, semantics node discovery requests and responses are exchanged between semantics node 311 and semantics node discovery server 312 in order to build the hierarchy of semantics nodes, as well as sibling relationships. At step 318, semantics node 311 determines the address of semantics node 313. At step 320, a semantics related resource create request message is sent to semantics node 313 in order to copy the semantics related resource (and other data) that is used by device application 314. Semantics node 313 responds with a semantics related resource create response message, which may include an acknowledgement that the semantics related resource and other data has been copied successfully. At step 321, a semantics linkage update request message is sent to device application 314. The message at step 321 may include instructions for device application 314 to retrieve semantics related resources from semantics node 313. At step 322, the semantics linkage update response message may include an acknowledgement that the semantics node linkage is updated. At step 323, device application 314 retrieves semantics related resources in types of class, relationship, and term from semantics node 313.
V. ETSI M2M/oneM2M Embodiments
A. ETSI M2M Architecture with Semantics Node
As mentioned above, the semantic node concept described herein can be used to enhance the ETSI M2M architecture. In one embodiment, one or more semantics node may be located in the access/core network as a stand-alone network entity, which may be referred to as a M2M semantics node as shown in
A semantics node may support a complementary resource structure as used in the service capability layer (xSCL) of the current ETSI M2M Architecture, and this resource structure may be applied to the semantics node described herein, in the manner illustrated in
As shown in
With reference again to
B. xSCL with Semantics Capability
In another embodiment illustrated in
To support the embodiment of
The classes, relationships, and terms collections under the <sclBase> resource 361 may each contain respective instances of semantics related resources hosted on the local SCL. Each instance may contain a semantic representation as well as have other attributes associated with it, such as discovery related information such as tags. These collections of semantic related resources may be accessed by clients having the proper access rights to do so.
C. Use Case Example of ETSI M2M Semantics Implementation
The semantics related resources managed by a semantics node may be associated and linked to resources in the ETSI M2M resource structure, such as <sclBase>, <application>, <container>, <contentInstance>, and the like. The following discussion illustrates how semantics related resources may be used to provide semantics information for a <contentInstance>.
In this example, assume that a temperatureReading class is defined and stored on scl1, and has URI of scl1/classes/temperatureReading. The relationship hasLocation is defined and stored on scl1 as well, and has URI of scl1/relationships/hasLocation. Additionally, the term ‘northeast China’ is defined and stored on scl1 too, and has URI of scl1/terms/northeastChina.
VI. 3GPP MTC Architecture Embodiments
As further mentioned above, the 3GPP MTC architecture may also be enhanced with the semantics support provided by the semantics nodes described herein. As shown in
While the 3GPP and ETSI M2M architectures are described by way of background herein and may be used to illustrate various embodiments described hereinafter, it is understood that implementations of the embodiments described hereinafter may vary while remaining within the scope of the present disclosure. One skilled in the art will also recognize that the disclosed embodiments are not limited to implementations using the 3GPP or ETSI M2M architectures discussed above, but rather may be implemented in other architectures and systems, such as oneM2M, MQTT, W3C semantics web, and other M2M systems and architectures.
As shown in
As shown in
Similar to the illustrated M2M service layer 22, there is the M2M service layer 22′ in the Infrastructure Domain. M2M service layer 22′ provides services for the M2M application 20′ and the underlying communication network 12′ in the infrastructure domain. M2M service layer 22′ also provides services for the M2M gateway devices 14 and M2M terminal devices 18 in the field domain. It will be understood that the M2M service layer 22′ may communicate with any number of M2M applications, M2M gateway devices and M2M terminal devices. The M2M service layer 22′ may interact with a service layer by a different service provider. The M2M service layer 22′ may be implemented by one or more servers, computers, virtual machines (e.g., cloud/compute/storage farms, etc.) or the like.
Referring also to
In some embodiments, M2M applications 20 and 20′ may include desired applications that communicate digests or identifiers for semantics related resources, as discussed herein. The M2M applications 20 and 20′ may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer, running across the devices, gateways, and other servers of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking/geofencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications 20 and 20′.
The semantics related resources publishing and discovery of the present application may be implemented as part of a service layer. The service layer (e.g., NSCL 126) is a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. An M2M entity (e.g., an M2M functional entity such as a device, gateway, or service/platform that may be implemented by a combination of hardware and software) may provide an application or service. Both ETSI M2M and oneM2M use a service layer that may contain the semantics related resources publishing and discovery of the present invention. ETSI M2M'"'"'s service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of Common Service Functions (CSFs) (i.e. service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE), which can be hosted on different types of network nodes (e.g. infrastructure node, middle node, application-specific node). Further, the semantics related resources publishing and discovery of the present application can be implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and/or a resource-oriented architecture (ROA) to access services such as the semantics related resources publishing and discovery of the present application.
The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 32 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the M2M device 30 to operate in a wireless environment. The processor 32 may be coupled to the transceiver 34, which may be coupled to the transmit/receive element 36. While
The transmit/receive element 36 may be configured to transmit signals to, or receive signals from, an M2M service platform 22. For example, in an embodiment, the transmit/receive element 36 may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the transmit/receive element 36 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 36 may be configured to transmit and/or receive any combination of wireless or wired signals.
In addition, although the transmit/receive element 36 is depicted in
The transceiver 34 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 36 and to demodulate the signals that are received by the transmit/receive element 36. As noted above, the M2M device 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the M2M device 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 and/or the removable memory 46. The non-removable memory 44 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the M2M device 30, such as on a server or a home computer. The processor 32 may be configured to control lighting patterns, images, or colors on the display or indicators 42 in response to whether the semantics related resources publishing and discovery (e.g., processing Bloom filters or retrieving semantics related resources) in some of the embodiments described herein are successful or unsuccessful, or otherwise indicate the status of resource propagation processes, such as identifiers and Bloom filters (e.g.,
The processor 32 may receive power from the power source 48, and may be configured to distribute and/or control the power to the other components in the M2M device 30. The power source 48 may be any suitable device for powering the M2M device 30. For example, the power source 48 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
The processor 32 may also be coupled to the GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the M2M device 30. It will be appreciated that the M2M device 30 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
The processor 32 may further be coupled to other peripherals 52, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 52 may include an accelerometer, an e-compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer'"'"'s main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.
Memory devices coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process'"'"'s virtual address space unless memory sharing between the processes has been set up.
In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.
Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.
Further, computing system 90 may contain network adaptor 97 that may be used to connect computing system 90 to an external communications network, such as network 12 of
It is understood that any or all of the systems, methods and processes described herein may be embodied in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium which instructions, when executed by a machine, such as a computer, server, M2M terminal device, M2M gateway device, or the like, perform and/or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described above may be implemented in the form of such computer executable instructions. Computer readable storage media include both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, but such computer readable storage media do not includes signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical medium which can be used to store the desired information and which can be accessed by a computer.
In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.
This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.