diff --git a/TS-0019-Abstract_Test_Suite_&_implementation_eXtra_Information_for_Test-V2_0_0.md b/TS-0019-Abstract_Test_Suite_&_implementation_eXtra_Information_for_Test-V2_0_0.md
index 6397a5395361b412c625f34eb121d0850965927d..7249724f81f546dedded202186f2966fd71fef76 100644
--- a/TS-0019-Abstract_Test_Suite_&_implementation_eXtra_Information_for_Test-V2_0_0.md
+++ b/TS-0019-Abstract_Test_Suite_&_implementation_eXtra_Information_for_Test-V2_0_0.md
@@ -1,4 +1,5 @@
 
+![media/image1.png](media/image1.png)
 
 
 
@@ -21,176 +22,191 @@ This Specification is provided for future development work within oneM2M only. T
 The present document has not been subject to any approval process by the oneM2M Partners Type 1.  Published oneM2M specifications and reports for implementation should be obtained via the oneM2M Partners' Publications Offices.
 
 
-
-About oneM2M 
+<br/>About oneM2M 
 The purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide. 
 More information about oneM2M may be found at:  http//www.oneM2M.org
 Copyright Notification
-� 2018, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
+© 2018, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA, TTC).
 All rights reserved.
 The copyright extends to reproduction in all media.
 
 Notice of Disclaimer & Limitation of Liability 
 The information provided in this document is directed solely to professionals who have the appropriate degree of experience to understand and interpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations. No recommendation as to products or vendors is made or should be implied. 
 NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS. NO oneM2M PARTNER TYPE 1 SHALL BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY THAT PARTNER FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM, AND IN NO EVENT SHALL oneM2M BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. oneM2M EXPRESSLY ADVISES ANY AND ALL USE OF OR RELIANCE UPON THIS INFORMATION PROVIDED IN THIS DOCUMENT IS AT THE RISK OF THE USER.
-
-Contents
-5.4.2.2.1	Introduction	11
-5.4.2.2.2	UtTrigger and UtTriggerAck Primitives	11
-5.4.2.2.3	Control Communication Protocol	14
-5.4.2.2.4	Control Message Serialization	14
-Annex A (normative):	TTCN-3 library modules	20
-Annex B (informative):	Bibliography	21
+<br/>Contents
+Annex A (normative):    TTCN-3 library modules    20
+Annex B (informative):    Bibliography    21
 
 
-# 1	Scope
-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�[6].
+# <br/>1    Scope
+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 [6].
 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�[3] and ISO/IEC�96462�[4]) as well as oneM2M TS-0015 Testing Framework�[i.2] are used as a basis for the test methodology.
+The ISO standard for the methodology of conformance testing (ISO/IEC 96461 [3] and ISO/IEC 96462 [4]) as well as oneM2M TS-0015 Testing Framework [i.2] are used as a basis for the test methodology.
 
-# 2	References
+# 2    References
 
-## 2.1	Normative references
+## 2.1    Normative references
 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.
-- [1]	oneM2M TS-0001: "Functional architecture".
-- [2]	oneM2M TS-0004: "Service Layer Core Protocol".
-- [3]	ISO/IEC 9646-1 (1994): "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts".
-- [4]	ISO/IEC 9646-2 (1994): "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification".
-- [6]	ISO/IEC 9646-7 (1995): "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements".
-- [7]	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".
-- [9]	oneM2M TS-0018: "Test Suite Structure and Test Purposes".
-
-## 2.2	Informative references
+
+`[1]    oneM2M TS-0001: "Functional architecture".`
+`[2]    oneM2M TS-0004: "Service Layer Core Protocol".`
+`[3]    ISO/IEC 9646-1 (1994): "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts".`
+`[4]    ISO/IEC 9646-2 (1994): "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 2: Abstract Test Suite specification".`
+`[6]    ISO/IEC 9646-7 (1995): "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements".`
+`[7]    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".`
+`[9]    oneM2M TS-0018: "Test Suite Structure and Test Purposes".`
+
+## 2.2    Informative references
+
 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.
-> NOTE:	While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.
+> NOTE:    While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.
+
 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.
-- [i.1]	oneM2M Drafting Rules.
-> NOTE:	Available at .
-- [i.2]	oneM2M TS-0015: "Testing Framework".
-- [i.3]	oneM2M TS-0025: "Product profiles".
 
-# 3	Definitions and abbreviations
+`[i.1]    oneM2M Drafting Rules.`
+> NOTE:    Available at [http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf](http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf).
+
+`[i.2]    oneM2M TS-0015: "Testing Framework".`
+`[i.3]    oneM2M TS-0025: "Product profiles".`
+
+# 3    Definitions and abbreviations
+
+## 3.1    Definitions
 
-## 3.1	Definitions
-For the purposes of the present document, the terms and definitions given in ISO/IEC�96461�[3], in ISO/IEC�96467�[6] and in oneM2M TS-0015 [i.2] apply.
+For the purposes of the present document, the terms and definitions given in ISO/IEC 96461 [3], in ISO/IEC 96467 [6] and in oneM2M TS-0015 [i.2] apply.
 
-## 3.2	Abbreviations
+## 3.2    Abbreviations
 For the purposes of the present document, the following abbreviations apply:
-- AE	Application entity
-- APT	Abstract Protocol Tester
-- ATM	Abstract Test Method
-- ATS	Abstract Test Suite
-- CoAP	Constrained Application Protocol
-- CSE	Common Service Entity
-- HTTP	Hypertext Transfer Protocol
-- IP	Internet Protocol
-- IUT	Implementation Under Test
-- MQTT	Message Queuing Telemetry Transport
-- PA	Platform Adaptor
-- PICS	Protocol Implementation Conformance Statement
-- PX	PiXit
-- SA	System Adaptor
-- SUT	System Under Test
-- TC	Test Case
-- TP	Test Purposes
-- TSS	Test Suite Structure
-- TTCN	Tree and Tabular Combined Notation
-- UT	Upper Tester
-
-# 4	Conventions 
+
+`AE    Application entity`
+`APT    Abstract Protocol Tester`
+`ATM    Abstract Test Method`
+`ATS    Abstract Test Suite`
+`CoAP    Constrained Application Protocol`
+`CSE    Common Service Entity`
+`HTTP    Hypertext Transfer Protocol`
+`IP    Internet Protocol`
+`IUT    Implementation Under Test`
+`MQTT    Message Queuing Telemetry Transport`
+`PA    Platform Adaptor`
+`PICS    Protocol Implementation Conformance Statement`
+`PX    PiXit`
+`SA    System Adaptor`
+`SUT    System Under Test`
+`TC    Test Case`
+`TP    Test Purposes`
+`TSS    Test Suite Structure`
+`TTCN    Tree and Tabular Combined Notation`
+`UT    Upper Tester`
+
+# 4    Conventions 
+
 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]
 
-# 5	Abstract Test Method (ATM)
+# 5    Abstract Test Method (ATM)
 
-## 5.1	Abstract protocol tester
+## 5.1    Abstract protocol tester
 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.
-                           
 
-Figure 5.1-1: Abstract protocol testers - oneM2M
+![media/image2.png](media/image2.png)                           ![media/image3.png](media/image3.png)
+
+![media/image4.png](media/image4.png)
+
+**Figure 5.1-1: Abstract protocol testers - oneM2M**
+
+
 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). Three different lower layers have been specified corresponding to the binding protocols considered in oneM2M: HTTP, CoAP and MQTT 
 
-## 5.2	Test Configuration
+## 5.2    Test Configuration
 
-### 5.2.1	AE Test Configuration
+### 5.2.1    AE Test Configuration
 Test configurations are defined to test different entities such as CSE and AE, etc.
 Figure X shows a AE test configuration which is mapped to CF03 in clause 6.3.3.3 in oneM2M TS-0015 [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.
 
-Figure 5.2.1-1: AE test configuration
+![media/image5.emf](media/image5.emf)
+
+**Figure 5.2.1-1: AE test configuration**
+
+
+## 5.3    Test architecture
 
-## 5.3	Test architecture
 The approach for the implementation of an Abstract Protocol Tester selected in oneM2M follows the recommendation of the oneM2M Testing Framework [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. 
 
-NOTE:	However, it can be implemented in a semi-independent manner, which will minimize the dependency to those elements. 
+![media/image6.png](media/image6.png)
+NOTE:    However, it can be implemented in a semi-independent manner, which will minimize the dependency to those elements. 
+
+
+**Figure 5.3-1: High level oneM2M Test Architecture**
 
-Figure 5.3-1: High level oneM2M Test Architecture
 
 - 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 [1] and [2]. 
+- oneM2M System Adaptor: this is the platform dependent part that includes adaptors and codecs (out of the scope of this document). This part of the architecture definition depends on the specific platform (e.g. Windows or Linux) and test tool on which the tester is going to run. 
 
-- oneM2M System Adaptor: this is the platform dependent part that includes adaptors and codecs (out of the scope of this document). This part of the architecture definition depends on the specific platform (e.g.�Windows or Linux) and test tool on which the tester is going to run. 
 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&TP document [9], including verdict logic that allows pass/fail diagnosis. 
 The test algorithms use the interfaces defined in [1] and [2] (mca, mcc) in order to:
-control the test event to be sent towards the IUT; and 
-observe the test events received from the IUT. 
+
+1. control the test event to be sent towards the IUT; and 
+1. observe the test events received from the IUT. 
+
 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.
+![media/image7.emf](media/image7.emf)
+
+**Figure 5.3-2: oneM2M Test Architecture**
+
 
-Figure 5.3-2: oneM2M Test Architecture
 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. TTCN-3 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:
 
 - 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.
-
 - SA (System Adaptor) layer functionality is divided into two modules:
 
     - 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.
-
     - Upper Tester Transport module implements functions that enable triggering specific actions or behaviour on the IUT.
 
 - 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).
 
-## 5.4	Ports and ASPs (Abstract Services Primitives)
+## 5.4    Ports and ASPs (Abstract Services Primitives)
+
+### 5.4.0    Introduction
 
-### 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
+### 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 [2].
+
 Two primitives are currently defined for these ports indicated as table 5.4.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.
+
+     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.
+     1. 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.
+
 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.
+
+     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.
+     1. 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**
@@ -204,30 +220,35 @@ Both primitives contain another parameters that permits to dynamically configure
 
 
 
-### 5.4.2	utPort
 
-#### 5.4.2.0	Introduction
+### 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
+#### 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
+![media/image8.emf](media/image8.emf)
+
+**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	Upper Tester Control Primitives
+##### 5.4.2.2.1    Introduction
 
-##### 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, UtTrigger and UtTriggerAck primitive.
 
@@ -241,10 +262,14 @@ The upper tester triggering message type maps to particular message formats for
 
 
 
-##### 5.4.2.2.2	UtTrigger and UtTriggerAck Primitives 
+##### 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-2 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.
 
 
@@ -280,57 +305,57 @@ Table 5.4.2.2.2-2 defines UtTrigger and UtTriggerAck primitives including oneM2M
 
 
 
-##### 5.4.2.2.3	Control Communication Protocol
+##### 5.4.2.2.3    Control Communication Protocol
 Protocol used for proceeding communications between TS 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.2.2.4	Control Message Serialization
+##### 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
+### 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
+### 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. 
 
-# 6	Untestable Test Purposes
+# 6    Untestable Test Purposes
 Void.
 
-# 7	ATS Conventions
+# 7    ATS Conventions
 
-## 7.0	Introduction
+## 7.0    Introduction
 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.
 
-## 7.1	Testing conventions
+## 7.1    Testing conventions
 
-### 7.1.1	Testing states
+### 7.1.1    Testing states
 
-#### 7.1.1.1	Initial state
+#### 7.1.1.1    Initial state
 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.
 
-#### 7.1.1.2	Final state
+#### 7.1.1.2    Final state
 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.
 
-## 7.2	Naming conventions
+## 7.2    Naming conventions
 
-### 7.2.1	General guidelines
+### 7.2.1    General guidelines
 This test suite follows the naming convention guidelines provided in [i.2].
 The naming convention is based on the following underlying principles:
 
-- in most cases, identifiers should be prefixed with a short alphabetic string (specified in table�7.2.1-1) indicating the type of TTCN3 element it represents;
-
+- in most cases, identifiers should be prefixed with a short alphabetic string (specified in table 7.2.1-1) indicating the type of TTCN3 element it represents;
 - suffixes should not be used except in those specific cases identified in table 7.2.1-1.
-
 - prefixes and suffixes should be separated from the body of the identifier with an underscore ("_");
-- EXAMPLE 1:	c_sixteen, t_wait.
 
-- 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;
+`EXAMPLE 1:    c_sixteen, t_wait.`
 
+- 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;
 - 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.
-- EXAMPLE 2:	f_initialState.
-Table�7.2.1-1 specifies the naming guidelines for each element of the TTCN3 language indicating the recommended prefix, suffixes (if any) and capitalization.
+
+`EXAMPLE 2:    f_initialState.`
+
+Table 7.2.1-1 specifies the naming guidelines for each element of the TTCN3 language indicating the recommended prefix, suffixes (if any) and capitalization.
 
 **Table7.2.1-1: TTCN-3 generic naming conventions**
 
@@ -362,10 +387,10 @@ Table�7.2.1-1 specifies the naming guidelines for each element of the TTCN3 la
 
 
 
-### 7.2.2	oneM2M specific TTCN-3 naming conventions
-Next to such general naming conventions, table�7.2.2-1 shows specific naming conventions that apply to the oneM2M TTCN-3 ATS.
+### 7.2.2    oneM2M specific TTCN-3 naming conventions
+Next to such general naming conventions, table 7.2.2-1 shows specific naming conventions that apply to the oneM2M TTCN-3 ATS.
 
-**Table�7.2.2-1: oneM2M specific TTCN-3 naming conventions**
+**Table 7.2.2-1: oneM2M specific TTCN-3 naming conventions**
 
 |Language element |Naming convention |Prefix |Example identifier |
 |-|-|-|-|
@@ -381,21 +406,22 @@ Next to such general naming conventions, table�7.2.2-1 shows specific naming c
 
 
 
-### 7.2.3	Usage of Log statements
+### 7.2.3    Usage of Log statements
 All TTCN-3 log statements use the following format using the same order:
 
 - The TTCN-3 test case or function identifier in which the log statement is defined.
-
 - One of the categories of log: INFO, WARNING, ERROR, TIMEOUT, NONE.
-
 - Free text.
-- EXAMPLE 1:	log("f_utInitializeIut: INFO: IUT initialized");
+
+`EXAMPLE 1:    log("f_utInitializeIut: INFO: IUT initialized");`
+
 Furthermore, the following rules are applied too:
 
-- All TTCN-3 setverdict statements are combined (as defined in TTCN-3 - ETSI�ES 201 873-1 [7]) with a log statement following the same above rules (see example 2).
-- EXAMPLE 2:	setverdict(pass, "TC_ONEM2M_CSE_DMR_CRE_001: Received correct message");
+- All TTCN-3 setverdict statements are combined (as defined in TTCN-3 - ETSI ES 201 873-1 [7]) with a log statement following the same above rules (see example 2).
+
+`EXAMPLE 2:    setverdict(pass, "TC_ONEM2M_CSE_DMR_CRE_001: Received correct message");`
 
-### 7.2.4	Test Case (TC) identifier
+### 7.2.4    Test Case (TC) identifier
 
 **Table 7.2.4-1: TC naming convention**
 
@@ -417,10 +443,12 @@ Furthermore, the following rules are applied too:
 | |\<per> = permutation |P1_P2_..PN |Permutation parameters |
 
 
-- EXAMPLE:	TP identifier:	TP/oneM2M/CSE/DMR/CRE/001
-TC identifier:	TC_ONEM2M_CSE_DMR_CRE_001
 
-## 7.3	IXIT
+
+`EXAMPLE:    TP identifier:    TP/oneM2M/CSE/DMR/CRE/001<br/>TC identifier:    TC_ONEM2M_CSE_DMR_CRE_001`
+
+## 7.3    IXIT
+
 The following parameters are used by the oneM2M ATS for the correct execution of the test cases.
 
 **Table 7.3-1: oneM2M ATS IXITs**
@@ -463,28 +491,24 @@ The following parameters are used by the oneM2M ATS for the correct execution of
 
 
 
-# 8	TTCN-3 Verifications
+# 8    TTCN-3 Verifications
 The principles for Verifying the TTCN-3 test code are given in one M2M TS-0015 [i.2].
 All test cases provided with this document in Annex A which correspond to at least one of the product profiles defined in one M2M TS-0025 [i.3] have been verified at the time of publication of this document which corresponds with the TTCN-3 code gitlab tag provided in annex A.
-
-Annex A (normative):
-TTCN-3 library modules
-A.1	Electronic annex, zip file with TTCN-3 code 
-This ATS has been produced using the Testing and Test Control Notation (TTCN) according to ETSI�ES 201 873-1 [7]. 
+<br/>Annex A (normative):<br/>TTCN-3 library modules
+A.1    Electronic annex, zip file with TTCN-3 code 
+This ATS has been produced using the Testing and Test Control Notation (TTCN) according to ETSI ES 201 873-1 [7]. 
 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:
-. 
-
-
+[https://git.onem2m.org/TST/ATS/tags/TST-2018-0021-TS-0019_TTCN-3_Test_cases](https://git.onem2m.org/TST/ATS/tags/TST-2018-0021-TS-0019_TTCN-3_Test_cases). 
 
-Annex B (informative):
-Bibliography
+<br/>
+Annex B (informative):<br/>Bibliography
 ISO/IEC 9646-6 (1994): "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 6: Protocol profile test specification".
 oneM2M TS-0017: "Implementation Conformance Statement".
 oneM2M TS-0031: "Feature catalogue".
 
 
-# History
+# <br/>History
 
 |Publication history |Publication history |Publication history |
 |-|-|-|
diff --git a/media/image1.png b/media/image1.png
new file mode 100644
index 0000000000000000000000000000000000000000..97c1800c30f775e41f7ceeccb99e5678e51651cd
Binary files /dev/null and b/media/image1.png differ
diff --git a/media/image2.png b/media/image2.png
new file mode 100644
index 0000000000000000000000000000000000000000..b1a7d923cfd493a68c5070f8ce7f23a38ff3e9d0
Binary files /dev/null and b/media/image2.png differ
diff --git a/media/image3.png b/media/image3.png
new file mode 100644
index 0000000000000000000000000000000000000000..d67c1ade753c921e803e9e52e5c643408f95b115
Binary files /dev/null and b/media/image3.png differ
diff --git a/media/image4.png b/media/image4.png
new file mode 100644
index 0000000000000000000000000000000000000000..ac279b284206d364f3913fffac6ecdcedd50fb24
Binary files /dev/null and b/media/image4.png differ
diff --git a/media/image5.emf b/media/image5.emf
new file mode 100644
index 0000000000000000000000000000000000000000..dc3a80a7339f4a53619df43dc2879233e3a44226
Binary files /dev/null and b/media/image5.emf differ
diff --git a/media/image6.png b/media/image6.png
new file mode 100644
index 0000000000000000000000000000000000000000..e894d519bd2adfb8b2cda05ebe406a474461903b
Binary files /dev/null and b/media/image6.png differ
diff --git a/media/image7.emf b/media/image7.emf
new file mode 100644
index 0000000000000000000000000000000000000000..9bb7e9529a04881445e7c0c69bdedd353cc60ffb
Binary files /dev/null and b/media/image7.emf differ
diff --git a/media/image8.emf b/media/image8.emf
new file mode 100644
index 0000000000000000000000000000000000000000..7ae8056bc8cd8dd3bbea8a0555d1116fe3dc796f
Binary files /dev/null and b/media/image8.emf differ
diff --git a/media/image9.emf b/media/image9.emf
new file mode 100644
index 0000000000000000000000000000000000000000..ec6f9e9bea5ad4debab714d37045cbe9c46910d1
Binary files /dev/null and b/media/image9.emf differ