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:
    • 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.
    • 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:
    • 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.
    • 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
←→ CSE
M2MResponsePrimitive
Respomse Primitive
←→ AE
←→ CSE

5.4.2 utPort

5.4.2.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.2.1.

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

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

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

5.4.2.2 Upper Tester Control Primitives

5.4.2.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.2.2.1-1, U tTrigger and U tTriggerAck primitive.

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

Upper Tester Control Message Type TTCN-3 Primitives Direction
Trigger UtTrigger Primitive TS → UT
Trigger Acknowledgement UtTriggerAck Primitive UT → TS
5.4.2.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.2.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: Trigger message flow

Figure 5.4.2.2.2-1: Trigger message flow

Table 5.4.2.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.2.2.2-1: UtTrigger and UtTriggerAck Primitive

Ut Control Primitive message Mapping to oneM2M data types Description
Reference
Triggering Message
HTTP
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 triggers IUT to execute a test case for creation of < AE > with abels attribute under a CSEBase resource\", then triggering message would be serialized as following.
N/A
Special upper tester commands
N/A
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"
}
}
EXAMPLE 2: If the test objective is to test "Test System triggers IUT to execute a test case for delete of < AE > resource\", then triggering message would be serialized as following.
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 peration
"to":{TARGET_AE_RESOURCE_ADDRESS},
//indicate Target AE resource address
"rvi": "2a"
}
}
"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 aresponse status code, and the response status code for the triggering operation can only be set to either 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.

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.2.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.
5.4.2.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 and various intrinsic features such as persistent connection, ease of programming, flexibility, etc.

5.4.2.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.3 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.4 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.