50
OneM2M Standard Specification Hamdamboy Urunov, a Ph.D. student. Special Communication Research Center., Financial Information Security., Kookmin University Seoul, South Korea Functional Architecture Summary of Identifiers and Resource structure

One m2m 4- identifier_resoruce structure

Embed Size (px)

Citation preview

Page 1: One m2m 4- identifier_resoruce structure

OneM2M Standard Specification

Hamdamboy Urunov, a Ph.D. student.Special Communication Research Center.,

Financial Information Security., Kookmin University Seoul, South Korea

Functional Architec-ture

Summary of Identifiers and Resource structure

Page 2: One m2m 4- identifier_resoruce structure

2

The schedule of OneM2M Specifi-cation

• TS-0001- Functional_Architecture-V2_10_0 M2M Identifiers

Procedures for Accessing Resources

Page 3: One m2m 4- identifier_resoruce structure

3

M2M Identifiers

Identity Management function defines many M2M

M2M Identifiers Application Entity Identifier(AE-ID)

Application Identifier(App-ID)

CSE-Identifier(CSE-ID)

M2M Node Identifier(M2M-Node-ID)

M2M Service Subscription Identifier(M2M-Sub-ID)

M2M Request Identifier(M2M-Request-ID)

M2M External Identifier(M2M-Ext-ID)

Underlying Network Identifier(UNetwork-ID)

Trigger Recipient Identifier(Trigger-Recipient-ID)

M2M Service Identifier(M2M-Sev-ID)

Service Role Identifier(SRole-ID)

M2M Service Profile Identifier(M2M-Service-Profile-ID)

Page 4: One m2m 4- identifier_resoruce structure

4

Application Entity Identifier(AE-ID) An Application Entity Identifier (AE-ID) uniquely identifies an AE resident on an M2M Node.

AE-ID is globally unique within/outside M2M Service Provider (SP) domain.

Application Identifier(App-ID)

An Application Identifier (App-ID) uniquely identifies an M2M Application in a given context.

Two Type

App-ID(Registered App-ID) : guarantee to be globally unique. Non-Registered App-ID : not guarantee to be globally unique.

M2M Identifiers(1)

Page 5: One m2m 4- identifier_resoruce structure

5

M2M Identifiers (2) CSE-Identifier(CSE-ID)

A CSE shall be identified by a globally unique identifier, the CSE-ID, when instantiated within an M2M Node in the M2M System.

The CSE-ID is globally unique, when used internally within/outside a specific M2M SP domain. The CSE-ID shall identify the CSE for the purpose of all interactions from/to the CSE within the M2M System.

M2M Node Identifier(M2M-Node-ID) An M2M Node, hosting a CSE and/or Application(s) shall be identified by a globally unique identifier, the M2M-

Node-ID. The M2M System shall allow the M2M Service Provider to set the CSE-ID and the M2M-Node-ID to the same

value. The M2M-Node-ID enables the M2M Service Provider to bind a CSE-ID to a specific M2M Node.

Examples of allocating a globally unique M2M-Node-ID include the use of Object Identity (OID) and IMEI.

ID(value) = CSE-ID = M2M Node-ID

M2M Node-ID = Object ID+ IMEI

International Mobile Equipment Identity

Page 6: One m2m 4- identifier_resoruce structure

6

M2M Request Identifier(M2M-Request-ID) The M2M-Request-ID tracks a Request initiated by an AE over the Mca reference point, and by a

CSE over the Mcc reference point To enable an AE to track Requests and corresponding Responses over the Mca reference point,

AEs shall include a distinct M2M Request Identifier per request

M2M External Identifier(M2M-Ext-ID) The M2M-Ext-ID is used by an M2M SP when services are requested from the Underlying Network.

• allows the Underlying Network to identify the M2M Device (e.g. ASN, MN) associated with the CSE-ID. For each CSE-ID, there is only one M2M-Ext-ID for a specific UNetwork-ID. The mapping by the Underlying Network of the M2M-Ext-ID to the M2M Device is Underlying Network spe-

cific. The Underlying Network provider and the M2M SP collaborate for the assignment of an M2M-Ext-ID to each

CSE.

M2M Identifiers (3)

M2M-Request-ID = AE (Mca) || CSE (Mcc)

Page 7: One m2m 4- identifier_resoruce structure

7

Underlying Network Identifier(UNetwork-ID) The UNetwork-ID is used for identifying an Underlying Network. UNetwork-ID is a static value and

unique within a M2M Service Provider domain. For example, based on "policy", scheduling of traffic triggered by a certain event category in

certain time periods may be allowed over Underlying Network "WLAN”.

Trigger Recipient Identifier(Trigger-Recipient-ID) The Trigger-Recipient-ID is used to identify an instance of an ASN/MN-CSE on an execution environ-

ment For example, when 3GPP device triggering is used, the Trigger-Recipient-ID maps to the AppID

For pre-provisioned M2M-Ext-IDs, Trigger-Recipient-ID is provisioned at the Infrastructure Node along with the M2M-Ext-ID and the associated CSE-ID.

For dynamic M2M-Ext-IDs, Trigger-Recipient-ID specific to the Underlying Network is provisioned at each M2M device in the Field Domain. Such Trigger-Recipient-ID is conveyed to the IN-CSE during CSE Registration

M2M Identifiers (4)

Page 8: One m2m 4- identifier_resoruce structure

8

M2M Service Identifier(M2M-Sev-ID) The M2M-Serv-ID is an identifier of a M2M Service offered by an M2M SP. It is an essential part of the M2M Service Subscription which stores a set of M2M-Serv-IDs pertaining

to the set of subscribed services.

Service Role Identifier(SRole-ID) The Service Role Identifier shall be used for service access authorization. In each M2M Service, one or multiple M2M Service Role(s) shall be defined by the M2M Service

Provider. An M2M Service Role is defined as a create permission pertaining to resource types which are associ-

ated with M2M Service.

M2M Identifiers (5)

Page 9: One m2m 4- identifier_resoruce structure

9

M2M Service Profile Identifier(M2M-Service-Profile-ID)

An M2M Service Profile Identifier defines M2M Service Roles as well as applicable rules governing the AEs register-

ing with M2M Nodes and the AEs residing on these nodes.

Every M2M Service Profile is allocated an identifier so it can be retrieved for verification purposes.

• belongs to the M2M Service Provider;

• identifies the M2M Service Roles as well as applicable rules governing AEs registering with an M2M node.

• The M2M Service Roles define the M2M Services authorized for the M2M Service Profile.

M2M Identifiers (6)

Page 10: One m2m 4- identifier_resoruce structure

10

Page 11: One m2m 4- identifier_resoruce structure

11

Summary of IdentityHow can dominate Identifiers uniqueness!?

Page 12: One m2m 4- identifier_resoruce structure

Summary of IdentityHow can dominate Identifiers uniqueness

12

1. IMEI has aggregated:* International Mobile Equipment Identity (IMEI)* Mobile Equipment (ME)

https://www.youtube.com/watch?v=q7dHTJyDcX0

Page 13: One m2m 4- identifier_resoruce structure

13

• What is IMEI number that is given to every mobile device in the world?

How can dominate Identifiers uniqueness (cont…)

• 15-digit or 17-digit numbers

• Mobile world is using the following format customers are used to: AB-CDEFGH-IJKLMN-Z

• There are many hardware platforms on which GSM Mobile Equipment models are based.

• They are manufactured by different companies and have different ME Type

• You can guess that ME Type models can get changes in hardware design, enhancements

and other things manufacturing process add to devices.

• The companies are using ME Build Level and give their products different build num-

bers to reflect the changes.

Page 14: One m2m 4- identifier_resoruce structure

14

How can dominate Identifiers uniqueness (cont…)

AB-CDEFGH-IJKLMN-Z The historical IMEI structure contained TAC, FAC, Serial number and

Check digit. TAC used to be (Type Approval Code )and is now the Type Allocation

Code. FAC (the Final Assembly Code).

If we return to our main formula, we’ll see that:* AB standed for TAC code [or Reporting Body Identifier]

* CDEFGH standed for the remainder of TAC [FAC]: CDEF referred to ME Type Identifier and GH could

indicate the manufacturer and was under control of the Reporting Body

* IJKLMN was the serial No [it was Allocated by Reporting Body however only manufacturers could as-

sign it to ME models* Z was the check digit [it defines as a function for all IMEI codes]

Page 15: One m2m 4- identifier_resoruce structure

15

Then the industry decided to change this IMEI structure and TAC + FAC were combined into the single 8-digit TAC

code [the FAC had to be considered as obsolete]. It is understood that such changes couldn’t happen within one or two days. There was a 2-year transition period be-

tween December 31st, 2002 and April 1st, 2004. The TAC codes that were allocated for the two ‘transition’ years included the first 6-digit just as they should and the 2-

digits (seventh and eighth ones) were 00. This helped companies to modify their productions, operators to add changes to their systems and start using 8-digit

TAC codes instead of the 6-digit codes. At the same time, Reporting Bodies were able to apply changes to IMEI allocation systems and the GSM Association

could update its databases. Whenever a new FAC code was requested by manufacturers between 2002 and 2004 –

they were provided with a new 8-digit TAC code instead.

How can dominate Identifiers uniqueness (cont…)

• The modern IMEI numbers don’t have the FAC code any more.

• They all have the 8-digit TAC number + Serial number +

check digit and you are welcome to learn more about the new IMEI structure you might have on your mobile de-vice.

http://imei.org/what-is-imei-number-tac-and-fac-terms/

Page 16: One m2m 4- identifier_resoruce structure

16

Application Identifier(App-ID)

Page 17: One m2m 4- identifier_resoruce structure

17

Unique identifier (UID)• A unique identifier (UID) is a numeric or alphanumeric string that is associated with a single entity within a

given system.Here are a few examples of UIDs: • A Uniform Resource Identifier (URI)•A Universal Unique Identifier  (UUID) is a 128-bit number used to uniquely identify some object or en-tity on the Internet.•A global unique identifier (GUID) is a number that Microsoft programming generates to create a unique identity for an entity such as a Word document.•A bank identifier code  (BIC) is a unique identifier for a specific financial institution. •A unique device identifier (UDID) is a 40-character string assigned to certain Apple devices including the iPhone, iPad, and iPod Touch.•A national provider identifier (NPI) is a unique ten-digit identification number required by HIPAA for all health care providers in the United States.

Page 18: One m2m 4- identifier_resoruce structure

18

A Uniform Resource Identifier (URI)

Page 19: One m2m 4- identifier_resoruce structure

19

Universal Unique Identifier  (UUID)In its canonical string representation, the sixteen octets of a UUID are represented as 32 lowercase hexadecimal digits, displayed in five groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32 alphanumeric characters and four hyphens).

The most significant bits of digit N indicate the UUID "variant" and the 4 bits of digit M indicate the UUID "version". In the example, M is 1 and N is a, meaning that.The canonical 8-4-4-4-12 format string is based on the "record layout" for the 16 bytes of the UUID:•a 4-byte (8 hex digits) "time_low" integer giving the low 32 bits of the time;•a 2-byte (4 hex digits) "time_mid" integer giving the middle 16 bits of the time;•a 2-byte (4 hex digits) "time_hi_and_version", with the 4-bit "version" in the most significant bits, followed by the high 12 bits of the time;•2 1-byte fields (totaling 4 hex digits) called "clock_seq_hi_res" and "clock_seq_lo", with the "variant" multiplexed into the most significant 1 to 3 bits of clock_seq_hi_res;•6 bytes (12 hex digits) with the 48-bit "node".

Page 20: One m2m 4- identifier_resoruce structure

20

 Global unique Identifier (GUID)  Global unique Identifier (GUID) A unique number assigned to a person, a piece of software, or a piece of hardware.Similar to a MAC Address, except that people are not aware of its presence. A media access control address (MAC address) is a unique identifier assigned to network interfaces for communi-

cations on the physical network segment. MAC addresses are used as a network address for most IEEE 802 network technologies, including Ethernet and

WiFi. Get Mac if config/all (can be spoofed) ◦ Because people are not aware they are being tracked, the information can be abused

the Microsoft Windows platforms adopted that design as globally unique identifiers (GUIDs).

Page 21: One m2m 4- identifier_resoruce structure

21

A bank identifier code  (BIC)

The SWIFT Code is a standard format for Business Identifier Codes (BIC) and it's used to uniquely identify banks and financial institutions globally - it says who and where they are. These codes are used when transferring money between banks, in particular for international wire transfers or SEPA payments. Banks also use these codes to exchanging messages.

Page 23: One m2m 4- identifier_resoruce structure

23

•A national provider identifier (NPI) is a unique ten-digit identification number required by HIPAA for all health care providers in the United States.

A national provider identifier (NPI)

What is National Provider Identifier (NPI)? The Health Insurance Portability and Accountability Act (HIPAA) of 1996 requires the adoption of a standard unique identifier for health care providers, the National Provider Identifier (NPI). NPI is 10 digits in length and will replace health care provider identifiers in use today, including the nine-digit Medi-Cal and six-digit Denti-Cal provider numbers

Page 24: One m2m 4- identifier_resoruce structure

24

Description and Flows of Reference Points

Page 25: One m2m 4- identifier_resoruce structure

8. Description and Flows of Reference Points

25

The message applies to communications such as: • between an AE and a CSE (Mca reference point); and • among CSEs (Mcc reference point).

AE

CSE

Mca/Mcc

To: Address of the target resource or target attribute for the operation. To: parameter can be the URI of an attribute to be retrieved.

CSE

under-stand

Servers Client

from an Originator to a Receiver

Such communications can be initiated either by the AEs or by the CSEs depending upon the operation in the Request message

From: Identifier representing the Originator. From parameter is used by the Receiver to check

the Originator identity for access

Page 26: One m2m 4- identifier_resoruce structure

26

8. Description and Flows of Reference Points (cont…)

8.1.2 Request Requests over

• The Mca and Mcc reference points, from an Originator to a Receiver, shall contain mandatory and may contain optional parameters. • Certain parameters may be mandatory or optional depending upon the Requested operation.

AE

CSE

CSE

Mca/Mcc

From: Identifier represent-ing the Originator.

The From parameter is used by the Receiver to check the Originator identity for access privilege verification

The Operation parameter shall indicate the operation to be executed at the Receiver:

- Create (C): To is the address of the target resource where the new resource (parent resource). - Retrieve (R): an existing To addressable resource is read and provided back to the Originator. - Update (U): the content of an existing To addressable resource is replaced with the new content as in Content parameter. If some attributes in the Content parameter do not exist at the target resource, such attributes are created with the assigned values. If some attributes in the Content parameter are set to NULL, such attributes are deleted from the addressed resource.

To is the address of the target resource where

the new resource.

Page 27: One m2m 4- identifier_resoruce structure

27

AE

CSE

CSE

Mca/Mcc

8. Description and Flows of Reference Points (cont…)

- Delete (D): an existing To addressable resource and all its sub-resources are deleted from the Resource stor-age. - Notify (N): information to be sent to the Receiver, processing on the Receiver is not indicated by the Originator.

Operation dependent Parameters: Content: resource content to be transferred.

The Content parameter shall be present in Request for the following op-erations: - Create (C): Content is the content of the new resource with the re-source type Resource Type. - Update (U): Content is the content to be replaced in an existing re-

source. For attributes to be updated at the resource, Content in-cludes the names of such attributes with their new values.

- For attributes to be created at the resource, Content includes names of such attributes with their associated values. For attributes to be deleted at the resource, Content includes the names of such at-tributes with their value set to NULL.

- Notify (N): Content is the notification information.

The Content parameter may be present in Request for the following operations: - Retrieve (R): Content is the list of attribute names from the resource that needs to be re-trieved. The values associated with the at-tribute names shall be returned.

Page 28: One m2m 4- identifier_resoruce structure

28

Role IDs: optional, required when role based access control is applied. • The Role IDs parameter shall be used by the Receiver to check the Access Control

privileges of the OriginatorOriginating Timestamp: optional originating timestamp of when the message was built.

• Example usage of the originating timestamp includes: to measure and enable opera-tion

message logging correlation message prioritization/scheduling accept performance requests charging.

8. Description and Flows of Reference Points (cont…)Optional Parameters:

AE

CSE

CSE

Mca/Mcc

Role ID

Request Expiration Timestamp: optional request message expiration timestamp. The Receiver CSE should handle the request before the time expires.

• If a Receiver CSE receives a request with Request Expiration Timestamp with the value indicating a time in the past, then the request shall be rejected.

Page 29: One m2m 4- identifier_resoruce structure

29

8. Description and Flows of Reference Points (cont…)

RFC 792 documents:

For example, the identifier might be used like a port in TCP or UDP to

identify a session and the sequence number might be incremented on each re-

quest sent. The destination returns these same values in the reply.

Code 0 may be received from a gateway or a host.

The data received (a timestamp) in the message is returned in the reply together with an additional timestamp.

The timestamp is 32 bits of milliseconds since midnight UT. The identifier and sequence number may be used by the echo

sender to aid in matching the replies with the requests.

http://www.networksorcery.com/enp/protocol/icmp/msg14.htm

Page 30: One m2m 4- identifier_resoruce structure

Summary of Request Message Parameters Showing any differences as applied to C, R, U, D or N operations.

"M" indicates Mandatory, "O" indicates Optional, "N/A" indicates "Not Applicable".

30

Page 31: One m2m 4- identifier_resoruce structure

31

Response Type: optional response message type: Indicates what type of response shall be sent to the issued request and when the response shall be sent to the Originator:

8. Description and Flows of Reference Points (cont…)

Response Type

nonBlockingRequest-Synch

nonBlockingRequestA-synch blockingRequest

flex Blocking {optional list of notification tar-

gets}

AE

CSE

CSE

Mca/Mcc

The request is accepted by the Receiver CSE, the Receiver CSE responds, after acceptance, with an acknowledgement confirming that the Receiver CSE will further process the request.

nonBlockingRequest-Synch

Page 32: One m2m 4- identifier_resoruce structure

32

Response Type: optional response message type: Indicates what type of response shall be sent to the issued request and when the response shall be sent to the Originator:

8. Description and Flows of Reference Points (cont…)

Response Type

nonBlockingRequest-Synch

nonBlockingRequestA-synch blockingRequest

flex Blocking {optional list of notification tar-

gets}

AE

CSE

CSE

Mca/Mcc

The request is accepted by the Receiver CSE, the Receiver CSE shall respond, after acceptance, with an Acknowledgement confirming that the Receiver CSE will further process the request.

nonBlockingRequestAsynch {optional list of notification

targets}

The result of the requested operation needs to be sent as notifica-tion(s) to the notification target(s) provided optionally within this parame-ter as a list of entities or to the Originator when no notification target list is provided.

Page 33: One m2m 4- identifier_resoruce structure

33

Response Type: optional response message type: Indicates what type of response shall be sent to the issued request and when the response shall be sent to the Originator:

8. Description and Flows of Reference Points (cont…)

Response Type

nonBlockingRequest-Synch

nonBlockingRequestA-synch blockingRequest

flex Blocking {optional list of notification tar-

gets}

AE

CSE

CSE

Mca/Mcc

blockingRe-quest

The request is accepted by the Receiver CSE, the Receiver CSE re-sponds with the result of the requested operation after com-pletion of the requested operation.

This is the default behavior when the Response Type parameter is not given the request

Page 34: One m2m 4- identifier_resoruce structure

34

Response Type: optional response message type: Indicates what type of response shall be sent to the issued request and when the response shall be sent to the Originator:

8. Description and Flows of Reference Points (cont…)

Response Type

nonBlockingRequest-Synch

nonBlockingRequestA-synch blockingRequest

flex Blocking {optional list of notification tar-

gets}

AE

CSE

CSE

Mca/Mcc

flex Blocking {optional list of notification

targets}

When Response Type in the request received by the Re-ceiver CSE is set to flexBlocking, it means that the Originator of the request has the capa-bility to accept the following types of responses: nonBlock-ingRequestSynch, nonBlockingRequestAsynch and block-ingRequest.

Page 35: One m2m 4- identifier_resoruce structure

35

8. Description and Flows of Reference Points (cont…)Result Con-tent Result Content :

• Indicates what are the expected components of the result of the requested operation. • The Originator of a request may not need to get back a result of an operation at all. • This shall be indicated in the Result Content parameter. • Settings of Result Content depends on the requested operation specified in Operation.

AE

CSE

CSE

Mca/Mcc

Result Con-tent

attributeshierarchical-ad-dress hierarchical-address + at-tributes

Attributes + child-re-sources

child-re-sources

Attributes + child-resources

Attributes + child-resource-ref-erences

child-resource-referencesnoth-ing

Page 36: One m2m 4- identifier_resoruce structure

36

Attributes: Representation of the requested resource shall be returned as content, with out the address(es) of the child resource(s) or their descendants.

8. Description and Flows of Reference Points (cont…)Result Con-tent

Result Con-tent

attributeshierarchical-ad-dress hierarchical-address + at-tributes

Attributes + child-re-sources

child-re-sources

Attributes + child-resources Attributes + child-resource-ref-erences

child-resource-referencesnoth-ing

AE

CSE

CSE

Mca/Mcc

For example, if the request is to retrieve a <container> resource, the address(es) of the <contentInstance> child-resource(s) is not provided.

•This setting shall be only valid for Create, Retrieve, Update, Delete operation. •When this is used for Create operation, only assigned/modified attributes shall

be included in the content. •If the Originator does not set Result Content parameter in the request mes-

sage, this setting shall be the default value when the Receiver processes the re-quest message.

Page 37: One m2m 4- identifier_resoruce structure

37

hierarchical-address:•Representation of the address of the created re-

source. •This shall be only valid for a Create operation.•The address shall be in hierarchical address

scheme.

8. Description and Flows of Reference Points (cont…)Result Con-tent

Result Con-tent

attributeshierarchical-ad-dress hierarchical-address + at-tributes

Attributes + child-re-sources

child-re-sources

Attributes + child-resources Attributes + child-resource-ref-erences

child-resource-referencesnoth-ing

AE

CSE

CSE

Mca/Mcc

Page 38: One m2m 4- identifier_resoruce structure

38

Summary of Response Message Parameters The Response received by the Originator of a Request accessing resources over

• the Mca and Mcc reference points shall contain mandatory • may contain optional parameters.

Mandatory Parameters:

• Response Status Code: This parameter indicates that a result of the requested operation is successful, unsuc-cessful, acknowledgement or status of processing such as authorization timeout, etc.:

A successful code indicates to the Originator that the Requested operation has been executed successfully by the Hosting CSE.

An unsuccessful code indicates to the Originator that the Requested operation has not been executed successfully

by the Hosting CSE. An acknowledgement indicates to the Originator that the Request has been received and accepted by the attached

CSE, i.e. by the CSE that received the Request from the issuing Originator directly, but the Request operation has not been executed yet. The success or failure of the execution of the Requested operation is to be conveyed later.

Request Identifier: The Request Identifier in the Response shall match the Request Identifier in the corresponding Request.

Page 39: One m2m 4- identifier_resoruce structure

Showing any differences as applied to successful C, R, U, D or N operations, and unsuccessful opera-tions. "M" indicates mandatory, "O" indicates optional, "N/A" indicates "not applicable".

39

Optional parameters

Page 40: One m2m 4- identifier_resoruce structure

Procedures for Accessing Resources

40

This clause describes the procedures for accessing the resources. The term "hop" in the descriptions here refers to the number of Transit CSEs traversed by a request on its

route from the Originator to the Hosting CSE. Traversal implies that the request was forwarded from one CSE to either its Registrar CSE or Registered CSE.

Page 41: One m2m 4- identifier_resoruce structure

41

Procedures for Accessing Resources(1)

Page 42: One m2m 4- identifier_resoruce structure

42

Procedures for Accessing Re-sources(2)

Page 43: One m2m 4- identifier_resoruce structure

43

Accessing Resources in CSEs - Non-Blocking Requests Synchronous Case

In the synchronous case,• it is assumed that the Originator of a Request is not able to re-

ceive asynchronous messages.

all exchange of information between Originator and Receiver

• CSE needs to be initiated by the Originator.

In that case the information flow depicted in figure 8.2.2.2-1 is ap-plicable. • Originator is trying to retrieve the result of the requested opera-

tion • with a second Request referring to the "Req-Ref" provided • in the Response to the original Request.

Page 44: One m2m 4- identifier_resoruce structure

44

Another variation of the information flow for the synchronous

case is depicted in figure 8.2.2.2-2.

Equivalent information flows are valid also for cases where

the target resource of the requested operation is not hosted

on the Receiver CSE.

From an Originator's perspective there is no difference as

the later retrieval of the result of a requested operation would

always be an exchange of Request/Response messages be-

tween the Originator and the Receiver CSE using the refer-

ence to the original request.

Accessing Resources in CSEs - Non-Blocking Requests Synchronous Case (1)

Page 45: One m2m 4- identifier_resoruce structure

Asynchronous Case

45

Accessing Resources in CSEs - Non-Blocking Requests

In the asynchronous case, a Hosting CSE that does not support the <request> resource type shall respond to an acceptable request with a response containing an Acknowledgement without a reference to a resource containing the context of the request.

In the asynchronous case the exemplary information flow depicted in figure 8.2.2.3-1 is applicable.

In this case it is assumed that the Originator of the Request provided two Notification Targets. (the Originator and one other Notification Target) to which notification shall be sent when the result of the re-quested operation is available or when the request failed.

Equivalent information flows are valid also for cases where the tar-get resource of the requested operation is hosted on the Hosting CSE itself.

From an Originator's or Notification Target's perspective there is no difference as the later notification of the result of a requested opera-tion would always be an exchange of request/response messages be-tween the CSE carrying out the requested operation and the Notifica-tion Targets using reference to the original Request ID.

Page 46: One m2m 4- identifier_resoruce structure

46

Procedures for interaction with Underlying Networks

This case describes the scenario where IN-CSE targets an ASN/MN-CSE (which is registered with the IN-CSE) for the Device Triggering request.

Figure 8.3.3.2.1-1 shows the general procedure for Device Triggering and, if required, for establishment of connectivity between IN-CSE and the Field Node.

Page 47: One m2m 4- identifier_resoruce structure

47

Pre-condition • The IN-CSE has already sent device trigger request to 3GPP

network and connectivity is not established yet. • IN-CSE has already stored the previous device trigger in-

formation, e.g. trigger reference number, etc.. Step-1: Device Trigger Recall/Replace request • IN-CSE issues the device trigger Recall/Replace request to

3GPP network. In addition to same parameters in the original device trigger re-quest, the following additional parameters for 3GPP device trigger recall/replace include: The old trigger reference number was assigned to the previ-

ously submitted trigger message that the IN-CSE wants to recall/replace.

For trigger replace request, the new trigger reference number which is assigned by the IN-CSE to the newly submitted trigger message.

Support for device trigger recall/replace procedure

Page 48: One m2m 4- identifier_resoruce structure

48

General Procedure for Location Request

• This procedure describes a scenario wherein an AE sends a request to obtain the location information of a target AE or CSE hosted in an M2M Node

• to the location server NSE, and the location server re-sponses to the CSE with location information.

Page 49: One m2m 4- identifier_resoruce structure

General procedure for Configura-tion of Traffic Patterns

49

Configuration of Traffic Patterns

Traffic pattern (TP) parameters can be associated with one or multiple Field Domain Nodes and are defined in table 8.3.5.2-1.

A Field Domain Node can be associ-ated with one of TP parameters or multiple sets of TP parameters for a particular target network that have different, non-overlapping schedules.

At any time only a single set of TP parameters can be associated with a Field Domain Node per underlying network.

The CSE shall assure that different TP parameter sets for a Node are not overlapping at any point in time.

A combination of the following pa-rameters can be set.

Page 50: One m2m 4- identifier_resoruce structure

50

Thank [email protected]