ETSI ES 202 912-5-2003 Access and Terminals (AT) Short Message Service (SMS) for PSTN ISDN Test Suites for SMS User Based Solution Part 5 Test Suite Structure and Test Purposes (TS_1.pdf

《ETSI ES 202 912-5-2003 Access and Terminals (AT) Short Message Service (SMS) for PSTN ISDN Test Suites for SMS User Based Solution Part 5 Test Suite Structure and Test Purposes (TS_1.pdf》由会员分享，可在线阅读，更多相关《ETSI ES 202 912-5-2003 Access and Terminals (AT) Short Message Service (SMS) for PSTN ISDN Test Suites for SMS User Based Solution Part 5 Test Suite Structure and Test Purposes (TS_1.pdf（70页珍藏版）》请在麦多课文档分享上搜索。

1、ETSI ES 202 912-5 1.1.1 (2003-02) ETSI Standard Access and Terminals (AT); Short Message Service (SMS) for PSTNASDN Test Suites for SMS User Based Solution; Part 5: Test Suite Structure and Test Purposes (TSS Essential, orpotentially Essential, IPRs notlJied to ETSI in respect ofETSI standards“, whi

2、ch is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (5). All published ETSI deliverables shall include information which directs the reader to the above source of information. Foreword This ETSI Standard (ES) has been produced by ETSI Technical Committee Ac

3、cess and Terminals (AT). The present document is part 5 of a multi-part deliverable. Full details of the entire series can be found in part 1 lo. ETSI 6 ETSI ES 202 912-5 VI .I .I (2003-02) 1 Scope The present document provides test suite structure and test purposes for testing Data Link layer in a

4、Terminal Equipment implementing the Short Message Service (SMS) for PSTNASDN, UBS Protocol 2 according to ES 201 912 i. Basic ISDN or PSTN call procedures apply in order to establish a circuit-switched band connection between such Terminal Equipment and an SM-SC. Tests for these procedures are outsi

5、de the scope of the present document. UBS2 terminals send and receive Data Link messages in the voice-band connection using the FSK signalling as defined in EN 300 659-2 3 and ES 200 778-2 6. Tests for the FSK signalling are also outside the scope of the present document. Terminal Equipment implemen

6、ting the Short Message Service (SMS) for PSTNASDN according to UBS Protocol 2 are required to implement the Transfer Layer according to ES 20 1 9 12 i. Using the Remote Single Layer Embedded Test Method (see ISO/IEC 9646-2 9) for the UBS Protocol 2 Data Link layer , Transfer Layer messages appear he

7、re only as octet string parameters of Data Link layer messages. Tests for the Transfer Layer are not within the scope of the present document. Figure 1 gives an overview of the reference architecture used for the UBS Protocol 2 operation. Figure 2 shows the configuration used for testing. ISO/IEC 96

8、46-1 8 and ISO/IEC 9646-2 9 are used as the basis for the test specification methodology. 2 Re fe re nces The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication

9、 andor edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. Referenced documents which are not found to be publicly available in the expected location might be found at htlu:/docbox.e

10、tsi.or:eerence. il ETSI ES 201 912 (Vl.l.1): “Access and Terminals (AT); Short Message Service (SMS) for PSTNASDN; Short Message Communication between a fixed network Short Message Terminal Equipment and a Short Message Service Centre“. ETSI EN 300 659-1 (V1.3.1): “Access and Terminals (AT); Analogu

11、e access to the Public Switched Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) services; Part 1 : On-hook data transmission“. ETSI EN 300 659-2 (V1.3.1): “Access and Terminals (AT); Analogue access to the Public Switched Telephone Network (PSTN); Sub

12、scriber line protocol over the local loop for display (and related) services; Part 2: Off-hook data transmission“. ETSI ES 200 659-3 (V1.3.1): “Access and Terminals (AT); Analogue access to the Public Switched Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and re

13、lated) services; Part 3: Data link message and parameter codings“. 21 31 41 ETSI ES 200 778-1 (V1.3.1): “Access and Terminals (AT); Analogue access to the Public Switched Telephone Network (PSTN); Protocol over the local loop for display and related services; Terminal equipment requirements; Part 1

14、: On-hook data transmission“. ETSI ES 200 778-2 (V1.3.1): “Access and Terminals (AT); Analogue access to the Public Switched Telephone Network (PSTN); Protocol over the local loop for display and related services; Terminal equipment requirements; Part 2: Off-hook data transmission“. ETSI 7 ETSI ES 2

15、02 912-5 VI .I .I (2003-02) 71 ETSI ES 202 912-4 (Vl.l.1): “Access and Terminals (AT); Short Message Service (SMS) for PSTN/ISDN Test Suites for SMS User Based Solution; Part 4: Protocol Implementation Conformance Statement (PICS) proforma specification user side for Data Link Layer Protocol 2“ ISO/

16、IEC 9646- 1 : “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1 : General concepts“. ISO/IEC 9646-2: “Information technology - Open systems interconnection - Conformance testing methodology and framework - Part 2: Abstract test suite spec

17、ification“. ETSI ES 202 912-1 (Vl.l.1): “Access and Terminals (AT); Short Message Service (SMS) for PSTNASDN; Test Suites for SMS User Based Solution; Part 1 : Protocol Implementation Conformance Statement (PICS) proforma specification user side for Data Link Layer (DLL) Protocol 1“. SI 91 lo1 3 3.1

18、 Definitions and abbreviations De fi nit ions For the purposes of the present document, the following terms and definitions apply: DL-Initiator: entity (SM-TE or SM-SC) initiating a data link connection to the peer entity by sending a DL establishing message (after the VB-connection has been establi

19、shed) DL-Responder: entity (SM-TE or SM-SC) having received a DL establishing message from the peer entity (after the VB-connection has been established) incoming VB-connection: VB-connection initiated by an SM-SC inopportune behaviour (of the tester): The tester sends a message which is not expecte

20、d by the IUT under the current circumstances (state). invalid behaviour (of the tester): abbreviated form of “syntactically invalid behaviour“, i.e. the tester sends a message where the presence or contents of one or more parameters or fields does not conform to the requirements Lower Test System (L

21、TS): part of the Test System performing basic signalling procedures to establish a VB-connection and to transmit and receive FSK frames originator (of an SM): SM-TE sending an SM to another SM-TE outgoing VB-connection: VB-connection initiated by an SM-TE peer (entities): SM-TE and SM-SC, for which

22、a voice-band connection exists or is pending, are considered as peers valid behaviour (tests): The tester behaves according to the protocol. NOTE: Timeout tests normally belong to the valid tests. VB-connection: voice-band connection between two peers, considered to be completed or established, when

23、 the basic call control procedures, performed according to the type of network access the SM-TE is connected to (i.e. PSTN or BRA ISDN or PRA ISDN), are completed and the voice-band connection is ready for FSK frame transfer NOTE: In order to establish an incoming VB-connection, the CLI information

24、has to be previously provided to the terminal equipment. The way of providing CLI (e.g. by DTMF or FSK signalling and using a data transmission associated with ringing or not, etc., in the case of PSTN) is out of the scope of the present document . VB-Initiator: entity (SM-TE or SM-SC) initiating a

25、voice-band connection to the peer entity VB-Responder: entity (SM-TE or SM-SC) having received a voice-band connection attempt from the peer entity ETSI 8 SM-SC Network (store while the expression “a .message“ is used when they can vary (e.g. a DLL-SMS-INFO (SMS-SUBMIT) message, where the SMS-SUBMIT

26、 TL message depends on the SM composed by the user, or a DLL-SMS-ENQ message with wrong checksum, where the wrong checksum byte is different from the correct value). D LL-S M S- E N Q D LL-S M S- RE L DLL-SMS-UNKNOWN 6.5 UBS2 DLL messages (PDUs) Used to recover a transmission error or to maintain ac

27、tive the Data Link layer. Carries a Data Link Layer connection release command. Unknown message, .e. a message not being defined in ES 201 912 I. This message is only be transmitted by the tester in order to create an error. 6.5.1 List of UBS2 DLL messages Table 16 lists the UBS2 DLL messages used i

28、n the present document. Table 16: List of UBS2 Data Link layer messages ETSI 19 ETSI ES 202 912-5 VI .I .I (2003-02) Octet(s) Message Type octet Subfield Short field name Description Extension bit E 1 bit (most significant bit in Message Type octet). Used for DLL extension mechanism (segmentation an

29、d re-assembly of Payloads longer than 255 octets). 7 bits (least significant bits in Message Type octet). Identifies the type of the DLL message. Message type MT field Message length Payload The short field names in table 17, e.g. MT, are the abbreviated field names as they appear in DLL messages oc

30、curring in test behaviour descriptions, when appropriate. NOTE 1: Clause 6.3.2 of ES 201 912 i specifies also the “Channel Seizure“, the “Mark signal“ and the “Checksum“. These message elements do not appear in the message structure definition used in the present document, but are treated in the ASP

31、S used for DLL message transmission and reception. The following principle applies for messages to be transmitted by the tester: The Message type field is not shown explicitly, because it is identified by the message name. If the Extension bit is not shown explicitly, it is understood that the bit v

32、alue “O“ (no segmentation) is sent. The Message length is not shown explicitly, the contents of the Message length octet is the binary coding of the number of octets in the payload. - ML Length of Payload (in octets). PL Octet string of maximum length 255; optional, .e. not present in all DLL messag

33、es. If the Payload is not shown explicitly, it is omitted. If the Payload is shown explicitly, it refers to a Test Parameter (see table 18) to be transmitted. The following principle applies for messages to be received from the IT: The Message type field is not shown explicitly, because it is identi

34、fied by the message name. If the Extension bit is not shown explicitly, it is understood that the bit value “O“ (no segmentation) has to be received. The Message length is not shown explicitly. The contents of the received Message length octet has to be the binary coding of the number of octets in t

35、he payload (otherwise the message is not passed to the LT by the LTS). If the Payload is not shown explicitly, it is assumed that no Payload has to be received in this message. If the Payload is shown explicitly, it either refers to a Test Parameter (see table is), or it explicitly indicates “OMIT“,

36、 or it indicates one of the wildcards Any (?) or AnyOrOmit (*). NOTE 2: The wildcards Any and AnyOrOmit and their symbols ? and * have been borrowed from TTCN and have the same semantics: ? means that any non-empty value compatible with the type of the referred field is received, * means that either

37、 nothing is received, or any non-empty value compatible with the type of the referred field is received. ETSI 20 ETSI ES 202 912-5 VI .I .I (2003-02) EXAMPLES : 6.6 ! DLL-SMS-E ST A correct DLL-SMS-EST message is sent. A syntactically correct DLL-SMS-INFO-MT message is sent, with the Payload represe

38、nted by Test Parameter “TSPX-SMS-DELIVER-S 1 I, which contains a default TL SMS-DELIVERY message. A syntactically correct DLL-SMS-INFO-MO message is received, where the extension bit is set to “1“ (i.e. “further segment follows“), and the Payload is any octet string of length up to 255 octets. !DLL-

39、SMS-INFO-MT (PL=TSPX-SMS-DELIVER-S 1) ?DLL-SMS-INFO-MO (E=l, PL=?) Behaviour notation This clause describes the principles used when filling the “Test description“ entry of the TP tables (see sample in clause 5.7) and the behaviour notation of preambles and postambles. The notation used to describe

40、the trees containing the required operations and signalling control primitives, is a TTCN-like notation, showing what is sent (character !) and received (character ?) by the tester (playing the role of the SM-SC). ASPs are sent as shown in the following TTCN-like form: O!OUTGOING-CALL-req where O de

41、notes the PCO used with the ASP, ! denotes “transmission“ and the ASP name follows. Since default values have been defined for the ASP parameters, parameter values are only indicated when they differ from the default value. EXAMPLE 1: O!OUTGOING-CALL-req(TFNUM=2) In this case 2 SMs are requested to

42、be transmitted by the SM-TE during the VB connection (instead of default 1 SM to be transmitted). The same principle applies for received ASPs, the symbol ! being replaced by ?. EXAMPLE 2: CC?OUTG-CALL-ind In this case the LT receives an indication from the LTS that there is an incoming call from th

43、e SM-TE (being requested at the SM-TE as in example 1). There is one important exception for the presentation of ASPs: To increase the readability, ASP names TRANSFER-req and TRANSFER-ind are not shown, except when a DLL message is to be transmitted with an error in the “Channel Seizure“ or the “Mar

44、k signal“ or the “Checksum“. DLL message names are directly used instead for transmission and reception. For examples see clause 6.5.2. Use of timers: There are two classes of timers assumed in the tester: a) b) operational timers, verif$ng receipt of a response from the IUT or verif$ng non-reaction

45、 of the IUT; and timers used to veriSl the correct timeout range of protocol timers implemented in the IUT. Timers of class a) do not explicitly appear in the test descriptions of the present document. It is assumed, that the tester starts an operational acknowledge timer when expecting some event f

46、rom the IUT, and that the timer is stopped when the expected event occurs. ETSI 21 ETSI ES 202 912-5 VI .I .I (2003-02) When a protocol timer is claimed to be implemented with a specific timeout value, the tester can never ver the exact timeout value, because of transmission delays and operational d

47、elays in the IUT and the tester, but only an accepted time interval. The timers of class b) are therefore normally defined in pairs: one for the lower accepted boundary value and one for the upper boundary value. As an example, timers TIMER-TmlMINUS and TIMER-Tml-PLUS have been defined for the verif

48、ication of protocol timer Tml implemented in the IUT. When it has to be verified that Tml is in the allowed interval, the following sequence appears in test descriptions (note that in all test descriptions the expected order of events is shown): START TIMER-TmlMINUS START TIMER-Tml-PLUS ?TIMEOUT TIM

49、ER-TmlMINUS The meaning of this sequence is: At fiist both timers supervising the boundary values are started. Then the timer for the lower boundary value expires. This verifies that the expected event may not occur too early. Then the expected received event is indicated and no timeout of the timer for the upper boundary value is indicated. This ensures that the expected event occurs before timeout of the timer for the upper boundary value (TIMER-Tml-PLUS). It is assumed, and not explicitly shown, that TIMER-Tml-PLUS is stopped when the expected event oc