1. The document discusses identifiers and resource structures in OneM2M specifications. It defines several M2M identifiers such as AE-ID, App-ID, CSE-ID, M2M-Node-ID, and others that uniquely identify entities. 2. It describes the formats and purposes of each identifier, such as the AE-ID uniquely identifying an application entity and the CSE-ID identifying a common services entity. The App-ID can be globally unique or non-unique. 3. Reference points like Mca and Mcc are also summarized, with examples of request messages containing parameters like From, To, and Operation to indicate the initiator, target resource, and requested operation.

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

2. The schedule of OneM2M Specification
• TS-0001- Functional_Architecture-V2_10_0
2
 M2M Identifiers
 Procedures for Accessing Resources

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)
3

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.
4
M2M Identifiers(1)

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

6. 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 specific.
 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)

7. 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 environment
 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)

8. 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 associated with
M2M Service.
M2M Identifiers (5)

9. 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 registering
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)

10. 10

11. 11
Summary of Identity
How can dominate Identifiers uniqueness!?

12. Summary of Identity
How can dominate Identifiers uniqueness
12
1. IMEI has aggregated:
* International Mobile Equipment Identity (IMEI)
* Mobile Equipment (ME)
https://www.youtube.com/watch?v=q7dHTJyDcX0

13. 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 numbers to reflect the
changes.

14. 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 assign it to ME models
* Z was the check digit [it defines as a function for all IMEI codes]

15. 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 between 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 device.
http://imei.org/what-is-imei-number-tac-and-fac-terms/

16. 16
Application Identifier(App-ID)

17. 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 entity 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.

18. A Uniform Resource Identifier (URI)
18

19. Universal Unique Identifier (UUID)
19
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".

20. Global unique Identifier (GUID)
20
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 communications 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).

21. A bank identifier code (BIC)
21
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.

22. A unique device identifier (UDID)
22
•A unique device identifier (UDID) is a
40-character string assigned to
certain Apple devices including
the iPhone, iPad, and iPod Touch

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

24. 24
Description and Flows of Reference Points

25. 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
understand
ServersClient
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

26. 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 representing
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.

27. 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 storage.
- 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 operations:
- Create (C): Content is the content of the new resource with the resource type
Resource Type.
- Update (U): Content is the content to be replaced in an existing resource. For
attributes to be updated at the resource, Content includes 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 attributes 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 retrieved. The
values associated with the attribute names shall be
returned.

28. 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
Originator
Originating Timestamp: optional originating timestamp of when the message was built.
• Example usage of the originating timestamp includes: to measure and enable operation
 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.

29. 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
request 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

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

31. 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
nonBlockingRequestSynch nonBlockingRequestAsynch blockingRequest flex Blocking
{optional list of notification targets}
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.
nonBlockingRequestSynch

32. 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
nonBlockingRequestSynch nonBlockingRequestAsynch blockingRequest flex Blocking
{optional list of notification targets}
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 notification(s) to the
notification target(s) provided optionally within this parameter as a list of entities or
to the Originator when no notification target list is provided.

33. 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
nonBlockingRequestSynch nonBlockingRequestAsynch blockingRequest flex Blocking
{optional list of notification targets}
AE
CSE
CSE
Mca/
Mcc
blockingRequest
The request is accepted by the Receiver CSE, the Receiver CSE responds
with the result of the requested operation after completion of the
requested operation.
This is the default behavior when the Response Type parameter is not given
the request

34. 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
nonBlockingRequestSynch nonBlockingRequestAsynch blockingRequest flex Blocking
{optional list of notification targets}
AE
CSE
CSE
Mca/
Mcc
flex Blocking
{optional list of notification targets}
When Response Type in the request received by the Receiver CSE
is set to flexBlocking,
it means that the Originator of the request has the capability to
accept the following types of responses: nonBlockingRequestSynch,
nonBlockingRequestAsynch and blockingRequest.

35. 35
8. Description and Flows of Reference Points (cont…)
Result Content
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 Content
attributes
hierarchical-address
hierarchical-address + attributes
Attributes + child-resources
child-resources
Attributes + child-resources
Attributes + child-resource-references
child-resource-references
nothing

36. 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 Content
Result Content
attributes
hierarchical-address
hierarchical-address + attributes
Attributes + child-resources
child-resources
Attributes + child-resources
Attributes + child-resource-references
child-resource-references
nothing
AE
CSE
CSE
Mca/
Mcc
For example, if the request is to retrieve a <container> resource, the address(es) of the <content
Instance> 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 includ
ed in the content.
• If the Originator does not set Result Content parameter in the request message, this setting
shall be the default value when the Receiver processes the request message.

37. 37
hierarchical-address:
• Representation of the address of the created resource.
• 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 Content
Result Content
attributes
hierarchical-address
hierarchical-address + attributes
Attributes + child-resources
child-resources
Attributes + child-resources
Attributes + child-resource-references
child-resource-references
nothing
AE
CSE
CSE
Mca/
Mcc

38. 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,
unsuccessful, 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.

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

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

41. 41
Procedures for Accessing Resources(1)

42. 42
Procedures for Accessing Resources(2)

43. 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
receive 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
applicable.
• Originator is trying to retrieve the result of the requested
operation
• with a second Request referring to the "Req-Ref" provided
• in the Response to the original Request.

44. 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
between the Originator and the Receiver CSE using the
reference to the original request.
Accessing Resources in CSEs - Non-Blocking Requests
Synchronous Case (1)

45. 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
requested operation is available or when the request failed.
 Equivalent information flows are valid also for cases where the
target 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
operation would always be an exchange of request/response
messages between the CSE carrying out the requested operation and
the Notification Targets using reference to the original Request ID.

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

47. 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
information, 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
request, the following additional parameters for 3GPP device
trigger recall/replace include:
 The old trigger reference number was assigned to the
previously 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

48. General Procedure for Location Request
48
• 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
responses to the CSE with location information.

49. General procedure for Configuration 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
associated 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
parameters can be set.

50. Thank you!
hamdamboy.Urunov@gmail.com
50