12.29 Advanced Semantic Discovery - a network of nodes across IoT Domains
12.29.1 Description
The oneM2M system has implemented basic native discovery capabilities. The use cases specified in clauses 12.29, 12.30, 12.31 and 12.32 lead to potential requirements, which extend the existing requirements of the use case clause 12.9.10 of the present document with a focus on the discovery and query capabilities, introducing a direct relation with the semantic aspects and enabling more sophisticated semantic queries as e.g. a capability in the CSE, that takes routing decisions for forwarding a received Advanced Semantic Discovery Query.
This use case could be considered as either the "use-case zero", or a "parametric use-case" for Advanced Semantic Discovery (ASD) and it can be instantiated in many domain specific cases.
This use case illustrates the needs for an Advanced Semantic Discovery (ASD) within distributed network of CSEs belonging a single Service Provider and across different IoT Service Providers. This distributed scenario is partially faced in the present document in clause 12.9 (Semantics query for device discovery across M2M Service Providers).
It shows the importance of formalizing:
- an Advanced Semantic Discovery Query Language (ASDQL) able to write Advanced Semantic Discovery Query (ASDQ);
- a Semantic Discovery Routing Protocol (SDRP) to route an Advanced Semantic Discovery Query (ASDQ) between different CSEs;
- a Semantic Discovery Agreement (SDA), to state some communication agreements between CSEs;
- a Semantic Query Resolution functionality (SQR) allowing to locally resolve an Advanced Semantic Discovery Query (ASDQ) into some elementary standard oneM2M Semantic Discovery Queries (SDQ).
The concepts included in the present use case is intensively used in the following clauses of the present document, namely:
- 12.30 Advanced_Semantic_Discovery - Semantic_Recommendation in a network of nodes across IoT Domains
- 12.31 Advanced_Semantic_Discovery -Facility_Management_of_a_Supermarket_Chain, and
- 12.32 Advanced_Semantic_Discovery -Healthcare_Network_and_Clinical_Knowledge_Administration.
12.29.2 Source
RDM-2020-0035R03-Semantic_discovery_with_multiple_M2M_SP
Note
informative source refer to ETSI TR 103 714 SmartM2M; Study for oneM2M Discovery and Query use cases and requirement [i.23].
12.29.3 Actors
- 5 Application Entities (AE) X of type T1, Y of type T2, Z of type T3, V of type T4, and W of type T5.
- 2 Middle Node Common Service Entities (MN-CSE) P, and Q.
- A MN-CSE has a local database containing information on their registered AE. The local database includes location information (where each device is presently located), the device type, etc. Let P and Q have some Semantic Discovery Agreement (SDA) with A. Semantic Discovery Agreement (SDA) can be relaxed inside a single Service Provider, see Note 2 of Definition 2.
- 4 Infrastructure Node Common Service Entities (IN-CSE) A, B, C, and D.
- An IN-CSE has a local database containing information on their registered MN-CSEs and AEs. The local database includes location information (where each device is currently located), the device type, etc. Let A, B, C, and D have some Semantic Discovery Agreement (SDA) among each other's.
12.29.4 Pre-conditions
Consider the following topology:
Figure 12.29.4-1 - Pre-condition topology
12.29.5 Triggers
This section presents, informally, three examples of the Advanced Semantic Discovery Query Language (ASDQL). Let AND, OR, NOT be non-terminals and FC be some filter-criteria, and ?T be a meta-variable of type T to be resolved.
Example 1. X:T1 send to MN-CSE P
ASDQ1 = ?T2|FC2 AND ?T3|FC3 AND ?T4|FC4 AND ?T5|FC5
The query can be intuitively read as follows: X is looking for
- some AE of type T2 registered in any CSE satisfying the filter criteria FC2, AND
- some AE of type T3 registered in any CSE satisfying the filter criteria FC3, AND
- some AE of type T4 registered in any CSE satisfying the filter criteria FC4, AND
- some AE of type T5 registered in any CSE satisfying the filter criteria FC5.
Example 2. X:T1 send to MN-CSE P
ASDQ = ?T2|FC2 OR ?T3|FC3 OR ?T4|FC4 OR ?T5|FC5
The query can be intuitively read as follows: X is looking for
- some AE of type T2 registered in any CSE satisfying the filter criteria FC2, OR
- some AE of type T3 registered in any CSE satisfying the filter criteria FC3, OR
- some AE of type T4 registered in any CSE satisfying the filter criteria FC4, OR
- some AE of type T5 registered in any CSE satisfying the filter criteria FC5.
Example 3 . X:T1 send to MN-CSE P
ASDQ = (?T2|FC2 OR ?T3|FC3) AND (?T4|FC4 OR ?T5|FC5)
Example 4 . X:T1 send to MN-CSE P
ASDQ = (?T2|FC2 AND ?T3|FC3) OR (?T4|FC4 AND ?T5|FC5)
Example 5 . X:T1 send to MN-CSE P
ASDQ = (?T2|FC2 AND ?T3|FC3) OR (?T4|FC4 AND (NOT ?T5|FC5))
It is also possible to consider other non-terminals, such as (list not exhaustive):
- ANY = search in all CSE databases;
- CURRENT = search in the CSE local database;
- CUSTOMER[N] = search in the databases of N CUSTOMER CSE;
- PROVIDER[N] = search in the databases of N PROVIDER CSE;
- PEER[N] = search start on the databases of N PEER CSE;
- BETWEEN_TIME[SEC] = search should return in SEC;
- BETWEEN_SPACE[METER] = search should give results in METER;
- OF_BRAND[NAME] = search should give results of brand NAME.
12.29.6 Normal Flow
We present a "trace" of the Semantic Discovery Routing (SDR) generated by Example 1, the other examples can be easily traced following the same logic. This trace is inspired to a semantic discovery routing as described in [i.24] and [i.26] and proceeds as follows:
- X sends an Advanced Semantic Discovery Query (ASDQ1) to P;
- P verifies the integrity of ASDQ1 and forward the Advanced Semantic Discovery Query ASDQ1 to A that starts the Semantic Discovery Routing Protocol (SDPR) into the network of CSE;
-
ASDQ1 is resolved using the Semantic Query Resolution System (SQRS) locally in A into four subqueries, namely ASDQ2, ASDQ3, ASDQ4, and ASDQ5, where:
- ASDQ2 = ?T2|FC2
- ASDQ3 = ?T3|FC3
- ASDQ4 = ?T4|FC4
-
ASDQ5 = ?T5|FC5
-
A starts lookup in its local database, trying to solve {ASDQ2,3,4,5} but fail
- A down-forwards ASDQ1 to Q via an mcc pointer
- Q solve the subquery ASDQ2 ?T2|FC2 in its local database returning Y to A
- A send back Y to P and X
- A up-forwards ASDQ3 and ASDQ4 and ASDQ5 to B
- B solve the ASDQ3 ?T3|FC3 in its local database returning Z to A (and back to P and X)
- B side-forwards ASDQ4 & ASDQ5 to C
- C solve the ASDQ4 ?T4|FC2 in its local database returning V to B (and back to A, P and X)
- C down-forwards ASDQ5 to D
- D solve the ASDQ5 ?T5|FC5 in its local database returning W to C (and back to B, A, P and X)
Note
- When A up-forwards to B, it follows that A respect the CUSTOMER-PROVIDER SDA with B (e.g. A respect the Semantic Discovery Agreement (SDA) directives of B). When B side-forwards to C, it follows that B and C respect the PEER-PEER Semantic Discovery Agreement (SDA) directives. When C down-forwards to D, it follows that D respect the PROVIDER-CUSTOMER Semantic Discovery Agreement (SDA) with C (e.g. D respect the Semantic Discovery Agreement (SDA) directives of C).
The moral is : B and C should be "acknowledged'' for their "routing job".
12.29.7 Alternative flow
In the following alternative topology, the CUSTOMER-PROVIDER Semantic Discovery Agreement (SDA) are reversed:
Figure 12.29.7-1 - Pre-condition topology for alternative flow
A possible "trace" of the Semantic Discovery Routing Protocol (SDRP), again inspired to [i.24] and [i.25] proceeds as in clause 12.20.6, excepting for the following caveat.
Caveat. When A down-forwards to B, it expects that B should respect the provider-customer Semantic Discovery Agreement (SDA) with A (e.g. B should acknowledge A. This is not intuitive since B does a favour to A and acknowledge A). When B side-forwards to C, it expects that B and C have a common Semantic Discovery Agreement (SDA) and, as such, they not acknowledge it each other. When C up-forwards to D, it expects that C and D have a common Semantic Discovery Agreement (SDA) (e.g. C should acknowledge D). This is not intuitive since C does a favour to D and acknowledges D).
The moral is : B and C do a job for their providers and, moreover, they have to acknowledge for their "routing job".
Alternative traces happen in practice. Because of the distributed nature of the Semantic Discovery Routing Protocol (SDRP), it is beneficial to try incentivizing routing respecting the Semantic Discovery Agreement (SDA), and, as such, avoid routing not respecting the Semantic Discovery Agreement (SDA). Those situations are not new in Internet and are referred as VALLEY ROUTING by [i.24]. "Good routing" should guarantee that routing is always "valley preserving" (or "no valley"). Valley routing property is also preserved in the Network Aware Resource Discovery Protocol [i.25].
12.29.8 Post-conditions
X can start to interact with Y, Z, V, and W.
12.29.9 High Level Illustrations
Figure 12.29.9-1 - Illustration for multiple service providers semantic discovery use case
12.29.10 Potential requirements
The oneM2M system shall provide mechanisms for Advanced Semantic Discovery (ASD) across a distributed network of IoT nodes within a single oneM2M Service Provider and across different IoT Service Providers.
A CSE receiving an Advanced Semantic Discovery Query (ASDQ) shall extract the Semantic Discovery Query (SDQ), embedded in the packet payload, and shall resolve the query with respect to the locally available information and shall forward to other suitable CSEs the Advanced Semantic Discovery Query (ASDQ) to complete the discovery.
More specifically, the oneM2M system shall provide:
- An Advanced Semantic Discovery Query Language (ASDQL) that the ability to write Advanced Semantic Discovery Query (ASDQ);
A Semantic Discovery Agreement (SDA) to state some communication agreements between CSE;
A Semantic Query Resolution (SQR) that allows to locally translate an Advanced Semantic Discovery Query (ASDQ) into some elementary oneM2M Semantic Discovery Queries (SDQ);
A Semantic Discovery Routing (SDR) to route an Advanced Semantic Discovery Query (ASDQ) between different CSEs.