Skip to content

5.4 Ports and ASPs (Abstract Services Primitives)

5.4.0 Introduction

The oneM2M ATS implements the following ports:

  • The mcaPort and mcaPortIn
  • The mccPort and mccPortIn
  • The acPort
  • The utPort
  • The InfoPort

5.4.1 mcaPort, mcaPortIn, mccPort, mccPortIn

These ports are used to send and receive the following message sets:

  • Request Primitives messages in accordance with oneM2M TS-0004 [2].
  • Response Primitives messages in accordance with oneM2M TS-0004 [2].

Two primitives are currently defined for these ports indicated as table 5.4.1-1:

  1. The M2MRequestPrimitive - to send or receive oneM2M messages to/from the IUT. Depending on the IUT to be tested:
    1. If the IUT is an AE, these messages are either received or sent by the tester which is associated with the CSE role through the mcaPortIn or the mcaPort respectively.
    2. If the IUT is a CSE, these messages are either sent or received by the tester when it plays the AE role through the mcaPort or the mcaPortIn respectively, or sent or received by the tester when it plays the CSE role through the mccPort or the mccPortIn respectively.
  2. The M2MResponsePrimitive - to send or receive oneM2M messages to/from the IUT. Depending on the IUT to be tested:
    1. If the IUT is an AE, these messages are either sent or received by the tester which is associated with the CSE role through the mcaPortIn or the mcaPort respectively.
    2. If the IUT is a CSE, these messages are either sent or received by the tester when it plays the CSE role through the mccPortIn or the mccPort respectively, sent or received by the tester when it plays the AE role through the mcaPortIn or mcaPort respectively.

Both primitives contain another parameters that permits to dynamically configure the test adaptor for every single sending. These parameters are:

  • Host: IP address of the IUT
  • XML Namespace
  • Protocol binding
  • Serialization
  • ForceFields: used to force invalid or empty values to certain attributes. This behaviour shall be implemented by the System Adaptor.

Table 5.4.1-1: Mapping of TTCN-3 Primitives to oneM2M Service Primitives

TTCN-3 Primitive oneM2M Message Direction IUT
M2MRequestPrimitive Request Primitive <=> AE
M2MRequestPrimitive Request Primitive <=> CSE
M2MResponsePrimitive Response Primitive <=> AE
M2MResponsePrimitive Response Primitive <=> CSE

5.4.2 mcnPort, mcnPortIn

These ports are used to send and receive the following message sets:

  • Request Primitives messages in accordance with oneM2M TS-0004 [2].
  • Response Primitives messages in accordance with oneM2M TS-0004 [2].

Two primitives are currently defined for these ports indicated:

  1. The T8Request - to send T8 request messages to/from the IUT according to 3GPP TS 29.122 [8].

  2. The T8Response - to receive T8 response messages to/from the IUT according to 3GPP TS 29.122 [8].

Further primitives might be defined to support other underlying networks.

5.4.3 mccPortInternal

This port is used to send and receive the following message sets between TTCN-3 components:

  • Request Primitives messages in accordance with oneM2M TS-0004 [2].
  • Response Primitives messages in accordance with oneM2M TS-0004 [2].

5.4.4 utPort

5.4.4.0 Introduction

The utPort is included in the oneM2M ATS in order to be able to stimulate the IUT and receive extra information from IUT upper layers. For instance, the utPort can be applied to automate AE testing shown as clause 5.4.4.1.

5.4.4.1 Usage for Automated AE Testing

The utPort is in charge of the communication between TTCN-3 Test Component module in Test System and the Upper Tester Application in SUT.

Functionalities that TTCN-3 Test Component module and the Upper Tester Application are required to implement are listed as follows:

  • TTCN-3 Test Component is able to configure the Test System and send standardized triggering commands to the SUT (Upper Tester Application).
  • Upper Tester Application can process the triggering command messages received from Test System (TTCN-3 Test Component) and stimulates IUT to act following the corresponding triggering command (i.e. sending oneM2M service primitives to Test System through Mca port).

oneM2M service Primitive defined for utPort is listed as follows:

  • The UtTrigger primitive is used to trigger upper layer events in IUT (i.e. sending oneM2M service primitives to Test System through Mca port).
  • The UtTriggerAck primitive is used by IUT to send acknowledgement back to the Test System.

The Upper Tester Application in SUT can be implemented as an embedded source code. An example for implementation of automated AE test for Registration is shown as figure 5.4.4.1-1.

Figure 5.4.4.1-1: Example of automated AE test using Ut interface

Figure 5.4.4.1-1: Example of automated AE test using Ut interface

5.4.4.2 Upper Tester Control Primitives

5.4.4.2.1 Introduction

The upper tester triggering message is used to transport control commands between Test System and the Upper Tester Application. The control command will contain essential parameters that are required for certain test case.

The upper tester triggering message type maps to particular message formats for exchanging data and those message formats are defined by TTCN-3 primitive as shown at table 5.4.4.2.1-1, U tTrigger and U tTriggerAck primitive.

Table 5.4.4.2.1-1: Mapping of TTCN-3 Primitives to oneM2M Service Primitives

Upper Tester Control Message Type TTCN-3 Primitives Direction Direction
Trigger UtTrigger Primitive TS UT
Trigger Acknowledgement UtTriggerAck Primitive UT TS
5.4.4.2.2 UtTrigger and UtTriggerAck Primitives

The UtTrigger primitive is initialized by the Test System to send triggering message to the target IUT as depicted in figure 5.4.4.2.2-1. The IUT will send acknowledgement message back to the Test System using UtTriggerAck primitive if trigger message is successfully transported to the IUT. Then IUT starts interaction with Test System through oneM2M request and response primitives.

Figure 5.4.2.2.2-1: Example of automated AE test using Ut interface

Figure 5.4.4.2.2-1: Trigger message flow

Table 5.4.4.2.2-1 defines UtTrigger and UtTriggerAck primitives including oneM2M data types to which are mapped as well as examples to show how to implement UtTrigger and UtTriggerAck primitives.

Table 5.4.4.2.2-1: UtTrigger and UtTriggerAck Primitive

Ut Control Primitive Mapping to oneM2M data types Description Reference Triggering Message HTTP message
UtTrigger Primitive requestPrimitive ONLY essential parameters included for certain test case

See note 1		 oneM2M
TS-0004 [2]		 EXAMPLE 1:
If the test objective is to test "Test System triggers IUT to execute a test case for creation of < AE > with labels attribute under a CSEBase resource ", then the triggering message would be serialized as following.		 EXAMPLE 1:
If the test objective is to test "Test System triggers IUT to execute a test case for creation of < AE > with labels attribute under a CSEBase resource ", then the triggering message would be serialized as following.
UtTrigger Primitive requestPrimitive ONLY essential parameters included for certain test case

See note 1		 oneM2M
TS-0004 [2]		 Request
{
"m2m:rqp" :{
"op": 1, //indicate CREATE operation
"ty": 2, //indicate AE resource type
"to": {TEST_SYSTEM_ADDRESS},
"pc": {
"m2m:ae": {
"lbl":"UNINITIALIZED" //indicate that attribute labels needs to be included
},
}
"rvi": "2a"
}
}		 Request
POST /{SUT_UT_APPLICATION_URL} HTTP/1.1
Host : {SUT_IP_ADDRESS:PORT}
Content-Length : {PAYLOAD_LENGTH}
Content-Type : application/ json

{
"m2m:rqp" :{
"op": 1, //indicate CREATE operation
"ty": 2, //indicate AE resource type
"to": {TEST_SYSTEM_ADDRESS},
"pc": {
"m2m:ae": {
"lbl":"UNINITIALIZED" //indicate that attribute labels needs to be included
}
},
"rvi": "2a"
}
}
UtTrigger Primitive requestPrimitive ONLY essential parameters included for certain test case

See note 1		 oneM2M
TS-0004 [2]		 EXAMPLE 2:
If the test objective is to test "Test System triggers IUT to execute a test case for delete of a < AE > resource. ", then the triggering message would be serialized as following.		 EXAMPLE 2:
If the test objective is to test "Test System triggers IUT to execute a test case for delete of a < AE > resource. ", then the triggering message would be serialized as following.
UtTrigger Primitive requestPrimitive ONLY essential parameters included for certain test case

See note 1		 oneM2M
TS-0004 [2]		 Request
{
"m2m:rqp" :{
"op": 4, //indicate DELETE operation
"to": {TARGET_AE_RESOURCE_ADDRESS}, //indicate Target AE resource address
"rvi": "2a"
}
}		 Request
POST /{SUT_UT_APPLICATION_URL} HTTP/1.1
Host : {SUT_IP_ADDRESS:PORT}
Content-Length : {PAYLOAD_LENGTH}
Content-Type : application/ json

{
"m2m:rqp" :{
"op": 4, //indicate DELETE operation
"to": {TARGET_AE_RESOURCE_ADDRESS}, //indicate Target AE resource address
"rvi": "2a"
}
}
UtTriggerPrimitive N/A Special upper tester commands N/A "RESET" Request
POST /{SUT_UT_APPLICATION_URL} HTTP/1.1
Host : {SUT_IP_ADDRESS:PORT}
X-M2M-UTCMD: Reset
UtTrigger Ack Primitive responsePrimitive ONLY responseStatusCode attribute included

See note 2		 oneM2M TS-0004 [2] Response
{
"m2m:rsp": {
"rsc": 2000
}

}
For any triggering response, it only contains a response status code, and the response status code for the triggering operation can only be set to either 2000 (OK) or 4000 (BAD_REQUEST) according to the rules for triggering operations.		 Response
HTTP/1.1 200 OK
X-M2M-RSC: 2000
NOTE 1: Additional rules defined in table 5.4.4.2.2-3 are also applied.
NOTE 2: Attribute response status code is defined at table 5.4.4.2.2-3.		 NOTE 1: Additional rules defined in table 5.4.4.2.2-3 are also applied.
NOTE 2: Attribute response status code is defined at table 5.4.4.2.2-3.		 NOTE 1: Additional rules defined in table 5.4.4.2.2-3 are also applied.
NOTE 2: Attribute response status code is defined at table 5.4.4.2.2-3.		 NOTE 1: Additional rules defined in table 5.4.4.2.2-3 are also applied.
NOTE 2: Attribute response status code is defined at table 5.4.4.2.2-3.		 NOTE 1: Additional rules defined in table 5.4.4.2.2-3 are also applied.
NOTE 2: Attribute response status code is defined at table 5.4.4.2.2-3.		 NOTE 1: Additional rules defined in table 5.4.4.2.2-3 are also applied.
NOTE 2: Attribute response status code is defined at table 5.4.4.2.2-3.

Table 5.4.4.2.2-2: Definition of special Upper Tester commands

Value Interpretation
Reset Inidicates that the IUT should reset

The rules for defining UtTrigger and UtTriggerAck primitives are:

  1. UtTrigger primitive is represented in requestPrimitive serialized in JSON format.

  2. UtTrigger primitive shall be interpreted as follows:

    • Any attribute/parameter containing a value shall be present and equal in the triggered request primitive.
    • Any attribute/parameter containing "UNINITIALIZED" value shall be present in the triggered request primitive.
    • Any other attribute/parameter shall comply with oneM2M TS-0004 [2].

  3. Parameters within UtTrigger are listed as following:

    • operation: (mandatory) operation type that IUT is triggered to perform.
    • resourceType: (optional) resource type of a target resource against which IUT is triggered to perform certain operation
    • to: (mandatory) target resource against which IUT is triggered to perform certain operation.
    • primitiveContent: (optional) represents the resource attributes that shall be included in the requestPrimitive.

Table 5.4.4.2.2-3: Definition of ResponseStatusCode for UtTriggerAck primitive

Response Status Code Description Response Status Code Value Interpretation
OK 2000 The SUT receives successfully the triggering message from Test System
BAD_REQUEST 4000 The SUT does not interpret correctly the UtTrigger primitive
NOTE: Only above two response status codes are allowed to use in UtTriggerAck primitive. NOTE: Only above two response status codes are allowed to use in UtTriggerAck primitive. NOTE: Only above two response status codes are allowed to use in UtTriggerAck primitive.
5.4.4.2.3 Control Communication Protocol

Protocol used for proceeding communications between Test System and Upper Tester Application is designated to the Hypertext Transfer Protocol (HTTP) protocol owning it is an application protocol that is widely supported by most all IoT devices and various intrinsic features such as persistent connection, ease of programming, flexibility, etc.

5.4.4.2.4 Control Message Serialization

Control commands that are wrapped within a request body of HTTP message shall be serialized into JavaScript Object Notation (JSON) because it is very lightweight and easy to parse and generate for machines.

5.4.5 acPort

The acPort is included in the oneM2M ATS in order to be able to control and configure the test adaptor for specific cases.

5.4.6 infoPort

The infoPort is included in the oneM2M ATS in order for the TTCN-3 test components to be able to exchange information such as last response primitives or request primitives received by a component, retrieved primitive contents.