SIST-TP TR 102 026 V1.1.1:2004

SLOVENSKI STANDARD
01-april-2004
Harmonizacija telekomunikacij in internetnega protokola prek omrežij (TIPHON) -
Študija uporabe TTCN-3 za preskušalne specifikacije za SIP in OSP
Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON);
Study of the use of TTCN-3 for SIP and for OSP test specifications
Ta slovenski standard je istoveten z: TR 102 026 Version 1.1.1
ICS:
33.020 Telekomunikacije na splošno Telecommunications in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

Technical Report
Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON);
Study of the use of TTCN-3 for SIP
and for OSP test specifications

2 ETSI TR 102 026 V1.1.1 (2002-01)

Reference
DTR/TIPHON-06019
Keywords
VoIP, interoperability, IP, testing, TTCN
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
editor@etsi.fr
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2002.
All rights reserved.
ETSI
3 ETSI TR 102 026 V1.1.1 (2002-01)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.6
3 Abbreviations.6
4 Background.7
5 Suitability of TTCN-3 for SIP testing .8
5.1 Architectural considerations for testing SIP.8
5.2 Expressing SIP dynamic behaviour in TTCN-3 .9
5.3 Expressing SIP messages in TTCN-3.10
5.3.1 SIP headers.12
5.3.1.1 Parameterization.12
5.3.1.2 Wildcards.13
5.3.1.3 Using modified templates.13
5.3.2 TTCN-3 regular expressions.14
5.3.2.1 Simple patterns.14
5.3.2.2 More complex patterns.14
5.3.2.2.1 Set expression.15
5.3.2.2.2 Reference expression.15
5.3.2.2.3 Match expression n times .15
5.3.2.3 Using regular expressions with SIP .15
6 Suitability of TTCN-3 for OSP testing.16
6.1 Architectural considerations for testing OSP .16
6.1.1 Normal OSP message exchange .16
6.1.2 Token carriage.17
6.2 Expressing OSP dynamic behaviour in TTCN-3.17
6.3 Expressing OSP messages in TTCN-3 .18
6.3.1 AuthorizationRequest.18
6.3.1.1 XML declaration.18
6.3.1.2 TTCN3 type.18
6.3.1.3 TTCN3 template.19
6.3.2 Parameterization.20
6.3.3 Wildcards.20
7 Practical experience of using TTCN-3.21
8 Availability of tools.21
9 Maintenance of the TTCN-3 standard.21
10 Training.22
Annex A: Suggested style guidelines.23
A.1 Introduction.23
A.2 The rule and its two corollaries .23
A.3 Some guidelines.24
A.3.1 Module organization.24
A.3.2 Comments.27
A.3.3 Type definitions.28
A.3.3.1 Basic types.28
A.3.3.2 Structured types.29
A.3.3.2.1 Enumerations.29
ETSI
4 ETSI TR 102 026 V1.1.1 (2002-01)
A.3.3.2.2 Records et al.29
A.3.3.2.3 Variable definitions.29
A.3.4 Function definitions.30
A.3.5 Whitespace.31
A.3.6 Statements.31
A.3.6.1 Simple statements.31
A.3.6.2 Compound statements.31
A.3.7 Naming conventions.32
A.3.8 Beautifiers and formatters .33
A.3.9 Presentation fonts and sheet orientation .33
A.3.10 Alternates, named or not .34
A.3.11 Calls and references to other modules.35
A.3.12 Test case style.35
A.3.13 PICS and PIXIT parameters .37
Annex B: Bibliography.38
History .39

ETSI
5 ETSI TR 102 026 V1.1.1 (2002-01)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Project Telecommunications and Internet Protocol
Harmonization Over Networks (TIPHON).
ETSI
6 ETSI TR 102 026 V1.1.1 (2002-01)
1 Scope
The present document provides an analysis on the suitability of using TTCN-3 as defined in ES 210 873-1 [1] to specify
the test specifications for TIPHON protocols, in particular the TIPHON profile of SIP (Session Initiation Protocol) and
the TIPHON OSP (Open Settlement Protocol). This study is restricted to the use of the TTCN-3 Core Language.
2 References
For the purposes of this Technical Report (TR) the following references apply:
[1] ETSI ES 201 873-1: "Methods for Testing and Specification (MTS); The Tree and Tabular
Combined Notation version 3; Part 1: TTCN-3 Core Language".
[2] ISO/IEC 9646-3: "Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 3: The Tree and Tabular Combined Notation (TTCN)
Edition 2".
[3] ETSI TS 101 321: "Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Open Settlement Protocol (OSP) for Inter-Domain pricing, authorization, and usage
exchange".
[4] ITU-T Recommendation Z.140: "The tree and tabular combined notation version 3 (TTCN-3):
Core language".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ASN.1 Abstract Syntax Notation One
ATS Abstract Test Suite
DTD Document Type Definition
IUT Implementation Under Test
MTC Master Test Component
OSP Open Settlement Protocol
(P)ICS (Protocol) Implementation Conformance Statement
(P)IXIT (Protocol) Implementation eXtra Information for Testing
PDU Protocol Data Unit
SIP Session Initiation Protocol
SUT System Under Test
TCP Transfert Control Protocol
TTCN-2 Tree and Tabular Combined Notation version 2
TTCN-3 Testing and Test Control Notation version 3
UDP User Datagram Protocol
XML eXtensible Markup Language
PCO Point of Control and Observation
DE Development Environment
ETSI
7 ETSI TR 102 026 V1.1.1 (2002-01)
4 Background
The detailed code for nearly all ETSI (conformance) Abstract Test Suites (ATS) is written in TTCN. There are two
versions of TTCN, version 2 (TTCN-2) as defined in ISO/IEC-9646-3 [2] and the recently published ETSI version 3
ES 201 873-1 [1].
NOTE: Version 1 of TTCN is not now used by ETSI.
Version 2 is oriented towards conformance testing and has been widely applied in testing telecommunications protocols
and services for over 10 years. TTCN-3 is a modernization of TTCN-2. It has been developed to apply to a wide range
of testing applications (i.e. it is not limited to conformance testing) and the syntax of the language has been brought into
line with that of other modern programming languages.
While it is not anticipated that TTCN-2 will immediately replace TTCN-3 (from ETSI's point of view the transition to
TTCN-3 is expected to occur over several years) there are good reasons to consider using TTCN-3 for "new" protocols
such as SIP or OSP.
EP TIPHON is writing test specifications for H.225, H.245, H.248, SIP and OSP. The tests for the first three protocols
are being written in TTCN-2. This is mainly due to timing (the work was started several months prior to the publication
of TTCN-3) and the fact that they are "traditional" protocols (for example H.225 is very close to Q.931). It is also more
likely that, in the short-term, the actual test systems for these protocols will be based on TTCN-2.
However, the nature of SIP and OSP (e.g., text-based, datacom-oriented) makes them an ideal candidate for TTCN-3.
The present document makes an initial analysis on the suitability of using TTCN-3 to for SIP and OSP test
specifications.
ETSI
8 ETSI TR 102 026 V1.1.1 (2002-01)
5 Suitability of TTCN-3 for SIP testing
In order to understand the suitability of TTCN-3 for testing SIP it is necessary to consider three main aspects:
• the basic testing architecture, i.e. the location of the test interfaces;
• the expression of dynamic behaviour (i.e. SIP message exchanges);
• the representation of data (i.e. SIP messages).
These aspects are described in clauses 5.1, 5.2 and 5.3 respectively.
5.1 Architectural considerations for testing SIP
Two conceptual SIP test systems are illustrated in figure 1. The TTCN-3 parts of the test system are represented by the
white boxes, which in the present document we refer to as the "TTCN-3 Tester". The light grey box represents
sub-structured parts of the test system. The dark grey boxes indicate the underlying transport layer, either UDP or TCP.

Option 1  Option 2
High level
(intelligent)
processing of the SIP
All processing of
PCO
Initial low - level
SIP messages
messages done
processing o f the SIP
in TTCN -3 messages done in test
system
-3
PCO
TTCN
UDP/TCP  UDP/TCP
Figure 1: Basic test system architecture
TTCN-3 behaviour is executed over test ports, sometimes called PCOs (Points of Control and Observation). For SIP
testing there are basically two options for the placement of the PCO.
• directly over UDP (or TCP);
• higher than UDP (or TCP), i.e. "embedded" in the test system.
In the first option of figure 1 all processing of the SIP messages is expressed in TTCN-3. For received messages this
means that the PCO delivers a SIP message to the TTCN-3 tester as a single text string. The TTCN-3 code must then
(somehow) parse this text string and break it down into data structures on which the TTCN-3 matching mechanisms etc.
can operate. For send messages the reverse occurs i.e. TTCN-3 data structures representing the SIP message are
encoded as a single text string.
It is certainly possible to use TTCN-3 this way but this would probably be inefficient. It would also overload the
TTCN-3 test cases (not to mention the test suite writers) with detail not explicitly relevant to the test purposes.
In the second option, the test system receives a SIP message over the UDP (or TCP) port and does the initial parsing
before passing the structure to the TTCN-3 Tester via the PCO. In its simplest form this parser need only recognize the
basic "outline" of the message with no detailed knowledge of individual headers. This structure would be mapped to the
corresponding TTCN-3 template on a best possible fit basis. The TTCN-3 Tester then operates directly on this data
structure rather than the incoming text string (by pattern matching).
ETSI
9 ETSI TR 102 026 V1.1.1 (2002-01)
If the tester is to deliver more complex TTCN-3 structures then the underlying parser will need to be correspondingly
complex. As this will effect how a TTCN-3 test case is expressed (i.e. place restrictions on how TTCN-3 is used) it is
important that this functionality is defined by EP TIPHON at an early stage.
In conventional protocol testing (especially when using, say, ASN.1) this sub-layer (shaded light grey in figure 1) is
often referred to as an encoder-decoder. Here, the incoming data is a bit stream which is decoded by the test system and
passed to the TTCN-3 tester in structured form.
Discussions with several tool implementer's indicate that option 2 should be the favoured approach. The present
document therefore recommends that EP TIPHON follow option 2 when writing TTCN-3 test cases for SIP.
5.2 Expressing SIP dynamic behaviour in TTCN-3
SIP has very simple dynamic behaviour. The TTCN-3 communication and timer mechanisms etc. are entirely adequate
to specify the exchange of SIP messages. The present document recommends that TIPHON SIP tests are expressed
using asynchronous communication.
NOTE: Generally, SIP testing would be based on asynchronous message exchanges, however TTCN-3 does have
synchronous communication if it is desired to express the test that way.
A typical piece of SIP behaviour could be:
testcase SIP_RG_RT_V_001() runs on SipComponent system SipInterfaces
// Selection: To be defined
// Status: Mandatory
// SUT: A UA, a proxy, or a redirect server.
// Precondition: None
// Ref: 2.2 [1], 7.1 [1], 10.14 [1]
// Purpose: Ensure that the IUT, in order to be registered, sends a REGISTER request
// t to its proxy (Home server, outbound proxy) with the action field set to "proxy"
// in the Contact header field, without user name in the Request-URI,
// with a Via header field and with a SIP URL as request-URI.
{
var REG_Request V_REGISTER_Request;
var ContactAddress_List V_ContactList;
var GenericParam_List V_GenericParamList;
var integer i,j, nbelement, nbparam;
var boolean hasBeenFound:=false;

sut.action ("Please REGISTER");
TWait.start(PX_TWAIT);
alt
{
[] SIP1.receive (REGISTER_Request_r_2) from rcv_label -> value V_REGISTER_Request
{
TWait.stop;
// Catch and prepare informations to answer
iutContact :=
getContactAddr(V_REGISTER_Request.reqHeader.contact.contactBody.contactAddress_List[1]);

V_CallId := V_REGISTER_Request.reqHeader.callId;
V_CSeq := V_REGISTER_Request.reqHeader.cSeq;
V_From := V_REGISTER_Request.reqHeader.fromField;
V_To := V_REGISTER_Request.reqHeader.toField;
V_Via := V_REGISTER_Request.reqHeader.via;
// update sent_label according to received via header field
getViaReplyAddr(V_Via.viaBody);
//Add a Tag in the TO field
V_To.toParams := {{TAG_ID, GetAValueTag()}};

// Check Contact content
V_ContactList := V_REGISTER_Request.reqHeader.contact.contactBody.contactAddress_List;
nbelement := sizeof(V_ContactList);
for (i:=1;i==nbelement;i:=i+1)
{
hasBeenFound:=false;
// Check that parameters are present in the contact
if (match(V_ContactList[i], ContactAdress_r_1))
{
V_GenericParamList := V_ContactList[i].contactParams;
nbparam := sizeof(V_GenericParamList);
j:=1;
//Check that at least one parameter is set to action="proxy"
ETSI
10 ETSI TR 102 026 V1.1.1 (2002-01)
do
{
if (match(V_GenericParamList[j],GenericParam_r_1))
{
hasBeenFound:=true;
}
// Check that contact does not include a parameter set to action="redirect"
if (match(V_GenericParamList[j],GenericParam_r_2))
{
hasBeenFound:=false;
j:= nbparam;
}
j:=j+1;
}
while (j<=nbparam) //end loop on contact parameters
}
if(not hasBeenFound)
{
verdict.set(fail);
//Answer with a 409 status message
SIP1.send (Response_409_s_1(V_CallId, V_CSeq, V_From, V_To,
V_Via )) to sent_label; stop
}
} //end For on Contact list
verdict.set(pass);
//Send a 200OK Answer to the UA with an Expire header field set
//to PX_DELTA_REGISTRATION and the contact list
SIP1.send (Response_200_s_2(V_CallId, V_CSeq, V_From, V_To,
V_Via, V_REGISTER_Request.reqHeader.contact,
PX_DELTA_REGISTRATION )) to sent_label

}
[] SIP1.trigger from rcv_label
{
all timer.stop;
verdict.set(fail);
stop
}
[] Twait.timeout {verdict.set(inconc); stop}
}
} // end testcase SIP_RG_RT_V_001

5.3 Expressing SIP messages in TTCN-3
Currently many SIP test suites specify one single text string for each instance of a message. Changing one element in a
message means that a complete, new message needs to written. The end result is many hundreds of individual SIP
messages. No rationalization. No reuse. Worse still, matches on incoming messages have to be exact, where in practice
a degree of flexibility is often desirable.
The TTCN-3 approach allows to set and match individual elements of data in complex messages. To give a high degree
of controllability and observability. Because SIP messages are text based they have no explicit structure, contrary to
conventional telecommunications protocol. For example:
INVITE sip:test@sip.com SIP/2.1
From: userB
To: userA
CSeq: 1 INVITE
Content-Length: 0
In order to test SIP using TTCN-3 it is necessary to give the messages at least some level of structuring. Highly
structured SIP data will give a good degree of control but will probably lead to a humanly unreadable test suite.
Conversely, little or no structuring will give good readability but very little control. In this clause we present a style of
using TTCN-3 that attempts to achieve controllability while retaining a good degree of readability.
ETSI
11 ETSI TR 102 026 V1.1.1 (2002-01)
A SIP message has three basic parts, the Request (or Status) line, the headers and the (optional) message body. The
components of a Request or Status line appear in a given order. In TTCN-3 this can be represented using a record type,
for example:
// SIP Message Request
type record SIP_REQUEST
{ charstring Method  optional, // even mandatory fields are optional
charstring Request_URI optional, // so that we can specify invalid messages
charstring SIP_Version optional,
:
}
Actual messages can be defined using TTCN-3 templates. For example:
template SIP_REQUEST MyRequest :=
{ Method  := "INVITE ",
Request_URI := "sip:test@sip.com ",
SIP_Version := "SIP/2.1\r\n" // where \r\n represents %d13%d10 the CR + LF characters
:
}
Explicit spaces could be included in the structure rather than having them as part of the actual string value
(see clause 5.3.1).
For the sake of this discussion let us assume that SIP headers are text strings terminated by an end of line character
(e.g., CR or LF or CRLF). Generally, SIP messages allow headers to appear in any order. However, for sent messages
(i.e. SIP Requests) the TTCN-3 Tester should specify messages with the SIP headers in a given order. In TTCN-3 this
can be expressed using the record of type.
// Unbounded array of character strings (i.e. headers)
type record of charstring REQUEST_HEADERS;

// Unbounded array of character strings (i.e. body elements)
type record of charstring REQUEST_BODY;

// SIP Message = Request Line + Headers + Body
type record SIP_REQUEST
{ charstring Method  optional, // even mandatory fields are optional
charstring Request_URI optional, // so that we can specify invalid messages
charstring SIP_Version optional,
REQUEST_HEADERS Message_Headers optional,
REQUEST_BODY Message_Body optional
}
For received messages (i.e. SIP Responses) the TTCN-3 Tester should be prepared to accept messages with the SIP
headers appearing in an arbitrary order. In TTCN-3 this can be expressed using the set of type.
// Unbounded set of character strings (i.e. headers)
type set of charstring RESPONSE_HEADERS;

// Unbounded set of character strings (i.e. body elements)
type set of charstring RESPONSE_BODY;

// SIP Message = Response Line + Headers + Body
type record SIP_RESPONSE
{ charstring  SIP_Version optional, // even mandatory fields are optional
charstring  Status_Code optional, // so that we can specify invalid messages
charstring  Reason_Phrase optional,
RESPONSE_HEADERS Message_Headers optional,
RESPONSE_BODY Message_Body optional
}
ETSI
12 ETSI TR 102 026 V1.1.1 (2002-01)
5.3.1 SIP headers
In its simplest form a SIP header can be represented as a single text string, as described in clause 5.3. For example:
"CSeq: 1 INVITE\r\n"
However, the CSeq header could be represented as a structured type of several elements:
type record CSEQ
{ tag charstring,
sp1 charstring,
counter charstring,
sp2 charstring,
method charstring // could also be enumerated type
}
// with the value:
template CSEQ MyCSeq :=
{ tag := "CSeq:",
sp1 := " ",
counter := "1",
sp2 := " ",
method := "INVITE",
eol := "\r\n"
}
Representing headers in this way gives a wide range of control (we can explicitly access individual fields in SIP
headers). However, readability can be seriously affected if this approach is not used care. Note also that the
REQUEST_HEADERS type (for example) can no longer be a simple record of charstring but would need, for
example, to be a union of the different message header structures. See also clause 3.3.2.2.
One method to give some form of pseudo-structure to the charstring and yet retain readability is to use the
concatenator operator, for example (where CRLF = "\r\n" and SP = " "):
"CSeq:" & SP & "1" & SP & "INVITE" & CRLF

NOTE: Regular expressions (patterns) will be introduced into TTCN-3 see clause 5.3.2 for a description and
clause 5.3.2.3 for a SIP example.
template SIP_RESPONSE MyResponse :=
{ SIP_Version := "INVITE" & SP,
Status_Code := "200" & SP,
Reason_Phrase := "OK" & CRLF,

Message_Headers := { "From:" & "userB" & CRLF,
"To:" & "userA" & CRLF,
"CSeq:" & "1" & "INVITE" & CRLF,
"Content-Length: " & "0",
* // All other headers are ignored
},
Message_Body  := omit
}
This approach makes more sense when used with parameterized templates and wildcards, as explained in
clauses 5.3.1.1 and 5.3.1.2.
See annex A for a full example (test case) which applies the various approaches described in the previous clauses.
5.3.1.1 Parameterization
TTCN-3 templates can be parameterized. For example, we could parameterize the counter in the CSeq header:
template SIP_RESPONSE MyResponse (charstring COUNTER) :=
{ :
Message_Headers := { :
"CSeq:" & COUNTER & "INVITE" & CRLF
:
},
Message_Body  := omit
}
// And in the receive line we could write:
pco.receive(MyRespons("1"))
ETSI
13 ETSI TR 102 026 V1.1.1 (2002-01)
5.3.1.2 Wildcards
The TTCN-3 matching mechanisms (wildcards) can also be used. For example, we could wildcard the counter in the
CSeq header:
template SIP_RESPONSE MyResponse :=
{ :
Message_Headers := { :
"CSeq:" & & "INVITE" & CRLF
},
Message_Body  := omit
}
NOTE: The exact syntax of TTCN-3 wildcards and patterns is still under review.
5.3.1.3 Using modified templates
Another mechanism that could be used is derived, or modified, templates. For example, a complete SIP message would
contain all the headers, say, from "Allow" to "WWWAuthenticate".
// SIP Message Request
type record SIP_REQUEST
{ charstring Method  optional, // even mandatory fields are optional
charstring Request_URI optional, // so that we can specify invalid messages
charstring SIP_Version optional,

charstring Allow  optional,
:
charstring  From  optional,
charstring  To  optional,
charstring  CSeq  optional,
charstring  Content-Length optional
:
charstring WWWAuthenticate optional,

RESPONSE_BODY Message_Body optional
}
A base response template where all headers are omitted:
NOTE: For SIP Responses the wildcard "*" would probably be used instead of omit.
template SIP_REQUEST MyBaseRequest :=
{ Method  := "INVITE" & SP,
Request_URI := "sip:test@sip.com" & SP,
SIP_Version := "SIP/2.1" & CRLF,

Allow  := omit,
:
From  := omit,
To  := omit,
CSeq  := omit,
ContentLength := omit,
:
WWWAuthenticate := omit,
MessageBody  := omit
}
The following template produces the same SIP message as the example in clause 5.3. That is, by default all other
headers are omitted.
template SIP_REQUEST MyRequest modifies SIP_REQUEST MyBaseRequest :=
{ Method  := "INVITE" & SP,
Request_URI := "sip:test@sip.com" & SP,
SIP_Version := "SIP/2.1" & CRLF,

From  := "From:" & "userB" & CRLF,
To  := "To:" & "userA" & CRLF,
CSeq  := "CSeq:" & "1" & "INVITE" & CRLF,
ContentLength := "Content-Length: " & "0"
}
ETSI
14 ETSI TR 102 026 V1.1.1 (2002-01)
5.3.2 TTCN-3 regular expressions
TTCN-3 now supports limited regular expressions, or patterns. These may be used to match character string values
anywhere that wildcards and matching mechanisms are currently allowed in TTCN-3.
Work is progressing to introduce more complicated pattern-matching into the language. It is expected that tool-makers
will implement these proposals as they develop. This will ensure that, for EP TIPHON at least, pattern matching
capabilities will be available in a timely manner.
5.3.2.1 Simple patterns
In addition to literal characters, character patterns allow the use of meta characters "?" and "*" to mean any character
and any number of any character respectively. For example:
template charstring MyTemplate:= pattern "ab??xyz*";

This template would match any character string that consists of the characters "ab", followed by any two characters,
followed by the characters "xyz", followed by any number of any characters.
The metacharacter "\" is used as an escape character. For example:
template charstring MyTemplate:= pattern "ab?\?xyz*";

This template would match any character string which consists of the characters "abr", followed by any characters,
followed by the characters "?xyz", followed by any number of any characters.
In addition to direct string values it is also possible within the pattern statement to use references to existing templates,
constants or variables. The reference shall resolve to one of the character string types and more than one. For example:
const charstring MyString:= "ab?";

template charstring MyTemplate:= pattern MyString;

This template would match any character string that consists of the characters "ab", followed by any characters. In
effect any character string following the pattern keyword either explicitly or by reference will be interpreted
following the rules defined in this clause.
5.3.2.2 More complex patterns
The draft proposal (July 2001) for a more sophisticated pattern matching mechanism in TTCN-3 is described below.
This proposal (or something very similar) will be incorporated into the language by October 2001 (support in tools for
this feature is already available).
The list of meta characters for TTCN-3 patterns is shown in table 1.
Table 1: List of TTCN-3 Pattern Metacharacters
Metacharacter Description
? Match any character
* Match any character zero or more times
\ Cause the following meta character to be interpreted as a literal
[ ] Match any character within the specified set
{ group, plane, row, cell }
Match the Universal character specified by the quadruple
Insert the referenced user defined string and interpret it as a regular expression
\d Match any numerical digit (equivalent to [0-9])
\w Match any alphanumeric character (equivalent to [0-9a-zA-Z])
\\ Match the backspace character
"" Match the double quote character
| Used to denote two alternative expressions
( ) Used to group an expression
#(n, m) Match the preceding expression at least n times but no more than m times

ETSI
15 ETSI TR 102 026 V1.1.1 (2002-01)
5.3.2.2.1 Set expression
The set expression is delimited by the "[" "]" symbols. In addition to character literals, it is possible to specify character
ranges using the separator "-". The set expression can also be negated by placing the "^" character as the first character
after the opening square brace.
For example:
template charstring RegExp1:= pattern “[a-z]”; // this will match any character from a to z

template charstring RegExp2:= pattern “[^a-z]”; // this will match any character except a to z

template charstring RegExp3:= pattern “[A-E][0-9][0-9][0-9]YKE”;

// RegExp3 will match a string which starts with a letter between A and E then has three
// digits and the letters YKE
5.3.2.2.2 Reference expression
In addition to direct string values it is also possible within the pattern statement to use references to existing templates,
constants or variables. The reference is enclosed within the "<" ">" characters. The reference shall resolve to one of the
character string types. For example:
const charstring MyString:= "ab?";

template charstring MyTemplate:= pattern “”;

This template would match any character string that consists of the characters "ab", followed by any characters. In
effect any character string following the pattern keyword either explicitly or by reference will be interpreted
following the rules defined in this clause.
template universal charstring MyTemplate1:= pattern “de{1, 1, 13, 7}”;

This template would match any character string which consists of the characters "ab", followed by any characters,
followed by the characters "de", followed by the character in ISO10646 with group = 1, plane = 1, row = 13 and
cell = 7.
5.3.2.2.3 Match expression n times
To specify that the preceding expression should be matched a number of times the "#(n, m)" syntax is used. This
specifies that the preceding expression must be matched at least n times but not more than m times.
For example:
template charstring RegExp4:= pattern “[a-z]#(9, 11)”;  // match at least 9 but no more than 11
// characters from a to z
template charstring RegExp5:= pattern “[a-z]#(9)”;  // match exactly 9
// characters from a to z
template charstring RegExp6:= pattern “[a-z]#(9, )”;  // match at least 9
// characters from a to z
template charstring RegExp7:= pattern “[a-z]#(, 11)”;  // match no more than 11
// characters from a to z
5.3.2.3 Using regular expressions with SIP
Patterns would replace the syntax illustrated in clause 5.1. For example, the following pattern indicates that "CSeq" may
be followed by 1 or more spaces, that the counter value (e.g., "1") is in the template parameter COUNTER (see
clause 5.3.1.1) and that "INVITE" is preceded by at least one space and followed by exactly one CRLF.
pattern "CSeq:#(1,)#(1,)INVITE"

Following this approach the example of 5.3.1 would become:
template SIP_REQUEST MyRequest (charstring COUNTER) :=
{ SIP_Version := pattern "INVITE#(1,)",
Status_Code := pattern "200#(1,)",
Reason_Phrase := pattern "OK",

From  := pattern "From:#(1,)\",
To  := pattern "To: :#(1,)\",
CSeq  := pattern "CSeq:#(1,)#(1,)INVITE",
ETSI
16 ETSI TR 102 026 V1.1.1 (2002-01)
Content-Length := pattern "Content-Length:#(1,)0"
}
6 Suitability of TTCN-3 for OSP testing
In order to understand the suitability of TTCN-3 for testing OSP it is necessary to consider three main aspects:
• the basic testing architecture, i.e. the location of the test interfaces;
• the expression of dynamic behaviour (i.e. OSP message exchanges);
• the representation of data (i.e. OSP messages).
These aspects are described in clauses 6.1, 6.2 and 6.3 respectively.
6.1 Architectural considerations for testing OSP
For the test architecture the discussion of clause 5.1 also applies to OSP. A more detailed test architecture is shown in
figure 2. The adaptation layer is shown in more detail in figure 3.
Tester IUT
TTCN OSP
Adaptation layer XML
HTTP HTTP
SSL TCP TCP SSL TCP TCP
port 443 port 80 port 443 port 80
IP
Figure 2: Test architecture
ASN.1 (Note) XML
TEXT ASCII
ASN.1 XML
PER BIN
Figure 3: Adaptation layer
6.1.1 Normal OSP message exchange
In the case of normal OSP message exchange the adaptation layer shall proceed the following tasks:
• The Adaptation layer shall receive an ASCII string (XML ) or a binary presentation of the XML document
ASCII
(XML ) from the HTTP layer.
BIN
• The Adaptation layer shall decode XML or XML according to the OSP DTD. The OSP DTD is defined
ASCII BIN
in TS 101 321 [3], annex A.
• The Adaptation layer shall map the decoded result to the TTCN3 types. The TTCN3 types are defined in
annex C.
• The Adaptation layer shall add all the raw data received from the HTTP layer in the payload field of the TTCN3
type. If a matching error in the Tester occurs, the raw data will be compared with the parsed data in order to see
if the matching error is a result of an OSP protocol error or if it is a result of a parsing error.
ETSI
17 ETSI TR 102 026 V1.1.1 (2002-01)
6.1.2 Token carriage
In the case of Token Carriage the Adaptation layer may receive the following formats:
• ASN.1 : The Adaptation layer receives an ASN.1 format as defined in TS 101 321 [3], clause D.2.1. The
PER PER
Adaptation layer shall convert the ASN.1 format to the TTCN3 types. The TTCN3 types are defined in
PER
annex C of [3].
• XML : The Adaptation layer receives an ASCII string as defined in TS 101 321 [3], clause D.2.2. The rules
ASCII
of clause 4.2.1 shall apply.
• XML : The Adaptation layer receives a binary presentation of the XML document as defined in
BIN
TS 101 321 [3], clause D.2.3. The rules of clause 4.2.1 shall apply.
6.2 Expressing OSP dynamic behaviour in TTCN-3
The dynamic behaviour of OSP is trivial, comprising simple Request/Response (Client/Server) interchanges.
testcase OSP_SV_PRI_BV_001() runs on MTC_OSP
// Selection: Pics Table I.1/2 [1] AND Pics Table I.20/1 [1] AND Pics Table I.20/2
// [1]
// Precondition: None
// Ref: Clause 6.2.1 [1]
// Purpose: Ensure that the IUT, on receipt of a PricingIndication,
// sends a PricingConfirmation with a componentID attribute associated to the Prici
// ngIndication, with a Timestamp and a Status element.
// The Timestamp element shall contain the definition of the time according to ISO
// 8601 [8]. The Status element shall contain the Code element. The Code element
...