Deployed 3dbee115 to v2.7.0 in public with MkDocs 1.5.3 and mike 2.0.0

public/v2.7.0/search/search_index.json

-{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"download/","title":"Download","text":"<p>Download baseline for TS-0019 version v2.7.0:</p> <p></p>"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Home","text":"<p>The present document contains the Abstract Test Suite (ATS) for oneM2M as defined in oneM2M TS-0001 [1] and oneM2M TS-0004 [2] in compliance with the relevant requirements and in accordance with the relevant guidance given in ISO/IEC 96467\ufffd[5]. The objective of the present document is to provide a basis for conformance tests for oneM2M products giving a high probability of interoperability between different manufacturers' equipment. The ISO standard for the methodology of conformance testing (ISO/IEC 96461\ufffd[3] and ISO/IEC\ufffd96462\ufffd[4]) as well as oneM2M TS-0015 Testing Framework\ufffd[i.2] are used as a basis for the test methodology.</p>"},{"location":"1/","title":"1    Scope","text":"<p>The present document contains the Abstract Test Suite (ATS) for oneM2M as defined in oneM2M TS-0001 [1] and oneM2M TS-0004 [2] in compliance with the relevant requirements and in accordance with the relevant guidance given in ISO/IEC 96467\ufffd[5]. The objective of the present document is to provide a basis for conformance tests for oneM2M products giving a high probability of interoperability between different manufacturers' equipment. The ISO standard for the methodology of conformance testing (ISO/IEC 96461\ufffd[3] and ISO/IEC\ufffd96462\ufffd[4]) as well as oneM2M TS-0015 Testing Framework\ufffd[i.2] are used as a basis for the test methodology.</p>"},{"location":"2.1/","title":"2.1    Normative references","text":"<p>References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. The following referenced documents are necessary for the application of the present document.</p> <p><code>[1]    oneM2M TS-0001: \"Functional Architecture\".</code></p> <p><code>[2]    oneM2M TS-0004: \"Service Layer Core Protocol\".</code></p> <p><code>[3]    ISO/IEC 9646-1 (1994): \"Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts\".</code></p> <p><code>[4]    ISO/IEC 9646-2 (1994): \"Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification\".</code></p> <p><code>[5]    ISO/IEC 9646-7 (1995): \"Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements\".</code></p> <p><code>[6]    ETSI ES 201 873-1 (V4.5.1): \"Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language\".</code></p> <p><code>[7]    oneM2M TS-0018: \"Test Suite Structure and Test Purposes\".</code></p>"},{"location":"2.2/","title":"2.2    Informative references","text":"<p>References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.</p> <p><code>[i.1]    oneM2M Drafting Rules.</code></p> <p>Note</p> <p>Available at http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf.</p> <p><code>[i.2]    oneM2M TS-0015: \"Testing Framework\".</code></p> <p><code>[i.3]    oneM2M TS-0025: \"Product profiles\".</code></p>"},{"location":"3.1/","title":"3.1    Terms","text":"<p>For the purposes of the present document, the terms given in ISO/IEC\ufffd96461\ufffd[3], ISO/IEC\ufffd96467\ufffd[5] and oneM2M TS-0015 [i.2] apply.</p>"},{"location":"3.2/","title":"3.2    Abbreviations","text":"<p>For the purposes of the present document, the following abbreviations apply:</p> <p><code>AE    Application Entity</code></p> <p><code>APT    Abstract Protocol Tester</code></p> <p><code>ATM    Abstract Test Method</code></p> <p><code>ATS    Abstract Test Suite</code></p> <p><code>CoAP    Constrained Application Protocol</code></p> <p><code>CSE    Common Service Entity</code></p> <p><code>HTTP    Hypertext Transfer Protocol</code></p> <p><code>IP    Internet Protocol</code></p> <p><code>IUT    Implementation Under Test</code></p> <p><code>IXIT    Implementation eXtra Information for Test</code></p> <p><code>JSON    JavaScript Object Notation</code></p> <p><code>MQTT    Message Queuing Telemetry Transport</code></p> <p><code>MTC    Main Test Component</code></p> <p><code>PA    Platform Adaptor</code></p> <p><code>PICS    Protocol Implementation Conformance Statement</code></p> <p><code>PTC    Paralell Test Component</code></p> <p><code>PX    PiXit</code></p> <p><code>SA    System Adaptor</code></p> <p><code>SUT    System Under Test</code></p> <p><code>TC    Test Case</code></p> <p><code>TCP    Transmission Control Protocol</code></p> <p><code>TP    Test Purposes</code></p> <p><code>TS    Test System</code></p> <p><code>TSS    Test Suite Structure</code></p> <p><code>TTCN    Tree and Tabular Combined Notation</code></p> <p><code>UDP    User Datagram Protocol</code></p> <p><code>UT    Upper Tester</code></p> <p><code>XML    eXtensible Markup Language</code></p>"},{"location":"4/","title":"4    Conventions","text":"<p>The key words \"Shall\", \"Shall not\", \"May\", \"Need not\", \"Should\", \"Should not\" in this document are to be interpreted as described in the oneM2M Drafting Rules [i.1].</p>"},{"location":"5.1/","title":"5.1    Abstract protocol tester","text":"<p>An abstract protocol tester (APT) is a process that provides behaviours for testing an IUT by emulating a peer IUT at the same layer, and enabling to address a single test objective. APTs used by the oneM2M test suite are described in figure 5.1-1. The test system will simulate valid and invalid protocol behaviour, and will analyse the reaction of the IUT.</p> <p> </p> <p> </p> <p>Figure 5.1-1: Abstract protocol testers - oneM2M</p> <p>As figure 5.1-1 illustrates, the corresponding ATS needs to use lower layers to establish a proper connection to the system under test (SUT) over a physical link (Lower layers link). Four different lower layers have been specified corresponding to the binding protocols considered in oneM2M: HTTP, CoAP, WebSocket and MQTT.</p>"},{"location":"5.2/","title":"5.2    Test Configuration","text":""},{"location":"5.2/#521-ae-test-configuration","title":"5.2.1    AE Test Configuration","text":"<p>Test configurations are defined to test different entities such as CSE and AE, etc. Figure 5.2.1-1 shows a AE test configuration which is mapped to CF03 in clause 6.3.3.3 in oneM2M TS0015\ufffd[i.2] and aligns with conformance test system architecture in clause 6.3.3.2 in oneM2M TS-0015 [i.2]. The TTCN-3 Test Component in Test System sends triggering actions or behaviour to the Upper Tester Application of SUT through upper tester transport link Ut while the IUT sends/receives oneM2M service primitives through Mca to/from CSE in Test System.</p> <p></p> <p>Figure 5.2.1-1: AE test configuration</p>"},{"location":"5.3/","title":"5.3    Test architecture","text":"<p>The approach for the implementation of an Abstract Protocol Tester selected in oneM2M follows the recommendation of the oneM2M Testing Framework oneM2M TS-0015 [i.2] where the TTCN-3 language and its architecture are recommended. Following this recommendation the oneM2M tester architecture comprises a non-platform dependent Test Suite, and a platform dependent part.</p> <p></p> <p>Note</p> <p>However, it can be implemented in a semi-independent manner, which will minimize the dependency to those elements.</p> <p>Figure 5.3-1: High level oneM2M Test Architecture</p> <ul> <li>oneM2M TTCN-3 Abstract Test Suite: the test suite is platform independent, and it is the cornerstone of the architecture. It allows a complete decoupling between the test suite and the rest of the test system. The test suite is composed of a complete set of test cases covering oneM2M requirements specified by oneM2M TS0001 [1] and oneM2M TS-0004 [2].</li> <li>oneM2M System Adaptor: this is the platform dependent part that includes adaptors and codecs (out of the scope of the present document). This part of the architecture definition depends on the specific platform (e.g.\ufffdWindows or Linux) and test tool on which the tester is going to run.</li> </ul> <p>Figure 5.3-2 shows the oneM2M TTCN-3 test architecture design used for the oneM2M ATS. The Test Suite needs to interact with the System Adaptor to implement the collection of TTCN-3 test cases that are intended to be used to test the oneM2M IUTs. The oneM2M TTCN-3 test cases implement the test algorithms specified in the TSS&amp;TP document oneM2M TS0018\ufffd[7], including verdict logic that allows pass/fail diagnosis. The test algorithms use the interfaces defined in [1] and [2] (mca, mcc) in order to:</p> <ol> <li>control the test event to be sent towards the IUT; and</li> <li>observe the test events received from the IUT.</li> </ol> <p>In TTCN-3 these two interfaces have been implemented through a set of logical TTCN-3 ports (mcaPort and mcaPortIn for mca interface, and mccPort and mccPortIn for mcc interface) which allows oneM2M message primitives exchange with the IUT.</p> <p></p> <p>Figure 5.3-2: oneM2M Test Architecture</p> <p>The oneM2M primitive messages have been mapped into TTCN-3 structure. Through this mapping, the TTCN-3 is able to build and send these messages, as well as receive them via the ports defined above. Additionally, the test cases are able to control and configure the test platform through a dedicated port called acPort while port utPort enables oneM2M TTCN-3 Test Component module to trigger specific action or behaviour on IUT. TTCN3 Test Components can also exchange information through a dedicated port called infoPort. To build up a tester, the test platform needs to be also developed (out of scope). This test platform is composed of three adaptation layers:</p> <ul> <li>PA (Platform Adaptor) layer functionality implements the communication between the TTCN-3 modules and external elements that constitute the test tool such as timers and external functions. The External functions are a powerful resources supported by TTCN-3 language. An External function is a function declared at the TTCN-3 level but implemented at the native level.</li> <li> <p>SA (System Adaptor) layer functionality is divided into two modules:</p> <ul> <li>oneM2M lower layers stack module implements the communication with the IUT and carries out the oneM2M primitives messages sent to or received from the IUT. This module is based on TCP or UDP depending on the binding supported by the IUT. The binding is a system adaptor parameter.</li> <li>Upper Tester Transport module implements functions that enable triggering specific actions or behaviour on the IUT.</li> </ul> </li> <li> <p>CODECS layer is the part of the tester to encode and decode messages between the TTCN-3 abstract internal data representation and the format required by the related base standard which the IUT understands. Several CODECS are required in oneM2M tester to cope with the bindings considered in oneM2M (HTTP, CoAP, MQTT) and the serialization methods (xml, json).</p> </li> </ul>"},{"location":"5.4/","title":"5.4    Ports and ASPs (Abstract Services Primitives)","text":""},{"location":"5.4/#540-introduction","title":"5.4.0    Introduction","text":"<p>The oneM2M ATS implements the following ports:</p> <ul> <li>The mcaPort and mcaPortIn</li> <li>The mccPort and mccPortIn</li> <li>The acPort</li> <li>The utPort</li> <li>The InfoPort</li> </ul>"},{"location":"5.4/#541-mcaport-mcaportin-mccport-mccportin","title":"5.4.1    mcaPort, mcaPortIn, mccPort, mccPortIn","text":"<p>These ports are used to send and receive the following message sets:</p> <ul> <li>Request Primitives messages in accordance with oneM2M TS-0004 [2].</li> <li>Response Primitives messages in accordance with oneM2M TS-0004 [2].</li> </ul> <p>Two primitives are currently defined for these ports indicated as table 5.4.1-1:</p> <ol> <li> <p>The M2MRequestPrimitive - to send or receive oneM2M messages to/from the IUT. Depending on the IUT to be tested:</p> <ol> <li>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.</li> <li>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.</li> </ol> </li> <li> <p>The M2MResponsePrimitive - to send or receive oneM2M messages to/from the IUT. Depending on the IUT to be tested:</p> <ol> <li>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.</li> <li>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.</li> </ol> </li> </ol> <p>Both primitives contain another parameters that permits to dynamically configure the test adaptor for every single sending. These parameters are:</p> <ul> <li>Host: IP address of the IUT</li> <li>XML Namespace</li> <li>Protocol binding</li> <li>Serialization</li> <li>ForceFields: used to force invalid or empty values to certain attributes. This behaviour shall be implemented by the System Adaptor.</li> </ul> <p>Table 5.4.1-1: Mapping of TTCN-3 Primitives to oneM2M Service Primitives</p> TTCN-3 Primitive oneM2M Message Direction IUT M2MRequestPrimitive Request Primitive AE M2MRequestPrimitive Request Primitive CSE M2MResponsePrimitive Response Primitive AE M2MResponsePrimitive Response Primitive CSE"},{"location":"5.4/#542-utport","title":"5.4.2    utPort","text":""},{"location":"5.4/#5420-introduction","title":"5.4.2.0    Introduction","text":"<p>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.</p>"},{"location":"5.4/#5421-usage-for-automated-ae-testing","title":"5.4.2.1    Usage for Automated AE Testing","text":"<p>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:</p> <ul> <li>TTCN-3 Test Component is able to configure the Test System and send standardized triggering commands to the SUT (Upper Tester Application).</li> <li>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).</li> </ul> <p>oneM2M service Primitive defined for utPort is listed as follows:</p> <ul> <li>The UtTrigger primitive is used to trigger upper layer events in IUT (i.e. sending oneM2M service primitives to Test System through Mca port).</li> <li>The UtTriggerAck primitive is used by IUT to send acknowledgement back to the Test System.</li> </ul> <p>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.</p> <p></p> <p>Figure 5.4.2.1-1: Example of automated AE test using Ut interface</p>"},{"location":"5.4/#5422-upper-tester-control-primitives","title":"5.4.2.2    Upper Tester Control Primitives","text":""},{"location":"5.4/#54221-introduction","title":"5.4.2.2.1    Introduction","text":"<p>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, UtTrigger and UtTriggerAck primitive.</p> <p>Table 5.4.2.2.1-1: Mapping of TTCN-3 Primitives to oneM2M Service Primitives</p> Upper Tester Control Message Type TTCN-3 Primitives Direction Direction Upper Tester Control Message Type TTCN-3 Primitives TS UT Trigger UtTrigger Primitive Trigger Acknowledgement UtTriggerAck Primitive"},{"location":"5.4/#54222-uttrigger-and-uttriggerack-primitives","title":"5.4.2.2.2    UtTrigger and UtTriggerAck Primitives","text":"<p>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.</p> <p></p> <p>Figure 5.4.2.2.2-1: Trigger message flow</p> <p>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.</p> <p>Table 5.4.2.2.2-1: UtTrigger and UtTriggerAck Primitive</p> Ut Control Primitive Mapping to oneM2M data types Description Reference Triggering Message HTTP message UtTrigger Primitive requestPrimitive ONLY essential parameters included for certain test caseSee note 1 oneM2MTS-0004 [2] EXAMPLE 1:If the test objective is to test \"Test System triggers IUT to execute a test case for creation of \\ 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 \\ 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 caseSee note 1 oneM2MTS-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\"}} RequestPOST /{SUT_UT_APPLICATION_URL} HTTP/1.1Host: {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 caseSee note 1 oneM2MTS-0004 [2] EXAMPLE 2: If the test objective is to test \"Test System triggers IUT to execute a test case for delete of a \\ 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 \\ resource.\", then the triggering message would be serialized as following. UtTrigger Primitive requestPrimitive ONLY essential parameters included for certain test caseSee note 1 oneM2MTS-0004 [2] Request{ \"m2m:rqp\" :{  \"op\": 4, //indicate DELETE operation  \"to\": {TARGET_AE_RESOURCE_ADDRESS}, //indicate Target AE resource address    \"rvi\": \"2a\"}} RequestPOST /{SUT_UT_APPLICATION_URL} HTTP/1.1Host: {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\"}} UtTriggerAck Primitive responsePrimitive ONLY responseStatusCode attribute includedSee 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. ResponseHTTP/1.1 200 OKX-M2M-RSC: 2000 NOTE 1:    Additional rules defined in table 5.4.2.2.2-3 are also applied.NOTE 2:  Attribute response status code is defined at table 5.4.2.2.2-3. NOTE 1:    Additional rules defined in table 5.4.2.2.2-3 are also applied.NOTE 2:  Attribute response status code is defined at table 5.4.2.2.2-3. NOTE 1:    Additional rules defined in table 5.4.2.2.2-3 are also applied.NOTE 2:  Attribute response status code is defined at table 5.4.2.2.2-3. NOTE 1:    Additional rules defined in table 5.4.2.2.2-3 are also applied.NOTE 2:  Attribute response status code is defined at table 5.4.2.2.2-3. NOTE 1:    Additional rules defined in table 5.4.2.2.2-3 are also applied.NOTE 2:  Attribute response status code is defined at table 5.4.2.2.2-3. NOTE 1:    Additional rules defined in table 5.4.2.2.2-3 are also applied.NOTE 2:  Attribute response status code is defined at table 5.4.2.2.2-3. <p>Table 5.4.2.2.2-2: Rules for defining UtTrigger and UtTriggerAck primitives</p> <ol> <li>UtTrigger primitive is represented in requestPrimitive serialized in JSON format. </li> <li>UtTrigger primitive shall be interpreted as follows:<ul> <li>Any attribute/parameter containing a value shall be present and equal in the triggered request primitive.</li> <li>Any attribute/parameter containing \"UNINITIALIZED\" value shall be present in the triggered request primitive.</li> <li>Any other attribute/parameter shall comply with oneM2M TS-0004 [2].</li> </ul> </li> <li>Parameters within UtTrigger are listed as following:<ul> <li>operation: (mandatory)operation type that IUT is triggered to perform.</li> <li>resourceType: (optional)resource type of a target resource against which IUT is triggered to perform certain operation</li> <li>to: (mandatory)target resource against which IUT is triggered to perform certain operation. </li> <li>primitiveContent:(optional)represents the resource attributes that shall be included in the requestPrimitive.</li> </ul> </li> </ol> <p>Table 5.4.2.2.2-3: Definition of ResponseStatusCode for UtTriggerAck primitive</p> 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."},{"location":"5.4/#54223-control-communication-protocol","title":"5.4.2.2.3    Control Communication Protocol","text":"<p>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.</p>"},{"location":"5.4/#54224-control-message-serialization","title":"5.4.2.2.4    Control Message Serialization","text":"<p>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.</p>"},{"location":"5.4/#543-acport","title":"5.4.3    acPort","text":"<p>The acPort is included in the oneM2M ATS in order to be able to control and configure the test adaptor for specific cases.</p>"},{"location":"5.4/#544-infoport","title":"5.4.4    infoPort","text":"<p>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.</p>"},{"location":"5.5/","title":"5.5    Test components","text":""},{"location":"5.5/#551-tester","title":"5.5.1    Tester","text":"<p>The Tester test component includes a set of ports, timers and variables that are common to the other defined components which are described in table 5.5.1-1.</p> <p>Table 5.5.1-1: Tester component elements</p> Name Instance type Element type Description acPort port AdapterControlPort Port that communicates with the adapter for sending configuration parameters infoPort port InfoPort Port between test components for exchanging information utPort port UpperTesterPort Port that communicates with the UT Application for triggering actions on the IUT tc_ac timer N/A Timer for the reception of a message tc_wait timer N/A Timer for the reaction of the IUT to an upper tester primitive tc_done Timer N/A Timer for waiting completion of a component behaviour vc_config variable Configurations Configuration being used for the given test case vc_testSystemRole variable TestSystemRole Role of the test component vc_componentRegistered variable boolean Flag to indicate that AeSimu/CseSimu is registered to IUT vc_resourcesList variable MyResourcesList List of all resources created by the test system on the IUT vc_resourcesIndexToBeDeleted variable IntegerList List of indexes of resources created by the test system on the IUT that need to be deleted vc_acpIndex variable integer Index of accessControlPolicy resource used by the test system by default (when required) vc_request variable MsgIn Latest request primitive received/sent vc_response variable MsgIn Latest response primitive received/sent vc_aeSimu variable default Reference to the default behaviour for an AeSimu component vc_cseSimu variable default Reference to the default behaviour for an CseSimu component vc_primitiveContentRetrievedResource variable PrimitiveContent Latest content of a RETRIEVE operation vc_myInterfaces variable Interfaces Parameters for the ports of the given component:Port (mcaPort, mcaPortIn, mccPort, mccPortIn)Host (SUT IP address :port)Protocol bindingSerialization <p>Note that vc_aeSimu and vc_cseSimu are not common to the other defined test components, but those variables are required in Tester for the correct activation/deactivation of default behaviours.</p>"},{"location":"5.5/#552-aesimu","title":"5.5.2    AeSimu","text":"<p>The AeSimu test component extends the Tester component by adding elements specific to an AE entity. Table 5.5.2-1 summarizes those elements.</p> <p>Table 5.5.2-1: AeSimu component elements</p> Name Instance type Element type Description mcaPort port OneM2MPort Port that implements the mca interface when test system is the client (sending requests) mcaPortIn port OneM2MPort Port that implements the mca interface when test system is the server (receiving requests) vc_ae2 test component AeSimu Reference to the AE2 component when required vc_cse1 test component CseSimu Reference to the CSE1 component when CF02 is used vc_auxiliaryAe2Up variable boolean Flag to indicate that AE2 component has been started vc_aeIndex variable integer Index of the AE resource in vc_resourcesList created by the AeSimu component"},{"location":"5.5/#553-csesimu","title":"5.5.3    CseSimu","text":"<p>The CseSimu test component extends the Tester component by adding elements specific to an CSE entity. Table 5.5.3-1 summarizes those elements.</p> <p>Table 5.5.3-1: CseSimu component elements</p> Name Instance type Element type Description mcaPort port OneM2MPort Port that implements the mca interface when test system is the client (sending requests) mcaPortIn port OneM2MPort Port that implements the mca interface when test system is the server (receiving requests) mccPort port OneM2MPort Port that implements the mcc interface when test system is the client (sending requests) mccPortIn port OneM2MPort Port that implements the mcc interface when test system is the server (receiving requests) vc_ae1 test component AeSimu Reference to the AE1 component when CF02 (CseSimu as master) is used vc_localResourcesList variable MyResourcesList List of all resources created by the IUT on the test system vc_localRemoteCseIndex variable integer Index of the remoteCSE resource in vc_localResourcesList representing the IUT (CSE) vc_remoteCseIndex variable integer Index of the remoteCSE resource in vc_resourcesList representing the CseSimu component vc_cSEBaseIndex variable integer Index of the CSEBase resource in vc_localResourcesList of the CseSimu component vc_cseType variable CseTypeID CSE type of the test system (default is MN)"},{"location":"5.6/","title":"5.6    Test strategy","text":"<p>This clause introduces the test strategy being used for the TTCN-3 test cases. The chosen strategy permits to have a clear structure of the code that facilitates an easy navigation throw the different test steps. The use of the TTCN-3 MTC and PTC(s) is as depicted in figure 5.6-1.</p> <p></p> <p>Figure 5.6-1: Use of TTCN-3 components</p> <p>At the start of the test case execution, the MTC is created. Then, the MTC executes the following steps:</p> <ul> <li>Step 1) initialization of the master PTC.</li> <li>Step 2) initialization of some parameters if required for the permutation test cases.</li> <li> <p>Step 3) running of the appropriate function on the master PTC. The function run on the master PTC implements a given Test Purpose. Such function follows a code structure as indicated here below:</p> <ul> <li>Local Variables, declaration of local variables.</li> <li>Test Control, checking IUT capability parameters required for the proper execution of the test.</li> <li>Test Component Configuration, that initializes the given test component and other test components acting as slave PTC(s) as required by a given configuration.</li> <li>Test adapter configuration, that configures the test adapter throw the acPort if required.</li> <li>Preamble, that implements the necessary test steps as described in the Initial conditions of a Test Purpose. It may also implement additional test steps which are required for the correct execution of the test.</li> <li>Test body, that implements the test steps as described in the Expected behaviour of a Test Purpose.</li> <li>Postamble, that implements the necessary test steps to bring the IUT back to the initial state.</li> <li>Tear down, that finalizes properly the TTCN-3 ports used by the different test components depending on the configuration.</li> </ul> </li> </ul> <p>While master PTC follows the test structure described above, slave PTC(s) run only certain procedures, usually one by one, as mandated by the master PTC. A procedure usually implements a oneM2M request-response exchange between a given PTC and the IUT, although it can implement any other specific action (sending or reception of a message, several request-response exchanges, etc.).</p> <ul> <li>Step 4) checking of some parameters if required for the permutation test cases.</li> </ul> <p>This test strategy may slightly vary for certain cases where specific requirements need to be fulfilled.</p>"},{"location":"6/","title":"6    Untestable Test Purposes","text":"<p>Void.</p>"},{"location":"7.0/","title":"7.0    Introduction","text":"<p>The ATS conventions are intended to give a better understanding of the ATS but they also describe the conventions made for the development of the ATS. These conventions shall be considered during any later maintenance or further development of the ATS. The ATS conventions contain two clauses, the naming conventions and the implementation conventions. The naming conventions describe the structure of the naming of all ATS elements. The implementation conventions describe the functional structure of the ATS. To define the ATS, the guidelines of oneM2M TS-0015 [i.2] were considered.</p>"},{"location":"7.1/","title":"7.1    Testing conventions","text":""},{"location":"7.1/#711-testing-states","title":"7.1.1    Testing states","text":""},{"location":"7.1/#7111-initial-state","title":"7.1.1.1    Initial state","text":"<p>All test cases start with the function f_preamble_XYZ. This function brings the IUT in an \"initialized\" state by performing some actions such as registration of AE, creation of auxiliary access control policy resource, creation of additional needed resources.</p>"},{"location":"7.1/#7112-final-state","title":"7.1.1.2    Final state","text":"<p>All test cases end with the function f_postamble_XYZ. This function brings the IUT back in an \"idle\" state which means deletion of all created resources being used by the test case so that next test case execution is not disturbed. As necessary, further actions may be included in the f_postamble functions.</p>"},{"location":"7.2/","title":"7.2    Naming conventions","text":""},{"location":"7.2/#721-general-guidelines","title":"7.2.1    General guidelines","text":"<p>This test suite follows the naming convention guidelines provided in oneM2M TS-0015 [i.2]. The naming convention is based on the following underlying principles:</p> <ul> <li>in most cases, identifiers should be prefixed with a short alphabetic string (specified in table\ufffd7.2.1-1) indicating the type of TTCN3 element it represents;</li> <li>suffixes should not be used except in those specific cases identified in table 7.2.1-1;</li> <li>prefixes and suffixes should be separated from the body of the identifier with an underscore (\"_\");</li> </ul> <p><code>EXAMPLE 1:    c_sixteen, t_wait.</code></p> <ul> <li>only module names, data type names and module parameters should begin with an uppercase letter. All other names (i.e. the part of the identifier following the prefix) should begin with a lowercase letter;</li> <li>the start of second and subsequent words in an identifier should be indicated by capitalizing the first character. Underscores should not be used for this purpose.</li> </ul> <p><code>EXAMPLE 2:    f_initialState.</code></p> <p>Table\ufffd7.2.1-1 specifies the naming guidelines for each element of the TTCN3 language indicating the recommended prefix, suffixes (if any) and capitalization.</p> <p>Table 7.2.1-1: TTCN-3 generic naming conventions</p> Language element Naming convention Prefix Example identifier Module Use upper-case initial letter none OneM2M_Templates Group within a module Use lower-case initial letter none messageGroup Data type Use upper-case initial letter none SetupContents Message template Use lower-case initial letter m_ m_setupInit Message template with wildcard or matching expression Use lower-case initial letters mw_ mw_anyUserReply Signature template Use lower-case initial letter s_ s_callSignature Port instance Use lower-case initial letter none signallingPort Test component instance Use lower-case initial letter none userTerminal Constant Use lower-case initial letter c_ c_maxRetransmission Constant (defined within component type) Use lower-case initial letter cc_ cc_minDuration External constant Use lower-case initial letter cx_ cx_macId Function Use lower-case initial letter f_ f_authentication() External function Use lower-case initial letter fx_ fx_calculateLength() Altstep (incl. Default) Use lower-case initial letter a_ a_receiveSetup() Test case Use ETSI numbering TC_ TC_COR_0009_47_ND Variable (local) Use lower-case initial letter v_ v_macId Variable (defined within a component type) Use lower-case initial letters vc_ vc_systemName Timer (local) Use lower-case initial letter t_ t_wait Timer (defined within a component) Use lower-case initial letters tc_ tc_authMin Module parameters for PICS Use all upper case letters PICS_ PICS_DOOROPEN Module parameters for other parameters Use all upper case letters PX_ PX_TESTER_STATION_ID Formal Parameters Use lower-case initial letter p_ p_macId Enumerated Values Use lower-case initial letter e_ e_syncOk"},{"location":"7.2/#722-onem2m-specific-ttcn-3-naming-conventions","title":"7.2.2    oneM2M specific TTCN-3 naming conventions","text":"<p>Next to such general naming conventions, table 7.2.2-1 shows specific naming conventions that apply to the oneM2M TTCN-3 ATS.</p> <p>Table\ufffd7.2.2-1: oneM2M specific TTCN-3 naming conventions</p> Language element Naming convention Prefix Example identifier oneM2M Module Use upper-case initial letter OneM2M_ OneM2M_Testcases_ Module containing oneM2M types Use upper-case initial letter OneM2M_Types OneM2M_Types Module containing types and values Use upper-case initial letter OneM2M_TypesAndValues OneM2M_TypesAndValues Module containing Templates Use upper-case initial letter OneM2M_Templates OneM2M_Templates Module containing test cases Use upper-case initial letter OneM2M_Testcases OneM2M_Testcases Module containing functions Use upper-case initial letter OneM2M_Functions OneM2M_Functions Module containing external functions Use upper-case initial letter OneM2M_ExternalFunctions OneM2M_ExternalFunctions Module containing components, ports and message definitions Use upper-case initial letter OneM2M_TestSystem OneM2M_TestSystem Module containing module parameters Use upper-case initial letter OneM2M_Pixits OneM2M_Pixits"},{"location":"7.2/#723-usage-of-log-statements","title":"7.2.3    Usage of Log statements","text":"<p>All TTCN-3 log statements use the following format using the same order:</p> <ul> <li>The TTCN-3 test case or function identifier in which the log statement is defined.</li> <li>One of the categories of log: INFO, WARNING, ERROR, TIMEOUT, NONE.</li> <li>Free text.</li> </ul> <p><code>EXAMPLE 1:    log(\"f_utInitializeIut: INFO: IUT initialized\");</code></p> <p>Furthermore, the following rules are applied too:</p> <ul> <li>All TTCN-3 setverdict statements are combined (as defined in TTCN-3 - ETSI\ufffdES 201 873-1 [6]) with a log statement following the same above rules (see example 2).</li> </ul> <p><code>EXAMPLE 2:    setverdict(pass, \"TC_ONEM2M_CSE_DMR_CRE_001: Received correct message\");</code></p>"},{"location":"7.2/#724-test-case-tc-identifier","title":"7.2.4    Test Case (TC) identifier","text":"<p>Table 7.2.4-1: TC naming convention</p> Identifier: TC_\\\\\\\\\\ \\ = root ONEM2M oneM2M \\ = group CSE CSE testing AE AE testing \\ = subgroup REG Registration DMR Data Management and Repository SUB Subscription and Notification GMG Group Management DIS Discovery LOC Location DMG Device Management CMDH Communication Management and Delivery Handling SEC Security \\ = sequential number 001 to 999 \\ = permutation P1_P2_..PN Permutation parameters <p><code>EXAMPLE:    TP identifier:    TP/oneM2M/CSE/DMR/CRE/001&lt;br/&gt;TC identifier:    TC_ONEM2M_CSE_DMR_CRE_001.</code></p>"},{"location":"7.3/","title":"7.3    IXIT","text":"<p>The following parameters are used by the oneM2M ATS for the correct execution of the test cases.</p> <p>Table 7.3-1: oneM2M ATS IXITs</p> GROUP IXIT NAME DESCRIPTION DEFAULT VALUE IutParameters PX_IN_CSE MN-CSE true IutParameters PX_MN_CSE IN-CSE false IutParameters PX_ASN_CSE ASN-CSE false IutParameters PX_SUT_ADDRESS SUT address \"127.0.0.1:8080\" IutParameters PX_UT_IMPLEMENTED Upper Tester implemented false IutParameters PX_CSE_NAME IUT CSE Name \"cseName\" IutParameters PX_CSE_ID IUT CSE-ID with SP-relative-CSE-ID format (relative) according to oneM2M TS-0001 [1], table 7.2-1 \"/cseId\" IutParameters PX_CSE_RESOURCE_ID IUT CSE resource ID with Unstructured-CSE-relative-Resource-ID (relative) format according to oneM2MTS-0001 [1], table 7.2-1 \"cseResourceId\" IutParameters PX_SP_ID IUT M2M-SP-ID with M2M-SP-ID format (absolute) according to oneM2M TS-0001 [1], table 7.2-1 Unstructured-CSE-relative -Resource-ID \"//om2m.org\" IutParameters PX_SUPER_AE_ID AE-ID with privileges to CREATE at the IUT CSEBase with AE-ID-Stem format (relative) according to oneM2M TS-0001 [1], table 7.2-1 \"admin:admin\" IutParameters PX_SUPER_CSE_ID CSE-ID with privileges to CREATE at the IUT CSEBase with SPrelative-CSE-ID format (relative) according to oneM2M TS-0001 [1], table 7.2-1 \"/admin:admin\" IutParameters PX_ALLOWED_C_AE_IDS {\"C-AllowedAeId\"} IutParameters PX_NOT_ALLOWED_C_AE_IDS {\"C-NotAllowedAeId\"} IutParameters PX_ALLOWED_S_AE_IDS {\"S-AllowedAeId\"} IutParameters PX_NOT_ALLOWED_S_AE_IDS {\"S-NotAllowedAeId\"} IutParameters PX_NOT_ALLOWED_APP_ID \"NotAllowedAppId\" IutParameters PX_ADDRESSING_METHOD Addressing method e_hierarchical IutParameters PX_PRIMITIVE_SCOPE Primitive scope e_cseRelative IutParameters PX_WS_PROTOCOL WebSocket protocol \"oneM2M.R2.0.xml\" IutParameters PX_REQUEST_URI WebSocket context \"/\" IutParameters PX_HOSTING_CSE_ID Hosting CSE-ID for MQTT \"CSE-ID\" IutParameters PX_CREDENTIAL_ID Credential-ID for MQTT \"admin:admin\" IutParameters PX_XML_NAMESPACE XML Namespace \"m2m=\"\"http://www.onem2m.org/xml/protocols\"\"\" IutParameters PX_ACOR AccessControlOriginators {\"all\"} IutParameters PX_TCONFIG_IUT Time to configure IUT after a requested action 10.0 TesterParameters PX_TS_AE1 AE1 component settings aeIdStem = \"\"appId = \"NMyApp1Id\"mcaPort and mcaPortIn settings which include per port the following info:Binding: - bindingProtocol - bindingDesc:        - tsAddress     - localPort     - sutAddress        - remotePortSerialization TesterParameters PX_TS_AE2 AE2 component settings aeIdStem = \"\"appId = \"NMyApp2Id\"mcaPort and mcaPortIn settings which include per port the following info:Binding: - bindingProtocol - bindingDesc:        - tsAddress     - localPort     - sutAddress        - remotePortSerialization TesterParameters PX_TS_CSE1 CSE1 component settings cseName = \"CSE1_NAME\"cseId = \"/CSE1_ID\"cseResourceId = \"CSE1_RESOURCE_ID\"spId = \"//onem2m.org\"supportedResourceType = {int1, int2, int3, int16}mcaPort, mcaPortIn, mccPort and mccPortIn settings which include per port the following info:Binding: - bindingProtocol - bindingDesc:       - tsAddress     - localPort     - sutAddress        - remotePortSerialization PX_TS_UT UpperTester settings url = \"http://127.0.0.1:43000/\" ExecutionParameters PX_RESOURCES_TO_BE_DELETED (For debugging purposes) {\"MyAe\", \"MyAccessControlPolicyResource\", \"SubscriptionVerificationAcp\", \"MyAcp\", \"MyRemoteCSEResource\"} ExecutionParameters PX_RUN_POSTAMBLE (For debugging purposes) true"},{"location":"8/","title":"8    TTCN-3 Verifications","text":"<p>The principles for Verifying the TTCN-3 test code are given in oneM2M TS-0015 [i.2].</p> <p>All test cases provided with the present document in annex A which correspond to at least one of the product profiles defined in oneM2M TS-0025 [i.3] have been verified at the time of publication of the present document which corresponds with the TTCN-3 code gitlab tag provided in annex A.</p>"},{"location":"A.1/","title":"A.1    Electronic annex, zip file with TTCN-3 code","text":"<p>This ATS has been produced using the Testing and Test Control Notation (TTCN) according to ETSI\ufffdES 201 873-1 [6].</p> <p>This test suite has been compiled error-free using two different commercial TTCN-3 compilers. The TTCN-3 library modules, which form parts of the present document, are contained in the following gitLab tag:</p> <p>https://git.onem2m.org/TST/ATS/tags/TS-0019-baseline-v2_7_0 </p>"},{"location":"B/","title":"Annex B (informative):Bibliography","text":"<ul> <li>ISO/IEC 9646-6 (1994): \"Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 6: Protocol profile test specification\".</li> <li>oneM2M TS-0017: \"Implementation Conformance Statement\".</li> <li>oneM2M TS-0031: \"Feature catalogue\".</li> </ul>"},{"location":"download/","title":"Download","text":"<p>Download baseline for TS-0019 version v2.7.0:</p> <p></p>"}]}
\ No newline at end of file

public/v2.7.0/sitemap.xml

 <?xml version="1.0" encoding="UTF-8"?>
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/1/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/2.1/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/2.2/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/2/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/3.1/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/3.2/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/3/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/4/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/5.1/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/5.2/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/5.3/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/5.4/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/5.5/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/5.6/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/5/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/6/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/7.0/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/7.1/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/7.2/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/7.3/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/7/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/8/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/A.1/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/A/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
+    <url>
+         <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/B/</loc>
+         <lastmod>2024-04-19</lastmod>
+         <changefreq>daily</changefreq>
+    </url>
     <url>
          <loc>https://specifications.onem2m.org/ts-0019/v2.7.0/download/</loc>
-         <lastmod>2024-04-18</lastmod>
+         <lastmod>2024-04-19</lastmod>
          <changefreq>daily</changefreq>
     </url>
 </urlset>
\ No newline at end of file