Naming conventions should be explicitly stated. Naming conventions should not exist only for a single ATS, and the reader of an ATS should not be forced to "derive" the rules implicitly. The naming conventions should be part of the ATS conventions contained in the ATS specification document.

Naming conventions stated should, as a minimum, cover the following TTCN objects:

– test suite parameters/constants/variables;

– test case variables;

– formal parameters;

– timers;

– PDU/ASP/structured types;

– PDU/ASP/structured types constraints;

– test suite operations;

– aliases;

– test case/test step identifiers.

a) Protocol standard aligned

When there is a relationship between objects defined in the ATS and objects defined in the protocol standard, e.g. PDU types, the same names should be used in the ATS if this does not conflict with the character set for TTCN identifiers or with other rules. In case of a conflict, similar names should be used.

b) Distinguishing

The naming conventions should be defined in such a way, that objects of different types appearing in the same context, e.g. as constraint values, can be easily distinguished.

c) Structured

When objects of a given type allow a grouping or structuring into different classes, the names of these objects should reflect the structuring, i.e. the names should be composed of 2 or more parts, indicating the particular structure elements.

d) Self-explaining

The names should be such that the reader can understand the meaning (type/value/contents) of an object in a given context. When suffixes composed of digits are used, it is normally useful to have some rule expressed explaining the meaning of the digits.

e) Consistent

The rules stated should be used consistently throughout the document, there should be no exceptions.

f) Appropriate name length

Following the above rules extensively may occasionally lead to very long names, especially when structuring is used. The names should still be easily readable. When TTCN graphical form (TTCN.GR) is used, very long names are very inconvenient.

NOTE: Also, test tools may not be able to implement very long identifier names, which is an important aspect in this context.

Objects of Structured Type

Shall be derived from the name of the Information Element in the standard, if it corresponds to this (use standard acronyms where appropriate).

E.g.: "Window Size super-field" -> "WindowSizeSUFI"

Fields in a Structured Type

Shall be derived from the name of the same field in the corresponding Information Element in the standard. (Acronyms for the entire field name shall not be used)

E.g.: "Header Extension Type" -> "headerExtensionType" (not "HE")

Objects of ASP type

Shall be derived from the name of the corresponding Service Primitive in the Standard, using any relevant abbreviations from the present annex. The full name as it appears in the core specification shall be included in parentheses after the name.

E.g.: "CRLC-SUSPEND-Conf" -> "CRLC_SuspendCnf (CRLC-SUSPEND-Conf)"

If the metatype PDU is not used, the ASP name shall reflect both the ASP, and the embedded PDU name, using an underscore to separate the ASP part from the PDU part.

E.g.: DataReq_StartDTMF_Ack for an RRC-DATA-Req with an embedded START DTMF ACKNOWLEDGE PDU

Objects of PDU type

Shall have exactly the same name as the Message it corresponds to in the standard. If this Message is named by more words, they shall be joined, leaving the blanks out

E.g.: "AMD PDU" -> "AMDPDU".

Test Suite

Upper

–

TTCN Module

Upper

–

Simple Type

Upper

[<protocol>_]

Note 8

Structured Type

Upper

[<protocol>_]

Note 8

Element in Structured Type

Lower

–

ASN.1 Type

Upper

[<protocol>_]

Note 8

Element in ASN.1 Type

Lower

–

Test Suite Operation

Upper

o_[<protocol>_]

Notes 1 and 8

TSO Procedural Definition

Upper

o_[<protocol>_]

Notes 1 and 8

Formal Parameter to TSO or TSOP

Upper

p_

Test Suite Parameter (PICS)

Upper

pc_[<protocol>_]

Note 8

Test Suite Parameter (PIXIT)

Upper

px_[<protocol>_]

Note 8

Test Case Selection Expression

Upper

[<protocol>_]

Note 8

Test Suite Constant

Upper

tsc_[<protocol>_]

Note 8

Test Suite Variable

Upper

tsv_[<protocol>_]

Note 8

Test Case Variable

Upper

tcv_[<protocol>_]

Note 8

PCO Type

Upper

–

PCO

Upper

–

Note 2

CP

Upper

cp_

Note 2

Timer

Upper

t_[<protocol>_]

Note 8

Test Component

Upper

mtc_[<protocol>_] or ptc_[<protocol>_]

Notes 3 and 8

Test Component Configuration

Upper

–

ASP Type

Upper

[<protocol>_]

Notes 4 and 8

Parameters within ASP Type

Lower

–

Note 4

PDU Type

Upper

[<protocol>_]

Notes 4 and 8

Fields within PDU Type

Lower

–

Note 4

Encoding Definition

Upper

enc_

Encoding Variation

Upper

var_

Invalid Field Encoding Variation

Upper

inv_

CM Type

Upper

cm_

Field within CM Type

Lower

–

Alias

Upper

a_

ASP constraint

Upper

ca[b|d][s|r|w]_[<protocol>_]

Notes 5 and 8

PDU constraints

Upper

c[b|d][s|r|w]_[<protocol>|AA|108]

Notes 5, 8 and 10

Constraint (other types)

Upper

c[b|d][s|r|w]_[<protocol>_]

Notes 5 and 8

Formal Parameter for a Constraint

Upper

p_

Test Case Group

Upper

<protocol>/

Note 8

Test Step Group

Upper

Test Case

Upper

tc_

Note 6

Test Step

Upper

(ts_|pr_|po_)<CN domain>_<protocol>_

Notes 7, 8 and 9

Local tree

Upper

lt_

Defaults

Upper

<protocol>_

Note 8

NOTE 1: Coding rules are not specified for test suite operation procedural definitions at this stage. These rules will be defined when the need arises

NOTE 2: A prefix is not used for PCO declarations, but is used for CP declarations. This is because PCOs and CPs will only be used in send and receive statements, and PCOs will be used more frequently than CPs. Since a PCO name or a CP name will be used on most behaviour lines, PCO names should be as short as possible – E.g. 2 to 3 characters.

NOTE 3: The prefix is mtc if the component role is MTC, or ptc if the component role is PTC. If multiple PTCs are used, the rest of the identifier will clarify which PTC is being referred to. E.g. ptc_Cell1, ptc_Cell2.

NOTE 4: This applies for both tabular and ASN.1 definitions.

NOTE 5: Constraint prefixes are built up from the following regular expression. c[a][b|d][s|r|w].

– ‘c’ shall always be present to indicate that the object is a constraint.

– ‘a’ shall be present for ASP constraints to distinguish them from PDU constraints.

– ‘b’ shall be present if and only if the constraint is used as a base constraint. (i.e. included in the derivation path of any other constraint).

– ‘d’ shall be present if the constraint is derived from another constraint.(i.e. has an entry in it’s derivation path field)

– ‘b’ and ‘d’ cannot both be used in the same constraint, thereby limiting the derivation path to 1.

– For the purpose of the present note, the following definitions are required (see TR 101 666 [27] clause 12.6.2):

– The term ‘field’ is used to represent a structured type element, an ASP parameter, or a PDU field.

– A ‘bound field’ is a field that either contains a SpecificValue, or is Omitted (-).

– An ‘unbound field’ is a field that contains any of the following matching mechanisms: Complement, AnyValue (?), AnyOrOmit (*), ValueList, Range, SuperSet, SubSet, AnyOne (?), AnyOrNone (*), Permutation, Length, or IfPresent.

– ‘s’ may optionally be present if the constraint is only used in send statements. ‘s’ shall not be present if the constraint contains any unbound fields, or any fields chained to a constraint whose prefix includes ‘w’ or ‘r’.

– ‘r’ may optionally be present if the constraint is only used in receive statements.

– ‘w’ may optionally be present to indicate that the constraint contains fields that are unbound. Before these constraints are used in SEND events, all unbound fields must either be bound by using a derived constraint, or explicitly assigned a value in the SEND event behaviour line.

– Either ‘w’ or ‘r’ shall be used if any fields in the constraint are unbound or are chained to a constraint whose prefix includes ‘w’ or ‘r’.

NOTE 6: Test case names will correspond to the clause in the prose that specifies the test purpose. E.g. tc_7_2_23_2. An additional digit may be specified if more than one test case is used to achieve the test purpose. If an additional digit is required, this probably means that the test prose are not well defined.

NOTE 7: Test steps may optionally use the prefixes pr_ or po_ to indicate that the test step is a preamble or postamble respectively.

NOTE 8: Protocol abbreviations are provided in table E.2.3.2. Protocol abbreviations may optionally be used to clarify the scope of TTCN objects, or to resolve conflicts when the same name is required by multiple protocols within the ATS. The protocol abbreviation indicates that the object is related to a particular procedure (e.g. an MM procedure). This does not prevent the object from being used by an ATS testing a different protocol. If an object is specific to one ATS, this should be indicated in comments, rather than using a protocol abbreviation (e.g. if a timer is only used in RLC tests this should be stated in the comments, rather than using the abbreviation RLC in the timer name).If two different types exist in the ATS that represent the same information (e.g. IMSI) conversion operations shall be used to ensure consistency between the types. Also, conversion operations shall be used to avoid asking the same PIXIT question twice. For example, if a type is defined as an OCTETSTRING[4] for a NAS protocol, and the same type is represented as a BITSTRING[32] for RRC, a single PIXIT question shall be asked, and conversion operations shall be used to ensure that the same value is used for both types.

NOTE 9: The prefixes CS and PS may optionally be used to indicate that a test step is specific to circuit switched, or packet switched signalling respectively. For test steps specific to the Upper Tester, the prefixes AT or MMI or UT shall be used to indicate that, respectively, AT or MMI or both types of commands are used.

NOTE 10: The prefix AA shall be used for RRC PDU constraints to indicate that it is defined in 3GPP TS 34.123-1 [1] annex A. The prefix 108 shall be used for RRC PDU constraints to indicated that it is defined in 3GPP TS 34.108 [3] clause 9.

BMC

CC

CS

GMM

MAC

MM

PDCP

RLC

RRC

SMS

SS

SUS (Supplementary services)

TC

Acs

access

Acp

accept

Ack

acknowledge

act

activation

addr

address

(re)alloc

(re)allocated, (re)allocation

arg

argument

ass

assignment

auth

authentication

ava

avail, available

bCap

bearer capability

cau

cause

clg

calling

ch

channel

chk

check

ciph

cipher, ciphering

cld

called

clsmk

classmark

cmd

command

cmpl

complete

cnf

confirm

cfg

configuration

conn

connect

ctrl

control

def

default

descr

description

disc

disconnect

enq

enquiry

err

error

(re)est

(re)establish

ext

extended

fail

failure

ho

handover

id

identity / identification

ie

information element

iel

information element length

ind

indication

info

information

init

initialize

lvl

level

loc

location

locUpd

location update

max

maximum

mgmt

management

min

minimum

misc

miscellaneous

mod

modification

ms

mobile station

msg

message

mt

mobile terminal

neigh

neighbour

ntw

network

num

number

orig

origin/-al

pag

page/-ing

params

parameters

perm

permission

phy

physical

qual

quality

rand

random

ref

reference

reg

register

rej

reject

rel

release

req

request

rsp

response

rx

receiver

sel

selection

seq

sequence

serv

service

st

state

sysInfo

system information

sync

synchronization

sys

system

tx

transmitter

1. The name should reflect the purpose/objective the object is used for.
2. If the type is not a predefined one, it is useful that the name reflects the type, too.
3. It could be useful, that the individual naming conventions are not the same for all object classes this rule applies to. e.g. use upper case letters for test suite parameters/constants, and use one of the other possibilities presented in ETR 141 [37] example 1 for other object classes.

If the timer is not defined in the protocol to be tested, the name should reflect the objective of the timer used for testing.

NOTE: There is no need to indicate the object type "timer" in the name, since timers only occur together with timer operations

As far as applicable, derivation rules or mapping tables should be used to relate the names of the types to the corresponding objects in the protocol or service definition.

NOTE: There may be types, e.g. erroneous PDU types, that do not relate to an object in the protocol or service definition.

Rules should be stated to derive the names from the names of the corresponding type definitions. It is often possible to use the type name plus an appropriate suffix reflecting the specific constraint value. In case of lengthy names, useful abbreviations or a defined numbering scheme can be chosen.

The name should reflect the operation being performed.

i.e. the name should indicate an activity, not a status. This can be achieved e.g. by using appropriate prefixes like "check", "verify", etc.

The name should reflect that aspect of its expansion, that is important in the situation where the alias is used. Derivation rules should be provided to derive the alias name from its macro expansion or from the name of an embedded ASP / PDU.

The name should reflect the objective of the test step.

1. If the protocol standard uses ASN.1 to specify the PDUs, the ATS specifier should also use ASN.1.
2. If the protocol standard does not use ASN.1, check carefully whether features of ASN.1 that the tabular format of type definition does not present are necessary in the ATS, or could ease the design and understanding of the definitions as a whole. Check especially whether fields or parameters have to be specified, the order of appearance of which, in a received ASP/PDU, cannot be predicted. If any of these conditions apply, use ASN.1 for type and ASP/PDU type declarations.
3. Use the option of "ASN.1 ASP/PDU type Definitions by Reference" whenever applicable.
4. Example 14 shows a compatibility problem that could occur, when ASN.1 type declarations as well as tabular type declarations are used in an ATS. Use the ATS Conventions to describe how this compatibility problem is handled in the ATS, i.e. whether in expressions and assignments entities defined in ASN.1 are only related to entities defined in ASN.1 or not.

1. Use simple type or ASN.1 type definitions whenever an object of a base type with given characteristics (length, range, etc.) will be referenced more often than once.
2. Use the optional length indication in the field type or parameter type column of structured type and ASP/PDU type definitions whenever the base standard/profile restricts the length.

NOTE 1: This can often be achieved by references to simple types.

1. Map the applicable ASPs/PDUs from the service/protocol standard to corresponding ASP/PDU type definitions in the ATS.

NOTE 2: It may happen that not all ASPs/PDUs of a service/protocol standard are applicable to a particular ATS for the related protocol. It may also happen that additional ASP/PDU type declarations are necessary, e.g. to create syntactical errors.

1. Map the structure of ASPs/PDUs in the service/protocol standard to a corresponding structure in the ATS.

NOTE 3: This mapping is not always one-to-one, e.g. because a field in the PDU definition of the protocol standard is always absent under the specific conditions of an ATS. But it should normally not happen, that a structured element in the protocol standard is expanded using the "<-" macro expansion, so that the individual fields are still referenced, but the structure is lost in the ATS.

1. Use a test suite operation only if it cannot be substituted by other TTCN constructs.
2. Write down the rationale/objective of the test suite operation.
   Reference standards if applicable.
3. Classify and simplify algorithm.
   Split test suite operation if too complex.
4. Choose an appropriate specification language depending on the rationale/objective:
   – predicates for Boolean tests;
   – abstract data types for manipulation of ASN.1 objects;
   – programming languages for simple calculation.
5. Check/proof the test suite operation:
   – is the notation used known/explained;
   – are all alternative paths fully specified;
   – is the test suite operation returning a value in all circumstances;
   – are error situations covered (empty input variables, etc.).
6. State some evident examples.

1. Develop a design concept for the complete constraints part, particularly with respect to the "conflicting" features as indicated in items i) to iv) and including naming conventions (see ETR 141 [37] clause 6).
2. Make extensive use of the different optional "Comment" fields in the constraint declaration tables to highlight the peculiarity of each constraint.

1. Define different base constraints for the send- and receive direction of a PDU (when applicable).
2. Use modified constraints preferably when only a small number of fields or parameter values are altered with respect to a given base.

NOTE 1: For SEND events the creation of a further modified constraint can sometimes be avoided, if an assignment is made in the SEND statement line, thus overwriting a particular constraint value.

1. Design the relation between base constraints and modified constraints always in connection with parameterization of constraints (see the two subsequent subclauses).

NOTE 2: Additional parameters in a constraint, introduced to avoid the declaration of further base/modified constraints can reduce the amount of constraints needed in an ATS, but then the constraint reference is getting more and more unreadable.

1. When modified constraints are used, keep the length of the derivation path small. The length of the derivation path (resulting from the number of dots in it) is a kind of nesting level, and it is known from experience that a length greater than 2 is normally difficult to overview and maintain.

1. Make a careful evaluation of which embedded PDUs are needed in ASPs/PDUs, in which (profile) environment the ATS may operate and which kind of parameterization for other parameters/fields is needed, to find an appropriate balance between the use of static and/or dynamic chaining in a particular ATS.
2. When the ATS is used in different profile environments and the types and values of embedded PDUs cannot be predicted, dynamic chaining is normally the better choice.
3. When static chaining is used, chose the name of the ASP/PDU constraint such that it reflects the peculiar value of the embedded PDU (see also the clause on naming conventions in ETR 141 [37]).

1. Make a careful overall evaluation of which field/parameter values are needed in ASPs and PDUs to find an appropriate balance between the aim of a comparably small number of constraint declarations and readable and understandable constraint references.
2. Keep the number of formal parameters small.
   Keep in mind, that the number of formal parameters in structured/ASN.1 types Constraints will add up to the total number of ASP/PDU constraints.
   A clear border for the number of formal parameters cannot be stated, but it is known from experience that a number bigger than 5 normally cannot be handled very well.

1. Use comments to highlight the peculiarity of the value, especially when the value is a literal, whose meaning is not apparent.
2. Use test suite constants instead of literals, when appropriate.
   Normally not all literals can be defined as Test Suite Constants, but a rule by thumb is: if a literal value of a given type occurs more than once (as a constraint value or more generally in an expression), then it is useful to define it as a Test Suite Constant, letting the name reflect the value.
3. Use the length attribute when possible and when the length is not implicit in the value itself or given by the type definition (e.g. for strings containing "*").

Make sure that verdict assignment within a default tree is in relation to the test body. If an unsuccessful event arising in the test body is handled by the default tree, then assign a preliminary result "(FAIL)" within the corresponding behaviour line of the default tree. If the position of the unsuccessful event is not in the test body, assign a preliminary result "(INCONCLUSIVE)". If the behaviour line handling the unsuccessful event is a leaf of the default tree, assign a final verdict instead.

The entry of the test body should be marked.

For realizing test purposes dependent on protocol states, use a variable to reflect the current state of the IUT.

Combine event sequences used for checking a state of the IUT within test steps.

For easy adaptation of a test step to test case needs, parameterize the constraints used within a test step.

Minimize the complexity of test steps either by restricting the objective of a test step to atomic confirmed service primitives or by separating event sequences, which build different "logical" units into different test steps.

Keep the nesting level of test steps to a minimum.

Avoid recursive tree attachment. Where possible, use loops instead of recursive tree attachments.

If verdicts are assigned within a test step, guarantee at least the partial (i.e. not general) re-use of the test step.

Use parameterized test steps to ensure re-use of test steps within test cases for different needs.

If there is no Boolean expression included in an alternative sequence, a statement of type UCS (unconditional statement) should never be followed by a statement of type UCS or CS (conditional statement) within a sequence of alternatives.

1. A relational expression should never restrict the value range of a preceding relational expression in the same alternative sequence using the same variable.
2. The value range of a relational expression should be different from the whole value range of all preceding relational expressions in the same alternative sequence using the same variable.

Do not use conditions for terminating loops, which depend only on the behaviour of the IUT.

1. Make sure that each alternative sequence of receive events contains an OTHERWISE statement (without any qualifier) for each PCO.
2. Make sure that each alternative sequence of receive events contains at least one TIMEOUT event (implying that a corresponding timer was started).

1. Use only event sequences leading to the test body within a preamble.
2. Handle all event sequences not leading to the test body within the default tree of the test case/step.
3. If the very same event sequence can be used to transfer the IUT from each possible state to the idle state, then realize this event sequence as a postamble.

Avoid recursive test component configuration declarations.

Special care should be taken by using a RETURN statement within a default tree in order to avoid an endless loop resulting from the expansion of the default tree.