1、ETSI ES 202 912-2 1.1.1 (2003-02) ETSI Standard Access and Terminals (AT); Short Message Service (SMS) for PSTNIISDN; Test Suites for SMS User Based Solution; Part 2: Test Suite Structure and Test Purposes (TSS Essential, orpotentially Essential, IPRs notlJied to ETSI in respect ofETSI standards“, w
2、hich 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
3、Access and Terminals (AT). The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 SI. ETSI 6 ETSI ES 202 912-2 VI .I .I (2003-02) 1 Scope The present document provides test suite structure and test purposes for testing Data Link layer in
4、a Terminal Equipment implementing the Short Message Service (SMS) for PSTNASDN, UBS Protocol 1 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 out
5、side the scope of the present document. UBS1 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 implem
6、enting the Short Message Service (SMS) for PSTNASDN according to UBS Protocol 1 are required to implement the Transfer Layer according to TS 100 901 7. Using the Remote Single Layer Embedded Test Method (see ISO/IEC 9646-2 lo) for the UBS Protocol 1 Data Link layer , Transfer Layer messages appear h
7、ere 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 Protocol1 operation. Figure 2 shows the configuration used for testing. ISO/IEC 96
8、46-1 9 and ISO/IEC 9646-2 lo 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 publicatio
9、n 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.
10、etsi.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); Analog
11、ue 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); Su
12、bscriber line protocol over the local loop for display (and related) services; Part 2: Off-hook data transmission“. ETSI ES 300 659-3 (V1.3.1): “Public Switched Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) services; Part 3: Data link message and pa
13、rameter coding“. 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 : On-hook data transmission“. ETSI ES 200 778-2 (V
14、1.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 202 912-2 VI .I .I (2003-02) 71 ETSI TS 100 901 (V7
15、.4.0): “Digital cellular telecommunications system (Phase 2+) (GSM); Technical realization of the Short Message Service (SMS) (GSM 03.40 version 7.4.0 Release 1998)“. ETSI ES 202 912-l(Vl.l.1): “Access and Terminals (AT); Short Message Service (SMS) for PSTNASDN; Test Suites for SMS User Based Solut
16、ion; Part 1 : Protocol Implementation Conformance Statement (PICS) proforma specification user side for Data Link Layer (DLL) Protocol 1“. SI 91 ISO/IEC 9646- 1 : “Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1 : General concepts“. ISO/
17、IEC 9646-2: “Information technology - Open systems interconnection - Conformance testing methodology and framework - Part 2: Abstract test suite specification“. lo1 3 3.1 Definitions and abbreviations De fi nit ions For the purposes of the present document, the following terms and definitions apply:
18、 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 established) DL-Responder: entity (SM-TE or SM-SC) having received a DL establishing message from the peer entity (after the VB-connectio
19、n 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 expected by the IT under the current circumstances (state) invalid behaviour (of the tester): abbreviated form of “syntactically invalid
20、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 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
21、 for which a voice-band connection exists or is pending SM-Call: incoming call for a SM-TE where the CLI contains the address of an SM-SC stored in the SM-TE valid behaviour (tests): tester behaves according to the protocol NOTE: Timeout tests normally belong to the valid tests. VB-connection: voice
22、-band connection between two peers NOTE 1 : A Voice-band connection is considered to be completed or established, when 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
23、connection is ready for FSK frame transfer. NOTE 2: In order to establish an incoming VB-connection, the CLI information 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
24、, in the case of PSTN) is out of the scope of the present document . VB-Initiator: entity (SM-TE or SM-SC) initiating a 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-TE (Initiator) ETSI ES
25、 202 912-2 VI .I .I (2003-02) Network SM-SC (PSTNIISDN) (store optional, .e. not present PL lin all DLL messages The short field names in table 13, e.g. MT, are the abbreviated field names as they appear in DLL messages occurring in test behaviour descriptions, when appropriate. NOTE 1: Clause 5.3.2
26、 of ES 201 912 i specifies also the “Mark signal“ and the “Checksum“. Both message elements do not appear in the message structure definition used in the present document, but are treated in the ASPS used for DLL message transmission and reception. The following principle applies for messages to be
27、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 value “1“ (no segmentation) is sent. The Message length is not shown explicitly, the contents of the Me
28、ssage length octet is the binary coding of the number of octets in the payload. If the Payload is not shown explicitly, it is omitted. If the Payload is shown explicitly, it refers to a Test Parameter (see table 14 on page 19) to be transmitted. The following principle applies for messages to be rec
29、eived from the IUT: 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 value “1“ (no segmentation) has to be received. The Message length is not shown explicitly. The contents of th
30、e received Message length octet has to be the binary coding of the number of octets in the 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,
31、 it either refers to a Test Parameter (see table 14 on page 19), or it explicitly indicates “OMIT“, 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
32、any non-empty value compatible with the type of the referred field is received, * means that either nothing is received, or any non-empty value compatible with the type of the referred field is received. ETSI 19 EXAMPLES : ! DLL-SMS-E ST ETSI ES 202 912-2 VI .I .I (2003-02) 6.5 A correct DLL-SMS-EST
33、 message is sent, without payload !DLL-SMS-DATA (PL=TSPX-SMS-DELIVER-S 1) A syntactically correct DLL-SMS-DATA message is sent, with the Payload represented by Test Parameter TSPX-SMS-DELIVER-S l, which contains a default TL SMS-DELIVERY message. ?DLL-SMS-DATA (E=l, PL=?) A syntactically correct DLL
34、-SMS-DATA message is received, where the extension bit is set to “1“ (i.e. “no segmentation“), and the Payload is any octet string of length up to 176 octets. Behaviour notation This clause describes the principles used when filling the “Test description“ entry of the TP tables (see sample in clause
35、 5.7) and the behaviour notation of preambles and postambles. The notation used to describe 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 S
36、M-SC). ASPs are sent as shown in the following TTCN-like form: O!OUTGOING-CALL-req where O denotes 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 th
37、e default value. EXAMPLE 1: In this case 2 SMs are requested to 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 a
38、n indication from the LTS that there is an incoming call from the 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 b
39、e transmitted with an error in the “Mark signal“ or the “Checksum“. DLL message names are directly used instead for transmission and reception. For examples see clause 6.4.2. When the tester expects a reaction from the IUT following the transmission of a PDU or ASP, the start of an “acknowledgement
40、timer“ is assumed, but normally not indicated in the test description. Notes are put into the behaviour descriptions whenever it appears to be necessary. Preambles and Postambles: The description of Preambles and Postamble starts with an Objective definition. ETSI 20 ETSI ES 202 912-2 VI .I .I (2003
41、-02) Test Parameter name The behaviour description ends with the preamble or postamble name. Between start and end the notation is as described above for “Test description“. Each preamble shows the state from where it starts (idle or a different state reached by the execution of another preamble), t
42、hen it shows the operations executed in this preamble and fially the state or configuration reached, using the notation described above. Type Description Each test purpose description shows the state from where it starts by identiSling a preamble. TSPX-SMS-DELIVER-S3 TSPX-S MS-SU B MIT-REP-ACK TSPX-
43、S MS-SU B MIT-REP-NACK TSPX-UNKNOWN-PL TSPX-TOO-LONG-PL 6.6 Parametrization and selection OCTETSTRI N G OCTETSTRI N G OCTETSTRING OCTETSTRING OCTETSTRING NOTE: During the TSS&TP development Test Parameters have been collected in table 14 and 15. Test Parameter names starting with “TSPX“ are used for
44、 test parametrization and will correspond to PIXIT items, TS Parameter names starting with “TSPC“ are used for selection and normally correspond to PICS items. Only Test Parameters referred to in the TP description tables appear here. It is assumed that the Test Parameters defied here will be transf
45、ormed into TTCN “Test Suite Parameters“ in an ATS basing on this TSS&TP, presumably in a one-to-one fashion. Table 14 shows the Test Parameters that are necessary to parameterize the test descriptions to the necessary extent. They will normally appear as ASP parameter values or PDU field contents. I
46、t is also possible that they appear in I brackets as qualifiers for different branches of behaviour (see clause 6.5). Table 14 specifies the Test Parameter name, its type (normally a string, integer or Boolean type) and the explanation what it is used for. Table 14: Test Parameters used for parametr
47、ization (associated with PIXIT items) - - I the SUT. I Address of the SM-SC to be called bv the SUT TSPX SC ADDR I OCTETSTRING TSPX-SMS-DELIVER-SI OCTETSTRI N G (referred to as SMEI). This is the default SME SMS-DELIVER TL message that is used as “default“ SM to be delivered. and is transmitted I as
48、 Payload in a DLL message. I SMS-DELIVER TL message that is used as TSPX-SMS-DELIVER-S2 I OCTETSTRING Com me nts : second message to be delivered on the same VB connection, and is transmitted as Payload in a DLL message. SMS-DELIVER TL message containing a TL error, to be delivered to the IUT. The m
49、essage is expected to provoke a DLL-SMS-NACK message from the IUT. SMS-SUBMIT-REPORT TL message that can be sent by the tester in a DLL-SMS-ACK message as a positive response upon a SM submitted by the SM-TE. SMS-SUBMIT-REPORT TL message that can be sent by the tester in a DLL-SMS-NACK message as a negative response upon a SM submitted by the SM-TE. Payload to be transmitted in the DLL-SMS-UNKNOWN message. Payload longer than 176 octets, to be transmitted in the DLL-SMS-DATA-LONG message. ETSI 21 ETSI ES 202 912-2 VI .I .I (2003-02) Test Parameter name TSPC-
