ETSI ETR 293-2-1998 Terrestrial Trunked Radio (TETRA) Air Interface (AI) Layer 2 and 3 Protocol Validation Part 2 Validation of SDL Models for Packet Data Optimized (PDO)《陆地集群无线电(T_1.pdf

《ETSI ETR 293-2-1998 Terrestrial Trunked Radio (TETRA) Air Interface (AI) Layer 2 and 3 Protocol Validation Part 2 Validation of SDL Models for Packet Data Optimized (PDO)《陆地集群无线电(T_1.pdf》由会员分享，可在线阅读，更多相关《ETSI ETR 293-2-1998 Terrestrial Trunked Radio (TETRA) Air Interface (AI) Layer 2 and 3 Protocol Validation Part 2 Validation of SDL Models for Packet Data Optimized (PDO)《陆地集群无线电(T_1.pdf（42页珍藏版）》请在麦多课文档分享上搜索。

1、STD-ETSI ETR 293-2-ENGL 3%98 = 3400855 0336623 990 ETSI T. ETR 293-2 June 1998 Source: TETRA Reference: DTWTETRA-04012-2 ICs: 33.020 Key words: TETRA, protocol, validation, SDL, PDO Terrestrial Trunked Radio (TETRA); Air Interface (AI) layer 2 and 3 protocol validation; Part 2: Validation of SDL mod

2、els for Packet Data Optimized (PDO) ETSI European Telecommunications Standards Institute ETSI Secretariat Postal address: F-O6921 Sophia Antipolis CEDEX - FRANCE Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE Internet: secretariat Q etdfr - http:/www.etsi.fr - http:/ww

3、w.etsi.org Tel .: +33 4 92 94 42 O0 - Fax: +33 4 93 65 47 16 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. O European Telecommunications Standards Institute 1998. All righ

4、ts reserved. STD-ETSI ETR 293-2-ENGL L998 = 3400855 03Lbb24 823 Page 2 ETR 293-2: June 1998 Whilst every care has been taken in the preparation and publication of this document, errors in content, typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to “E

5、TSI Standards Making Support Dept.“ at the address shown on the title page. - STD-ETSI ETR 293-2-ENGL L998 3400855 0336625 763 Page 3 ETR 293-2: June 1998 Contents Foreword 5 1 Scope . 7 2 References 7 3 Definitions and abbreviations . 7 3.1 Definitions . -.- 7 3.2 Abbreviations . 7 . 4 Introduction

6、 8 5 General . 6 5.1 The validation principles 8 5.2 Validation architecture 10 5.3 The validation process 1.1 5.3.1 Protocol validation process . 11 5.3.2 Protocol stack validation process 11 5.3.3 Validation result analysis . 12 Documentation of the validation process . 12 5.3.4 Tool support 12 5.

7、4 5.5 Validated protocols 13 6 Protocol validation . 14 6.1 6.2 6.3 6.4 6.5 MM entity . ._._ 15 6.1.1 Validation purposes . 15 6.1 . 1 . 1 Registration 15 6.1.1.2 Group attachment - detachment 15 6.1.2 Options, constants and parameters 15 6.1.3 Validation results . 16 CONP entity 23 6.2.1 Validation

8、 purposes . 23 6.2.1.1 Data transfer 23 6.2.2 Options. constants and parameters 23 6.2.3 Validation results . 23 SCLNP entity 25 6.3.1 Validation purposes . 25 MLE entity . 31 6.4.1 Validation purposes . 31 6.4.1.1 6.4.1.2 Data transfer 31 6.4.1.3 6.4.1.4 6.4.2 Options. constants and parameters 31 6

9、.4.3 Validation results . 32 Layer 2 entity 35 6.5.1 Validation purposes . 35 6.3.2 6.3.3 Validation results . 25 Options. constants and parameters 25 Attachment management procedures . 31 Network broadcast procedures 31 Management entity procedures . 31 6.5.1.1 6.5.1.2 6.5.1.3 6.5.1.4 6.5.1.5 Downl

10、ink - Acknowledged - Single SDU 35 Downlink - Acknowledged - Chained SDU 35 Downlink - Unacknowledged - Single SDU 35 Uplink - Acknowledged - Single SDU 35 Uplink - Acknowledged - Chained SDU . 35 Options, constants and parameters 36 Validation results . 36 6.5.2 6.5.3 STDmETSI E. TR 2%3-2-ENGF k996

11、 35rt3Q855 -133bb2b bTT =i Page 4 ETR 293-2: June 1998 7 Protocol stack validation . 40 7.1 Validation purposes 40 7.2 7.3 Validation results . 40 Options. constants and parameters 40 8 Validation result summary 41 Annex A: Validation files on floppy disk . 42 History 43 STD-ETSI ETR 293-2-ENGL 1998

12、 m 3400855 0336627 53b m Page 5 ETR 293-2: June 1998 Foreword This ETSI Technical Report (ETR) has been produced by the TErrestrial TRunked RAdio (TETRA) Project of the European Telecommunications Standards Institute (ETSI). ETRs are informative documents resulting from ETSI studies which are not ap

13、propriate for European Telecommunication Standard (ETS) or Interim European Telecommunication Standard (LETS) status. An ETR may be used to publish material which is either of an informative nature, relating to the use or the application of ETSs or I-ETSs, or which is immature and not yet suitable f

14、or formal adoption as an ETS or an LETS. This ETR consists of 3 parts as follows: Part 1: “Validation of SDL models for Voice plus Data“; Part 2: “Validation of SDL models for Packet Data Optimized (PDO)“; Part 3: “Validation of SDL models for Security functions“. STDmETSI ETR 293-2-ENGL L778 M 3400

15、855 03Lbb28 472 S Page 7 ETR 293-2: June 1998 1 Scope This ETSI Technical Report (ETR) defines the methods, procedures, and validation purposes used for the formal validation of the Specification and Description Language (SDL) model of TETRA Packet Data Optimized Interface and documents the results

16、of the validation. The validation of the TETRA SDL-specifications inside the scope of this ETR covers the TETRA Air Interface, layer 2 and 3 protocols for Packet Data Optimized. 2 References For the purposes of this ETR the following references apply: ETS 300 393-1 (November 1995): ?Radio Equipment

17、and Systems (RES); Trans-European Trunked RAdio (TETRA) system; Packet Data Optimized; Part 1 : General network design?. ETS 300 393-2 (November 1995): ?Radio Equipment and Systems (RES); Trans-European Trunked RAdio (TETRA) system; Packet Data Optimized: Part 2: Air Interface?. ITU-T Recommendation

18、 Z.l O0 (1993): ?Specification and description language (SDL)?. ITU-T Recommendation Z.120 (1 993): ?Message sequence charts?. iS0.8348: ?Information processing systems - Data communications - Network service definition?. 180.8878: ?Use of X.25 to provide the OS1 connection mode network service?. 18

19、0.8648: ?information processing systems - Internal organisation of the network layer?. Definitions and abbreviations Defini ti ons For the purposes of this ETR, the following definitions apply: validation case: A sequence of validation events designed to achieve a particular validation purpose. vali

20、dation model: A model for the protocol specified with a formal description technique, in this case, SDL. validation purpose: A single requirement of a protocol in the scope of validation. vaiidatlon script: A validation case or a subset of it presented in a manner that can be used to activate and tr

21、ace the protocol transitions in execution of the validation model. 3.2 Abbreviations For the purposes of this ETR, the following abbreviations apply: BS cc IE GTSI ITS1 LLME MCC Base Station Call Control sub-entity within CMCE Information Element Group TETRA Subscriber Identity Individual TETRA Subs

22、criber Identity Lower Layer Management Entity Mobile Country Code Previous page is blank _ STD-ETSI ETR 293-2-ENGL $998 3400855 031ibb29 309 Page 8 ETR 293-2: June 1998 MLE MM MNC MNI MS MSC PDU QoS RPDI SCLNP SAP SDL SDS SDU SP SSI TDMA TE I TETRA TL-SDU TLA-SAP TLB-SAP TLC-SAP TS I V+D Mobile Link

23、 Entity Mobility Management Mobile Network Code Mobile Network Identity Mobile Station Message Sequence Chart Protocol Data Unit Quality of Service Radio Packet Data Interface Specific Connectionless Network Protocol Service Access Point Specification and Description Language Short Data Services sub

24、-entity within CMCE Service Data Unit Service Prim i tive Short Subscriber Identity Time Division Multiple Access TETRA Equipment Identity TErrestrial Trunked RAdio SDU from the LLC service user, .e. MLE A layer 2 Service Access Point A layer 2 Service Access Point A layer 2 Service Access Point TET

25、RA Subscriber Identity Voice plus Data 4 Introduction This ETR documents the validation of the TETRA protocols for the PDO Air Interface, ETS 300 393-2 2. The overall purpose of the validation is to check that the required service and protocol functionality is supported by the specified protocols of

26、 the MS side. The validation of the protocols under the scope of this ETR has been performed using the latest specification methodologies, techniques and tools available. Code generation was used to create an executable validation model from the SDL specification. The executable validation model was

27、 then used for simulation against the selected set of protocol requirements. The simulation was performed using advanced simulation techniques, including Message Sequence Chart (MSC) trace generation. During the specification and simulation of the validation model a number of minor errors and ineffi

28、ciencies in the protocol descriptions were identified. These errors and inefficiencies are documented, and generally a proposal for solution is given in this ETR. The validation has demonstrated that an operational TETRA PDO Air Interface protocol stack can be implemented according to ETS 300 393-2

29、2. 5 General 5.1 The validation principles The validation of the required service functionality is performed using a set of selected requirements, derived from the textual protocol specifications. The selected requirements are expressed in terms of validation cases. Also a validation model is derive

30、d from the same textual protocol specifications. This validation model should reflect correctly the defined protocol behaviour. These principles are illustrated in Figure 1. The purpose of the validation is to check if the validation model satisfies the selected requirements, and hence if the protoc

31、ol descriptions correctly define the service functionality. Use of two independent formalizations of the textual standard improves the probability that the protocol description is consistently expressing the validated requirements. STD-ETSI ETR 293-2-ENGL 1998 3400855 0336630 O20 D Page 9 ETR 293-2:

32、 June 1998 71 (Textual protocoll Figure 1: The principle of the valldatlon process The value of validation using this approach is heavily dependent on the quality of the mapping from the selected requirements of the textual protocol specification to the validation cases representing the validation r

33、equirements. However it is necessary to formalise the textual protocol specification in order to allow the validation process to be carried out by computer tools. The formalization is done by converting the textual protocol specification into SDL and expressing the validation cases in terms of MSCs.

34、 The requirements for a protocol can be categorised into three different classes referring to the following three aspects of protocol validation: 1) service validation; 2) protocol validation; 3) protocol stack validation. Service validation is checking that the requirements at the service interface

35、 are satisfied by a single protocol entity. Protocol validation includes single protocol entity validation and peer-to-peer validation. Single protocol entity validation is concentrated on the mapping between service primitives and PDUs. Additionally, peer- to-peer validation covers the PDU exchange

36、 between peer entities. Protocol stack validation is validation of protocol entities of different layers linked together STD=ETSI ETR 293-2-ENGL 1998 31.i0085.5 03Lbb3L Tb? M Page 10 ETR 293-2: June 1998 5.2 Validation architecture The general outline of the validation performed is illustrated in Fi

37、gure 2, where also the relationship with the three concepts of Figure 1 is indicated. . . . Va lidat ion Figure 2: Architecture of the validation The validation model and the validation cases are established based on the textual protocol specification. The validation model is implemented as SDL spec

38、ifications for each protocol as recommended by ITU-T Recommendation Z.l O0 3. Validation cases and validation traces are presented as MSC-diagrams. MSC-diagrams follow the corresponding ITU-T Recommendation Z.120 4. All important requirements of the protocols must be expressed in the scope of valida

39、tion purposes and thus, also in the validation cases. Additionally, an MSC only specifies a single sequence of validation events. So for that reason a set of MSCs may be needed for the specification of one validation case. An MSC of a validation case contains a representation of an N - service user,

40、 N - protocol, N - formatter, and (N-1) - service provider. So the protocol events, .e. N - SPs, N - PDUs and (N-1) - SPs can be traced from an MSC respectively. Hence validation of protocol behaviour requirements is done in terms of the protocol events of the validation cases. In addition, requirem

41、ents on the data part of the protocols must be validated. An exhaustive validation is not feasible due to the number of combinations of data values. So a limited number of combinations of data values are selected. The particular data values selected should ensure that all unique behaviours of the pr

42、otocol are validated. To perform the validation, the validation model has to be made ready for simulation, .e. executable. This is done automatically by the tools used for the validation. In order to perform the simulation, a set of validation scripts has been derived from the validation cases. This

43、 has been done by providing all the necessary signals and parameters to make a validation case executable in combination with the executable validation model. In addition, the validation scripts contain commands to configure the simulation environment, 0.g. breakpoint settings. Since the format of t

44、he validation scripts is tool-dependent and the scripts are only used to send the necessary protocol events already presented in the validation cases to the executable validation model, they are not part of the documentation of the validation process. STD-ETSI ETR 293-2-ENGL 3978 3i)DQ855 0336632 9T

45、3 W Page 11 ETR 293-2: June 1998 Finally, validation traces can be produced by executing the validation model. These traces are then compared to the validation cases and the result analysis of the validation follows. Only validation traces of the whole protocol stack are included in the documentatio

46、n of the validation process, since also protocol events of the individual protocol entities can be extracted from these traces. A minimum requirement for the validation performed is that all parts of the validation cases have been verified at least once during the validation. NOTE: The validation is

47、 restricted to the MS side of the protocols, but a parallel model for the BS side is made for simulation purposes solely. Due to this, the BS model is not part of the validation documentation. 5.3 The validation process To accomplish the validation results, the following validation scheme has been u

48、sed to implement the validation principles described in sub-clause 5.1 : - protocol validation process: - protocol stack validation process. In this scheme the service validation is performed in two parts. First part of the service validation is performed as part of the protocol validation, when the

49、 SP - PDU relationship inside a protocol entity is validated. Second part of the service validation is performed while incrementally validating the protocol stack. That is when the interaction between a protocol entity and the one above it inside one stack is validated. For the highest service interface inside the scope of the validation, the service validation is done manually during the validation sessions, e.g. validation script acting as a service user of the protocol. So following this scheme validation results for all three categories of requiremen