ETSI EN 300 392-12-14 V1.1.1 (2002-07)
Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 12: Supplementary services stage 3; Sub-part 14: Late Entry (LE)
Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 12: Supplementary services stage 3; Sub-part 14: Late Entry (LE)
DEN/TETRA-03001-12-14
Prizemni snopovni radio (TETRA) - Govor in podatki (V+D) - 12. del: Dopolnilne storitve stopnje 3 - 12.-14. del: Poznejši vstop (LE)
General Information
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Prizemni snopovni radio (TETRA) - Govor in podatki (V+D) - 12. del: Dopolnilne storitve stopnje 3 - 12.-14. del: Poznejši vstop (LE)Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 12: Supplementary services stage 3; Sub-part 14: Late Entry (LE)33.070.10Prizemni snopovni radio (TETRA)Terrestrial Trunked Radio (TETRA)ICS:Ta slovenski standard je istoveten z:EN 300 392-12-14 Version 1.1.1SIST EN 300 392-12-14 V1.1.1:2003en01-december-2003SIST EN 300 392-12-14 V1.1.1:2003SLOVENSKI
STANDARD
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 2
Reference DEN/TETRA-03001-12-14 Keywords late entry, supplementary service, TETRA 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.
DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. SIST EN 300 392-12-14 V1.1.1:2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 3
Contents Intellectual Property Rights.5 Foreword.5 1 Scope.7 2 References.7 3 Definitions and abbreviations.8 3.1 Definitions.8 3.2 Abbreviations.8 4 SS-LE service description.9 4.1 General.9 4.2 SS-LE services offered over the TNSS-SAP and TNCC-SAP.9 4.3 SS-LE service primitives.10 4.3.1 List of SS-LE service primitives.10 4.3.2 ACKNOWLEDGE LE indication.10 4.3.3 ACKNOWLEDGE LE response.10 4.3.4 BROADCAST LE indication.11 4.3.5 DEFINE request.11 4.3.6 DEFINE indication.12 4.3.7 INTERROGATE request.12 4.3.8 INTERROGATE indication.12 4.3.9 PAGING LE indication.13 4.3.10 PAGING LE response.13 4.4 Parameter descriptions.13 5 Signalling protocol for the support of SS-LE.15 5.1 General.15 5.2 SS-LE operational requirements.15 5.2.1 Served user MS/LS.15 5.2.2 Served user SwMI.15 5.2.3 Group controlling SwMI.15 5.2.4 Served user home SwMI.15 5.2.5 Authorized user MS/LS.15 5.2.6 Authorized user SwMI.15 5.2.7 Calling user MS/LS.16 5.3 SS-LE Coding requirements.16 5.3.1 SS-LE PDUs.16 5.3.1.1 General on SS_LE PDUs.16 5.3.1.2 DEFINE PDU.16 5.3.1.3 DEFINE ACK PDU.17 5.3.1.4 INFORM1 PDU.17 5.3.1.5 INFORM2 PDU.17 5.3.1.6 INFORM2 ACK PDU.17 5.3.1.7 INFORM3 PDU.18 5.3.1.8 INFORM3 ACK PDU.18 5.3.1.9 INFORM4 PDU.18 5.3.1.10 INTERROGATE PDU.18 5.3.1.11 INTERROGATE ACK PDU.19 5.3.2 Information element coding.19 5.3.2.1 Basic service type.19 5.3.2.2 Call behaviour.20 5.3.2.3 Defined group extension.20 5.3.2.4 Defined group SNA.20 5.3.2.5 Defined group SSI.20 5.3.2.6 Defined group type identifier.21 5.3.2.7 Interrogated group extension.21 SIST EN 300 392-12-14 V1.1.1:2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 4
5.3.2.8 Interrogated group SNA.21 5.3.2.9 Interrogated group SSI.21 5.3.2.10 Interrogated group type identifier.21 5.3.2.11 LE definition.21 5.3.2.12 LE used over ISI.21 5.3.2.13 Notification indicator.21 5.3.2.14 Range type for defined groups.22 5.3.2.15 Range type for interrogated groups.22 5.3.2.16 Repetition rate.22 5.3.2.17 Result of definition.22 5.3.2.18 Result of interrogation.23 5.3.2.19 SS-LE PDU type.23 5.4 SS-LE protocol states.23 5.4.1 Protocol states of the served user MS/LS.23 5.4.2 Protocol states of the home SwMI.24 5.4.2.1 State IDLE.24 5.4.2.2 State SS-LE ACTIVE.24 5.4.3 Protocol states of the authorized user MS/LS.24 5.4.4 Protocol states of the visited SwMI.24 5.4.4.1 State IDLE.24 5.4.4.2 State SS-LE ACTIVE.24 5.5 SS-LE signalling procedures.24 5.5.1 Address usage.24 5.5.2 Procedures for served user MS/LS.24 5.5.3 Procedures for home SwMI.25 5.5.3.1 Definition in the home SwMI.25 5.5.3.2 Interrogation in the home SwMI.25 5.5.3.3 Invocation and operation in group home SwMI.26 5.5.4 Procedures for FE3.26 5.5.5 Procedures for FE2 in visited SwMI.27 5.5.5.1 Support of SS-LE definition and interrogation in FE2 in visited SwMI.27 5.5.5.2 Support of SS-LE operation in FE2 in visited SwMI.27 5.5.6 Generic SS procedures in the visited SwMI.27 5.6 Protocol timers.27 6 SS-LE FE behaviour.27 6.1 General.27 6.2 Behaviour of FE1.28 6.3 Behaviour of FE2 in home SwMI.29 6.4 Behaviour of FE3.31 6.5 Behaviour of FE2 in visited SwMI.32 7 Interworking considerations.33 History.34
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 5
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 European Standard (Telecommunications series) has been produced by ETSI Project Terrestrial Trunked Radio (TETRA). The present document had been submitted to Public Enquiry as ETS 300 392-12-14. During the processing for Vote it was converted into an EN. The present document is part 12, sub-part 14 of a multi-part deliverable covering Voice plus Data (V+D), as identified below: EN 300 392-1: "General network design"; EN 300 392-2: "Air Interface (AI)"; EN 300 392-3: "Interworking at the Inter-System Interface (ISI)"; ETS 300 392-4: "Gateways basic operation"; EN 300 392-5: "Peripheral Equipment Interface (PEI)"; EN 300 392-7: "Security"; EN 300 392-9: "General requirements for supplementary services"; EN 300 392-10: "Supplementary services stage 1"; EN 300 392-11: "Supplementary services stage 2"; EN 300 392-12: "Supplementary services stage 3"; Sub-part 1: "Call Identification (CI)"; Sub-part 2: "Call Report (CR)"; Sub-part 3: "Talking Party Identification (TPI)"; Sub-part 4: "Call Forwarding (CF)"; Sub-part 5: "List Search Call (LSC)"; Sub-part 6: "Call Authorized by Dispatcher (CAD)"; Sub-part 7: "Short Number Addressing (SNA)"; Sub-part 8: "Area Selection (AS)"; Sub-part 9: "Access Priority (AP)"; Sub-part 10: "Priority Call (PC)"; SIST EN 300 392-12-14 V1.1.1:2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 6
Sub-part 11: "Call Waiting (CW)"; Sub-part 12: "Call Hold (CH)"; Sub-part 13: "Call Completion to Busy Subscriber (CCBS)"; Sub-part 14: "Late Entry (LE)"; Sub-part 16: "Pre-emptive Priority Call (PPC)"; Sub-part 17: "Include Call (IC)"; Sub-part 18: "Barring of Outgoing Calls (BOC)"; Sub-part 19: "Barring of Incoming Calls (BIC)"; Sub-part 20: "Discreet Listening (DL)"; Sub-part 21: "Ambience Listening (AL)"; Sub-part 22: "Dynamic Group Number Assignment (DGNA)"; Sub-part 23: "Call Completion on No Reply (CCNR)"; Sub-part 24: "Call Retention (CRT)"; ETS 300 392-13: "SDL model of the Air Interface (AI)"; ETS 300 392-14: "Protocol Implementation Conformance Statement (PICS) proforma specification"; TS 100 392-15: "TETRA frequency bands, duplex spacings and channel numbering"; TS 100 392-16: "Network Performance Metrics"; TS 100 392-17: "TETRA V+D and DMO Release 1.1 specifications".
National transposition dates Date of adoption of this EN: 12 July 2002 Date of latest announcement of this EN (doa): 31 October 2002 Date of latest publication of new National Standard or endorsement of this EN (dop/e):
30 April 2003 Date of withdrawal of any conflicting National Standard (dow): 30 April 2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 7
1 Scope The present document defines the stage 3 specifications of the Supplementary Service Late Entry (SS-LE) for the Terrestrial Trunked Radio (TETRA). SS-LE allows radio users to be informed of and, if they are concerned, to join an already existing point-to-multipoint speech or data call. Man-Machine Interface (MMI) and charging principles are outside the scope of the present document. Supplementary Service stage 3 specification is preceded by the stage 1 and the stage 2 specifications of the service. Stage 1 describes the functional capabilities from the user's point of view. Stage 2 defines the functional behaviour in terms of functional entities and information flows. Stage 3 gives a precise description of the Supplementary Service from the implementation point of view. It defines the protocols for the service and the encoding rules for the information flows. It defines the processes for the functional entities and their behaviour. The described protocols and behaviour apply for the Switching and Management Infrastructure (SwMI), for the Mobile Station (MS) and for the Line Station (LS) and can be applied over the Inter System Interface (ISI) between TETRA systems. 2 References 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 and/or 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. [1] ETSI EN 300 392-10-14: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 10: Supplementary services stage 1; Sub-part 14: Late Entry (LE)". [2] ETSI EN 300 392-11-14: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 11: Supplementary services stage 2; Sub-part 14: Late Entry (LE)". [3] ETSI ETS 300 392-1: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 1: General network design". [4] ETSI EN 300 392-9: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 9: General requirements for supplementary services". [5] ETSI ETS 300 392-12-7: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 12: Supplementary services stage 3; Sub-part 7: Short Number Addressing (SNA)". [6] ETSI EN 300 392-2: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 2: Air Interface (AI)". [7] ETSI ETS 300 392-3-3: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI); Sub-part 3: Additional Network Feature Group Call (ANF-ISIGC)". [8] ETSI EN 300 392-3-1: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI); Sub-part 1: General design". [9] ITU-T Recommendation Z.100 (1993): "Specification and description language (SDL)". [10] ETSI ETS 300 392-3-5: "Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI); Sub-part 5: Additional Network Feature for Mobility Management (ANF-ISIMM)". SIST EN 300 392-12-14 V1.1.1:2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 8
3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: acknowledge LE: indication sent in LE messages by a SwMI to inform a member who would like to join the call that he has to inform the SwMI of his entering the call authorized user: identified user who is able to define and interrogate the SS-LE parameters broadcast LE: indication sent by a SwMI to inform members of a multipoint call which are currently not already involved in this call that they can join directly an existing communication (a channel is already allocated in this cell) home SwMI: TETRA system in which SS-LE can be defined and invoked.
NOTE: Home SwMI is the TETRA system which has same Mobile Network Identity (MNI) as the TETRA group identity to which SS-LE is defined. paging LE: indication sent by a SwMI to inform members of a multipoint call which are currently not already involved in this call that they need to ask for a communication channel for that call if they wish to participate the call (a channel is not yet allocated in this cell) server user: party that receives the SS-LE indications about an ongoing call and joins the call NOTE: Also known as user B. user B: in a group call a party that receives the SS-LE indications about an ongoing call visited SwMI: TETRA system to which SS-LE can be extended and invoked.
NOTE: Visited SwMI is a TETRA system which has a different MNI as the TETRA group identity to which SS-LE is defined. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: CC Call Control
FE Functional Entity GTSI Group TETRA Subscriber Identity ISI Inter-System Interface LE Late Entry LS Line Station MS Mobile Station SS Supplementary Service NOTE: The abbreviation SS is only used when referring to a specific supplementary service. SwMI Switching and Management Infrastructure SIST EN 300 392-12-14 V1.1.1:2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 9
4 SS-LE service description 4.1 General SS-LE supplementary service enables users to join the group call after the original call setup. SS-LE specifies the definition, interrogation and operation of the supplementary service. The Switching and Management Infrastructure (SwMI) applies the SS-LE definitions when a call is active for the group. The SS-LE actions are defined for the SwMI and for the Mobile Station (MS). The SS-LE information flows may be delivered over the Inter System Interface (ISI). This supplementary service is applicable to circuit mode speech and data group call services defined in EN 300 392-2 [6]. The Functional Entities used in the present document are defined in EN 300 392-11-14 [2]. 4.2 SS-LE services offered over the TNSS-SAP and TNCC-SAP SS-LE is an optional supplementary service for TETRA voice plus data layer 3. If SS-LE is supported, this clause shall specify the services and their availability. The following SS-LE services shall be provided: - late entry indications for a basic service (call control service). The following SS-LE services may be provided: - definition: a request to define SS-LE into the SwMI; - definition information: the reception of SS-LE definition for information; - interrogation: interrogation of SS-LE definition. The SS-LE service access point may be used in conformance testing as a normative (but potentially not accessable) boundary in MSs and LSs. NOTE 1: As the present document only deals with the SS-LE all the service primitives have been shown without a TNSS-LE-prefix e.g. the TNSS-LE DEFINE request is shorten into the DEFINE request. NOTE 2: As man-machine interface and MS/LS applications are outside the scope of the present document service primitives are used to define information exchange to and from the standardized part of the MS/LS. Those primitives may be only indirectly accessible. NOTE 3: The layer 3 services and service boundary for the SwMI are outside the scope of the present document. The SS-LE services described in this clause shall complement the call control service specified in EN 300 392-2 [6], clause 11. SIST EN 300 392-12-14 V1.1.1:2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 10 4.3 SS-LE service primitives
4.3.1 List of SS-LE service primitives
The SS-LE services as defined in EN 300 392-10-14 [1] are accessed in the SS-LE protocol description via service primitives. The SS-LE service primitives at the authorized user MS/LS (FE3) shall be: - DEFINE request; - DEFINE indication; - INTERROGATE request; and - INTERROGATE indication. The SS-LE service primitives at the served user MS/LS (FE1) may be: - BROADCAST LEindication; - ACKNOWLEDGE LE indication; - ACKNOWLEDGE LE response; - PAGING LE indication; and - PAGING LE response. Clauses 4.3.2 to 4.3.10 present the service primitive descriptions in alphabetic order. 4.3.2 ACKNOWLEDGE LE indication
The ACKNOWLEDGE LE indication primitive may be offered from FE1 to application over TNSS-SAP with the corresponding basic call primitive TNCC-SETUP indication indicating an acknowledged group call. The ACKNOWLEDGE LE indication primitive shall contain the SS-LE parameters listed in table 1. The ACKNOWLEDGE indication implies, that application shall send an ACKNOWLEDGE LE response, if it wants to joint in the call. Table 1: ACKNOWLEDGE LE indication contents
Parameter
C/O/M Remark LE type
M Acknowledge LE
4.3.3 ACKNOWLEDGE LE response The ACKNOWLEDGE LE response primitive may be offered from application to FE1 over TNSS-SAP with the corresponding basic call primitive TNCC-SETUP response. Application shall send the primitive if the subscriber joins the call. Application should discard any other ACKNOWLEDGE LE indications to the same call item: - while it is making a response to the received ACKNOWLEDGE LE indication; and - after sending an ACKNOWLEDGE LE response for the same call. However, if the subscriber receives another ACKNOWLEDGE LE indication after leaving the call and if the user wants to re-join in the group call, application shall send a new ACKNOWLEDGE LE response. If the subscriber leaves the acknowledged call, e.g. due to another call, the application shall send a TNCC-RELEASE request which invokes sending of a U-RELEASE PDU to SwMI to indicate that the user leaves the call. If the paging LE is changed to acknowledge LE within a call and if the application has sent a PAGING LE response for that call, the sent PAGING LE response shall be considered also as an ACKNOWLEDGE LE response. SIST EN 300 392-12-14 V1.1.1:2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 11 In case of acknowledge LE, the response shall be sent in the allocated traffic channel, if any. The ACKNOWLEDGE LE response primitive shall contain no SS-LE parameters. 4.3.4 BROADCAST LE indication The BROADCAST LE indication primitive may be offered from FE1 to application over TNSS-SAP with the corresponding basic call primitive TNCC-SETUP indication. The BROADCAST LE indication primitive shall contain the SS-LE parameters listed in table 2. Table 2: BROADCAST LE indication contents Parameter
C/O/M Remark LE type O Broadcast LE
4.3.5 DEFINE request DEFINE request primitive may be offered from application to FE3 over TNSS-SAP. The primitive shall contain the SS-LE parameters listed in table 3. Defined group TETRA identity parameter is a repeatable parameter, which can define one group number, a list of 2 to 15 group numbers or a range of group numbers. Each defined group TETRA identity element shall comprise of any of the following: - address type identifier and Short Number Address (SNA); - address type identifier and Short Subscriber Identity (SSI); or - address type identifier and SSI and address extension (GTSI). SNA, if used and supported, shall refer to the SS-SNA defined for sending authorized user. The SS-LE definition shall be requested to all group numbers given as defined group TETRA identity according to the parameters listed after the defined group TETRA identity. Table 3: DEFINE request contents Parameter
C/O/M Remark Defined group identity M Repeatable LE definition M See note LE used over ISI M See note Basic service type M See note Repetition rate M See note NOTE: This parameter value is common to all defined group identities in this service primitive.
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 12 4.3.6 DEFINE indication
DEFINE indication primitive may be offered from FE3 to application over TNSS-SAP. The primitive shall contain the SS-LE parameters listed in table 4. Defined group TETRA identity element is a repeatable parameter that shall define one group identity, a list of 2 to 15 group identities or a range of group identities. There shall be at least one defined group identity in a DEFINE primitive. It is required that result for definition apply for all group identities given as defined group identity. If the result for definition parameter would be different, FE3 shall deliver separate DEFINE indication primitives to application. Table 4: DEFINE indication contents Parameter
C/O/M Remark Defined group identity M Repeatable Result of definition
M
4.3.7 INTERROGATE request INTERROGATE request primitive may be offered from application to FE3 over TNSS-SAP. The primitive shall contain the SS-LE parameters listed in table 5. Interrogated group identity element is a repeatable parameter that shall define one group identity, a list of 2 to 14 group identities or a range of group identities. There shall be at least one interrogated group identity in an INTERROGATE primitive. SNA, if used, shall refer to the SNA defined for the sending authorized user. Table 5: INTERROGATE request contents
Parameter
C/O/M Remark Interrogated group identity M Repeatable 4.3.8 INTERROGATE indication
INTERROGATE indication primitive may be offered from FE3 to application over TNSS-SAP. The primitive shall contain the SS-LE parameters listed in table 6. Interrogated group TETRA identity element is a repeatable parameter that shall define one group number, a list of 2 to 14 group identities or a range of group identities. There shall be at least one interrogated group identity in an INTERROGATE primitive.
The interrogation result and any following parameters in the primitive apply for all group numbers given as interrogated group identity. If the parameters would be different, FE3 shall deliver separate INTERROGATE indication primitives to application. Table 6: INTERROGATE indication contents Parameter
C/O/M Remark Interrogated group identity M Repeatable Result of interrogation M See note 1 LE type C See note 2 LE used over ISI C See note 2 Basic service type C See note 2 Repetition rate C See note 2 NOTE 1: If the interrogation request failed, the reason is specified here. NOTE 2: These parameters are present only when the interrogation is accepted.
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 13 4.3.9 PAGING LE indication If the FE1 supports SS-LE paging function the PAGING LE indication primitive shall be offered from FE1 to application over TNSS-SAP with the corresponding basic call primitive TNCC-SETUP indication. The primitive shall contain the SS-LE parameters listed in table 7. The PAGING LE indication implies, that application shall send a PAGING LE response, if the subscriber wishes to join in the call. Table 7: PAGING LE indication contents Parameter
C/O/M Remark LE type
M LE Paging
4.3.10 PAGING LE response The PAGING LE response primitive may be offered from application to FE1 over TNSS-SAP with the corresponding basic call primitive TNCC-SETUP response. The application shall send the primitive only if the subscriber wishes to join the call. The primitive shall contain no SS-LE parameters. Application should discard any other PAGING LE indications to the same call while it is making the response to the received PAGING LE indication or while it is waiting for a BROADCAST LE or ACKNOWLEDGE LE indication after sending the LE PAGING response. If the FE1 receives a BROADCAST LE indication after sending a PAGING LE response to the same call, it may try to cancel the sending of the PAGING LE response and shall deliver the BROADCAST indication to the application. The application shall not send any response to ACKNOWLEDGE LE indications, when it has sent an LE PAGING LE response to the same call. 4.4 Parameter descriptions
Address extension = - Mobile Network Identity comprising Mobile Country Code (MCC) and Mobile Network Code (MNC).
- See ETS 300 392-1 [3], clause 7.
Basic service type = - multipoint circuit mode speech call; or - multipoint circuit mode data call.
Defined group identity =
- Short Number Address (SNA); - Short Subscriber Identity (SSI); or - Short Subscriber Identity (SSI) + Address extension i.e. full GTSI. - See ETS 300 392-1 [3], clause 7. NOTE: The SwMI may not support Short Number Address (SNA) nor mixing of Short Number Address (SNA) and Short Subscriber Identity (SSI) with or without Address extension.
Interrogated group identity, as defined group identity.
LE definition - remove late entry definition; or - LE definition. SIST EN 300 392-12-14 V1.1.1:2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 14
LE type = - broadcast LE; - acknowledge LE; or - paging LE.
LE used over ISI = - applied over ISI; or - not applied over ISI.
Repetition rate = - any rate; - low; - normal; or - high.
Result of definition = - rejected for unknown reason; - accepted; - user not authorized; - unknown TETRA identity; - parameters not valid; - insufficient information; or - SS-LE not supported for the basic service.
Result of interrogation = - rejected for unknown reason; - accepted; - user not authorized; - unknown TETRA identity; - SS-LE not supported for the basic service; - parameters not valid; or - insufficient information.
Short Number Address (SNA), see ETS 300 392-12-7 [5]. SIST EN 300 392-12-14 V1.1.1:2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 15 5 Signalling protocol for the support of SS-LE 5.1 General Clauses 5.2 to 5.6 define the SS-LE layer 3 protocol for the SS-LE services specified in clause 4. The SS-LE protocol comprises of sub-protocols defined for SS and call control (CC) within CMCE. These SS-LE sub-protocols complement the call control protocol defined in EN 300 392-2 [6], clause 14. The present document is only normative for the protocol architecture and user application SAPs within the MS, but gives an informative description of the protocol and the SAPs within the SwMI. NOTE: The internal communication between processes within CMCE is outside the scope of the present document and will only be mentioned as informative statements. 5.2 SS-LE operational requirements 5.2.1 Served user MS/LS The served user MS/LS shall comply with the requirements in clause 14 of EN 300 392-2 [6] which apply to the tele- and bearer services which it supports and which are invoked as group calls. If the served user MS/LS supports SS-LE services it shall comply with the requirements in clause 7.2.2 of EN 300 392-9 [4].
5.2.2 Served user SwMI That SwMI shall support as served user SwMI the served user MS/LS complying with the requirements for group calls set in clause 14 of EN 300 392-2 [6].
If the call is over the ISI, the served user SwMI shall comply with the corresponding ISI requirements for group calls, set in ETS 300 392-3-3 [7] and general ISI requirements set in EN 300 392-3-1 [8]. 5.2.3 Group controlling SwMI Group controlling SwMI shall support as served user SwMI the served user MS/LS complying with the requirements for group calls set in clause 14 of EN 300 392-2 [6]. If the call is over the ISI, the group controlling SwMI shall comply with the corresponding ISI requirements for group calls, set in ETS 300 392-3-3 [7], general ISI requirements set in EN 300 392-3-1 [8] and the requirements for call independent signalling set in EN 300 392-9 [4]. 5.2.4 Served user home SwMI No additional requirements are set to the served user home SwMI on the basic call point of view. 5.2.5 Authorized user MS/LS The authorized user MS/LS shall comply with the requirements for call independent signalling set in EN 300 392-9 [4]. 5.2.6 Authorized user SwMI The authorized user SwMI shall comply general ISI requirements set in EN 300 392-3-1 [8] and to the requirements for call independent signalling set in EN 300 392-9 [4]. SIST EN 300 392-12-14 V1.1.1:2003
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 16 5.2.7 Calling user MS/LS The calling user (user A) MS/LS shall comply with the requirements in clause 14 of EN 300 392-2 [6] which apply to the tele- and bearer services which it supports and which are invoked as group calls. 5.3 SS-LE Coding requirements
5.3.1 SS-LE PDUs 5.3.1.1 General on SS_LE PDUs • SS-LE operation related SS-LE PDUs shall be conveyed inside the basic call PDUs except unless otherwise defined in the SS-LE PDU descriptions. The SS-LE specific definition and interrogation SS-LE PDUs shall be conveyed in a U/D-FACILITY PDU over the air interface (see EN 300 392-2 [6], clause 14.7) and in the ISI-FACILITY PDU over the ISI interface. The present document is normative for the protocol architecture and user application SAPs within the MS. The element coding used in the PDUs is in accordance with the general rules specified in annex E of EN 300 392-2 [6]. The information contained in the following argument PDU definition tables correspond to the following key:
Length: length of the sub-argument in bits; Type: element type (1, 2 or 3) described in EN 300 392-2 [6], annex E; C/O/M: conditional/optional/mandatory; Remark: comment. 5.3.1.2 DEFINE PDU DEFINE PDU shall be offered from FE3 to FE2. The PDU shall be addressed to FE2 even if FE3 is in a visited SwMI. If the acknowledgements are different for different "defined group identities" FE2 shall send separate DEFINE ACK PDUs to FE3 for each result. DEFINE PDU shall contain the SS-LE information elements described in table 8. Table 8: DEFINE PDU contents
Element
Length Type C/O/M Remark SS-type 6 1 M Refer to EN 300 392-9 [4], clause 8.1 SS-LE PDU type 5 1 M
Range type for defined groups 4 1 M See note 1 Defined group address type 2 1 M Repeatable Defined group SNA 8 1 C See note 2 Defined group SSI 24 1 C See note 2 Defined group extension 24 1 C See note 2 LE definition 1 1 M See note 3 LE used over ISI
1 1 C See notes 3 and 4 Call behaviour 2 1 C See notes 3 and 4 Basic service type 2 1 C See notes 3 and 4 Repetition rate 2 1 C See notes 3 and 4 NOTE 1: At least one defined group shall be given. NOTE 2: Shall be conditional on the value of defined group address type information element value:
0 defined group SNA;
1 defined group SSI;
2 defined group SSI + defined group extension;
3 reserved. NOTE 3: These information elements shall be applicable to the all group numbers in this PDU. NOTE 4: These information elements shall be present only when the LE definition information element has value "LE definition".
ETSI ETSI EN 300 392-12-14 V1.1.1 (2002-07) 17 5.3.1.3 DEFINE ACK PDU DEFINE ACK PDU shall be offered from FE2 to FE3. The PDU shall be passed via FE2 in visited SwMI if FE3 is in TETRA visited SwMI. DEFINE ACK PDU shall contain the SS-LE information described in table 9. Table 9: DEFINE ACK PDU contents Element
Length Type C/O/M Remark SS-type 6 1 M Refer to EN 300 392-9 [4], clause 8.1 SS PDU type 4 1 M
Range type for defined groups 4 1 M See note 1 Defined group type identifier 2 1 M Repeatable Defined group SNA 8 1 C See note 2 Defined group SSI 24 1 C See note 2 Defined group extension 24 1 C See note 2 Result for definition
3 1 M
NOTE 1: At least one defined group shall be given. NOTE 2: Shall be conditional on the value of group address type information element value:
0 defined group SNA;
1 defined group SSI;
2 defined group SSI + defined group extension;
3 reserved.
5.3.1.4 INFORM1 PDU The INFORM1 PDU shall be offered from FE2 to FE1. INFORM1 PDU is a conceptual presentation of broadcast LE information without a specific supplementary service PDU. The LE type information shall be transported in the notification information element of the corresponding D-SETUP PDU. The INFORM1 PDU shall set the notification information element value into "LE broadcast" using information element coding as defined in EN 300 392-9 [4], clause 7.2.2. 5.3.1.5 INFORM2 PDU INFORM2 PDU shall be offered from FE2 to FE1. INFORM2 PDU is a conceptual presentation of acknowledge LE information without a specific supplementary service PDU. The LE type information shall be transported in the notification information element of the corresponding D-SETUP PDU. The INFORM2
...
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Prizemni snopovni radio (TETRA) - Govor in podatki (V+D) - 12. del: Dopolnilne storitve stopnje 3 - 12.-14. del: Poznejši vstop (LE)Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 12: Supplementary services stage 3; Sub-part 14: Late Entry (LE)33.070.10Prizemni snopovni radio (TETRA)Terrestrial Trunked Radio (TETRA)ICS:Ta slovenski standard je istoveten z:EN 300 392-12-14 Version 1.1.13SIST E76 300 392-12-14en01-PDM3SIST E76 300 392-12-14SLOVENSKI
STANDARD
DRAFTEUROPEANprETS 300 392-12-14TELECOMMUNICATIONSeptember 1996STANDARDSource: ETSI TC-RESReference: DE/RES-06001-12-14ICS:33.060, 33.060.50Key words:TETRA, V+D, SS, LERadio Equipment and Systems (RES);Trans-European Trunked Radio (TETRA);Voice plus Data (V+D);Part 12: Supplementary Services (SS) Stage 3;Part 12-14: Late Entry (LE)ETSIEuropean Telecommunications Standards InstituteETSI SecretariatPostal address: F-06921 Sophia Antipolis CEDEX - FRANCEOffice address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCEX.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.frTel.: +33 92 94 42 00 - Fax: +33 93 65 47 16Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and theforegoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1996. All rights reserved.SIST EN 300 392-12-14 V1.1.1:2003
Page 2Draft prETS 300 392-12-14: September 1996Whilst 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"ETSI Editing and Committee Support Dept." at the address shown on the title page.SIST EN 300 392-12-14 V1.1.1:2003
Page 3Draft prETS 300 392-12-14: September 1996ContentsForeword.71Scope.92Normative references.93Definitions and abbreviations.93.1Definitions.93.2Abbreviations.104Supplementary Service Late Entry (SS-LE) Stage 3 specification.104.1Functional model.104.1.1Functional model description.104.2SS-LE Service Description.114.2.1Mapping of FEs to Circuit Mode Control Entities (CMCE) sub-entities.114.3Protocol structure and protocol stack.125SS-LE service description.125.1General.125.1.1SS-LE services offered over the TNSS-SAP.135.1.1.1SS-LE primitives.135.1.1.2DEFINE request.135.1.1.3DEFINE-ACK confirm.145.1.1.4INFORM1 indication.155.1.1.5INFORM2 indication.155.1.1.6INFORM2-ACK confirm.155.1.1.7INFORM3 indication.165.1.1.8INFORM3-ACK response.165.1.1.9INTERROGATE request.175.1.1.10INTERROGATE-ACK confirm.175.1.2Parameter description.185.1.3Mapping of SS-LE primitives to TNSS primitives.205.2SS-LE protocol states.205.2.1Protocol states of FE1.205.2.1.1State IDLE.205.2.2Protocol states of FE2.205.2.2.1State IDLE.205.2.2.2State SS-LE ACTIVE.215.2.3Protocol states of FE3 (authorized user).215.2.3.1State IDLE.215.2.4Protocol states of FE4.215.2.4.1State IDLE.215.2.4.2State SS-LE ACTIVE.215.3Procedures.225.3.1Procedures for FE1.225.3.1.1Verification in FE1.225.3.2Procedures for FE2.225.3.2.1Verification in FE2 (for definition).225.3.2.2Verification in FE2 (for interrogation).225.3.2.3Save to database in FE2.235.3.2.4Record ack in FE2.235.3.3Procedures for FE3.235.3.3.1Verification in FE3.235.3.4Procedures for FE4.235.3.4.1Routeing address in FE4.235.4Protocol timers.245.4.1Protocol timers for FE2 and FE4.24SIST EN 300 392-12-14 V1.1.1:2003
Page 4Draft prETS 300 392-12-14: September 19965.4.1.1Protocol timer T1.245.5PDU Descriptions.245.5.1DEFINE request.245.5.2DEFINE-ACK.255.5.3INFORM1.255.5.4INFORM2.265.5.5INFORM2-ACK.265.5.6INFORM3.275.5.7INFORM3-ACK.275.5.8INFORM4.285.5.9INTERROGATE.285.5.10INTERROGATE-ACK.295.5.11Element coding.295.5.11.1Action type.295.5.11.2Basic service type.305.5.11.3Called party GTSI.305.5.11.4Defined party extension.305.5.11.5Defined party SNA.305.5.11.6Defined party SSI.315.5.12Defined party type identifier.315.5.12.1Defined subscriber type.315.5.12.2Interrogated party extension.325.5.12.3Interrogated party SNA.325.5.12.4Interrogated party SSI.325.5.13Interrogated party type identifier.325.5.13.1Interrogated subscriber type.325.5.13.2LE type for acknowledgement response.325.5.13.3LE type for acknowledgement response.335.5.13.4LE type for definition.335.5.13.5LE type for interrogation.335.5.13.6Notification indicator.335.5.13.7Repetition rate.345.5.13.8Result for definition.345.5.13.9Result for interrogation.346SS-LE FE behaviour.346.1Behaviour of FE1.356.1.1Service interaction for FE1 (SS entity in user B).356.1.1.1Process description of FE1 (SS entity in user B).366.1.1.2Service interaction for FE2 (SS entity in SwMI insystem 1).366.1.1.3Process description of FE2 (SS entity in SwMI).376.1.1.4Service interaction for FE3 (SS entity in authorized user).396.1.1.5Process description of FE3 (SS entity in authorized user).406.1.1.6Service interaction for FE4 (SS entity in SwMI insystem 2).416.1.1.7Process description of FE4 (SS entity in SwMI insystem 2).426.2Inter-working considerations.43Annex A (informative):Reception of SS-LE broadcast indications in MS/LS in layer 3.44Annex B (informative):Reception of SS-LE acknowledgement indications in MS /LS in layer 3.45Annex C (informative):Reception of SS-LE paging indications in MS/LS in layer 3.47Annex D (informative):Examples of SS-FACILITY elements.49D.1Example of DEFINE SS-FACILITY element contents.49D.2Examples of DEFINE-ACK SS-FACILITY element contents.49D.3Example of INTERROGATE-ACK SS-FACILITY element contents.50SIST EN 300 392-12-14 V1.1.1:2003
Page 5Draft prETS 300 392-12-14: September 1996History.51SIST EN 300 392-12-14 V1.1.1:2003
Page 6Draft prETS 300 392-12-14: September 1996Blank pageSIST EN 300 392-12-14 V1.1.1:2003
Page 7Draft prETS 300 392-12-14: September 1996ForewordThis draft European Telecommunication Standard (ETS) has been produced by the Radio Equipment andSystems (RES) Technical Committee of the European Telecommunications Standards Institute (ETSI),and is now submitted for the Public Enquiry phase of the ETSI standards approval procedure.This ETS is a multi-part standard as follows:Part 1:"General network design".Part 2:"Air Interface (AI)".Part 3:"Inter-working", (DE/RES-06001-3).Part 4:"Gateways", (DE/RES-06001-4).Part 5:"Terminal equipment interface", (DE/RES-06001-5).Part 6:"Line connected stations", (DE/RES-06001-6).Part 7:"Security".Part 8:"Management services", (DE/RES-06001-8).Part 9:"Performance objectives", (DE/RES-06001-9).Part 10:"Supplementary Services (SS) Stage 1".Part 11:"Supplementary Services (SS) Stage 2".Part 12:"Supplementary Services (SS) Stage 3".Part 13:"SDL Model of the Air Interface".Part 14:"PICS Proforma", (DE/RES-06001-14).Part 15:"Inter-working - Extended Operations", (DE/RES-06001-15).Proposed transposition datesDate of latest announcement of this ETS (doa):3 months after ETSI publicationDate of latest publication of new National Standardor endorsement of this ETS (dop/e):6 months after doaDate of withdrawal of any conflicting National Standard (dow):6 months after doaSIST EN 300 392-12-14 V1.1.1:2003
Page 8Draft prETS 300 392-12-14: September 1996Blank pageSIST EN 300 392-12-14 V1.1.1:2003
Page 9Draft prETS 300 392-12-14: September 19961ScopeThis European Telecommunication Standard (ETS) defines the stage 3 specifications of theSupplementary Service Late Entry (SS-LE) for the Trans-European Trunked Radio (TETRA).SS-LE allows radio users to be informed of and, if they are concerned, to join an already existingpoint-to-multipoint speech call.Man-Machine Interface (MMI) and charging principles are outside the scope of this ETS.Supplementary Service stage 3 specification is preceded by the stage 1 and the stage 2 specifications ofthe service. Stage 1 describes the functional capabilities from the user's point of view. Stage 2 defines thefunctional behaviour in terms of functional entities and information flows. Stage 3 gives a precisedescription of the Supplementary Service from the implementational point of view. It defines the protocolsfor the service and the encoding rules for the information flows. It defines the processes for the functionalentities and their behaviour. The described protocols and behaviour apply for the Switching andManagement Infrastructure (SwMI), for the Mobile Station (MS) and for the Line Station (LS) and can beapplied over the Inter System Interface (ISI) between TETRA systems.2Normative referencesThis ETS incorporates, by dated or undated reference, provisions from other publications. Thesenormative references are cited at the appropriate places in the text and the publications are listedhereafter. For dated references, subsequent amendments to, or revisions of, any of these publicationsapply to this European Telecommunications Standard only when incorporated in it by amendment orrevision. For undated references the latest edition of the publication referred to applies.[1]CCITT Recommendation I.130 (1988): "Method for the characterization oftelecommunication services supported by an ISSN and network capabilities ofan ISDN".[2]ETS 300 392-2: "Radio Equipment and Systems (RES), Trans-EuropeanTrunked Radio (TETRA), Voice plus Data (V+D), Part 2: Air Interface (AI)".[3]ITU-T Recommendation Z.100 (1993): "Specification and Description Language(SDL)".3Definitions and abbreviations3.1DefinitionsFor the purposes of this ETS, the following definitions apply:authorized user: An identified user who is able to define and interrogate the SS-LE parameters. Thedefinition procedure and principles for authorized user are outside the scope of SS-LE.forced LE: The user should join the ongoing multipoint call as soon as he receives a late entry indication.If the user is already engaged in another communication, the user has to join the highest priority call.LE acknowledgement: Indication sent in LE messages by a SwMI to inform a member who would like tojoin the call that he has to inform the SwMI of his entering the call.LE broadcast: Indication sent by a SwMI to inform members of a multipoint call which are currently notalready involved in this call that they can join directly an existing communication (a channel is alreadyallocated in this cell).LE paging: Indication sent by a SwMI to inform members of a multipoint call which are currently notalready involved in this call that they need to ask for a communication channel for that call if they wish toparticipate the call (a channel is not yet allocated in this cell).SIST EN 300 392-12-14 V1.1.1:2003
Page 10Draft prETS 300 392-12-14: September 1996system 1: A TETRA system in which SS-LE can be defined and invoked. System 1 is the TETRAsystem which has same Mobile Network Identity (MNI) as the TETRA group identity to which SS-LE isdefined.system 2: A TETRA system to which SS-LE can be extended and invoked. System 2 is aTETRA system which has a different MNI as the TETRA group identity to which SS-LE is defined.user A: Calling party in a call.user B: In a group call a party that receives the SS-LE indications about an ongoing call.3.2AbbreviationsFor the purposes of this ETS, the following abbreviations apply:CCCall ControlCCACall Control (functional entity Agent)FEFunctional EntityGTSIGroup TETRA Subscriber IdentityISIInter-System InterfaceITSIIndividual TETRA Subscriber IdentityLELate EntryLSLine StationMSMobile StationSSSupplementary ServiceNOTE:The abbreviation SS is only used when referring to a specific supplementary service.SwMISwitching and Management Infrastructure4Supplementary Service Late Entry (SS-LE) Stage 3 specification4.1Functional model4.1.1Functional model descriptionThe functional model shall comprise the following Functional Entities (FEs):-FE1user B functional entity;-FE2SS-LE functional entity;-FE3authorized user's functional entity.NOTE:A member of a group is authorized to interrogate the SS-LE for the group. For suchinterrogation, the INTERROGATE/INTERROGATE-ACK information flow is applicableand is used in the MS/LS as defined for FE3.-FE4SS-LE functional entity in visited system;-FE5user A's (Calling party's) functional entity;-CCCall Control;-CCACall Control Agent.The following relationships shall exist between these FEs:-rabetween FE1 and FE2;-rbbetween FE2s' in different systems;-rcbetween FE2 and FE3;-rdbetween FE2 and FE5;-rebetween FE1 and FE4;-rfbetween FE3 and FE4.SIST EN 300 392-12-14 V1.1.1:2003
Page 11Draft prETS 300 392-12-14: September 1996Figure 1 shows these FEs and relationships for the operational part and figure 2 for the management part.SYSTEM 1SYSTEM 2rarbreFE1FE2 FE4FE1user BSS-LE FESS-LE FEuser B
Figure 1: Functional model for the operational part of SS-LESYSTEM 1SYSTEM 2rcrbrfFE3FE2 FE4FE3authorised SS-LE FE SS-LE FEauthorized user user
Figure 2: Functional model for the management part of SS-LErarbreFE1FE2FE4FE1CCACCCCCCAuser BSS-LE FESS-LE FEuser B
Figure 3: The relationships with a basic service.4.2SS-LE Service Description4.2.1Mapping of FEs to Circuit Mode Control Entities (CMCE) sub-entitiesFunctional Entities (FEs, CCs and CCAs) correspond to sub-entities in CMCE described inETS 300 392-2 [2] according to the following rules:-FE1:supplementary service sub-entity in CMCE in user B's MS/LS;-FE2:supplementary service sub-entity in CMCE in SwMI in system 1;-FE3:supplementary service sub-entity in CMCE in authorized user's MS/LS;-FE4:supplementary service sub-entity in CMCE in SwMI in system 2;-FE5:supplementary service sub-entity in CMCE in user A's MS/LS;-CC:CC sub-entity in CMCE in SwMI;-CCA:CC sub-entity in CMCE in MS/LS.SIST EN 300 392-12-14 V1.1.1:2003
Page 12Draft prETS 300 392-12-14: September 19964.3Protocol structure and protocol stackFigure 4 shows the general position of the layer 3 supplementary services sub-entity within the CMCE andthe TNSS-SAP in both the MS/LS and in the SwMI protocol stack. The SS-LE specific definition, operationand interrogation information elements shall be conveyed in a SS FACILITY element within theSS sub-entity. The FACILITY element is then conveyed in a suitable CMCE PDU (see ETS 300 392-2 [2],subclause 14.7) between the MS/LS and the SwMI or over the ISI. This ETS is only normative for theprotocol architecture and user application SAPs within the mobile station/Line station but gives aninformative description of the protocol and the SAPs within the SwMI.FACILITY elementtransportMLECMCE_SwMICMCE_MS(LS)LCMC-SAPLCMC-SAPTNSS-SAPTNSDS-SAPTNCC-SAPUser applicationsCMCE-MSCircuit Mode Control Entity, Mobile StationCMCE-SwMICircuit Mode Control Entity, SwMI StationLCMC-SAPMobile Link Entity - Circuit Mode Control Service Access PointMLEMobile Link EntityTNCC-SAPTETRA Network - Call Control Service Access PointTNSDS-SAPTETRA Network - Short Data Service Service Access PointTNSS-SAPTETRA Network - Supplementary Service Service Access PointTNSS-SAPMLESS-sub entitySS-sub entityPDU-transportFigure 4: System view5SS-LE service description5.1GeneralClause 5 describes SS-LE specific services offered by the CMCE at the supplementary services SAP(TNSS-SAP) of the TETRA V+D layer 3 service boundary. The specific SS-LE services shall be carried asarguments within the following 3 general generic SS primitives:a)TNSS-SERVICE;b)TNSS-INFO;c)TNSS-ERROR.For a detailed description of the generic SS primitives refer to ETS 300 392-2 [2], subclause 12.3. Theflow of the generic SS primitives shall be as illustrated in figure 5.SIST EN 300 392-12-14 V1.1.1:2003
Page 13Draft prETS 300 392-12-14: September 1996SIGNALTNSS-SAPTNSS-ERROR indication,TNSS-INFO indication,TNSS-INFO confirm,TNSS-SERVICE indication,TNSS-SERVICE confirmTNSS-INFO request,TNSS-INFO response,TNSS-SERVICE request,TNSS-SERVICE responseTNSS-ERROR indication,TNSS-INFO indication,TNSS-INFO confirm,TNSS-SERVICE indication,TNSS-SERVICE confirmTNSS-INFO request,TNSS-INFO response,TNSS-SERVICE request,TNSS-SERVICE responseSS SERVICESwMISS SERVICEMS/LSCMCECMCEFigure 5: General supplementary services provided at the TNSS-SAPThe TNSS-SERVICE shall enable an invoking entity to request, and to be informed about, an operation tobe performed by the performing entity.The TNSS-INFO shall enable an entity to be informed of ongoing transactions.The TNSS-ERROR shall enable a performing entity to return the negative reply of a unsuccessfullyperformed operation to the invoking entity.5.1.1SS-LE services offered over the TNSS-SAP5.1.1.1SS-LE primitivesThe primitives shall as operation argument contain the following SS-LE sub-arguments.-DEFINE request;-DEFINE-ACK confirm;-INFORM1 indication;-INFORM2 indication;-INFORM2-ACK response;-INFORM3 indication;-INFORM3-ACK response;-INFORM4 indication;-INTERROGATE request;-INTERROGATE-ACK confirm.5.1.1.2DEFINE requestDEFINE request primitive shall be offered from application to FE3 over TNSS-SAP. The primitive shallcontain the SS-LE information elements listed in table 1.Defined group number type shall indicate the number of defined group TETRA identity elements, that shallfollow the element. The element shall also indicate whether the following defined group TETRA identityelements shall be interpreted as one group number, a list of 2-10 group numbers or a range of groupnumbers. In case of range first and last element of the range shall be given.SIST EN 300 392-12-14 V1.1.1:2003
Page 14Draft prETS 300 392-12-14: September 1996Defined group TETRA identity element is a repeatable element that shall appear and shall be interpretedas indicated by defined group number type element. There shall be at least one defined group TETRAidentity in a DEFINE primitive. Each defined group TETRA identity element shall comprise of any of thefollowing:-address type identifier and Short Number Address (SNA);-address type identifier and Short Subscriber Identity (SSI);-address type identifier and SSI and address extension.The partial elements of defined group TETRA identity element shall always be in the order given above.Thus, address type shall be the first element which is always followed by any other partial element, exceptaddress extension. Address extension shall always follow SSI, if address extension is used. Omittedaddress extension shall imply that the address extension shall be the address extension of authorizeduser. SNA, if used, shall refer to a SNA defined for authorized user.The SS-LE definition shall be requested to all group numbers given as defined group TETRA identityaccording to the parameters listed after the element defined group TETRA identity.Table 1: DEFINE request contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM:= DEFINEDefined group number typeMDefined group TETRA identityMRepeatable
Address type identifierM
Short Number AddressC
Short Subscriber IdentityC
Address extensionCLE typeOLE used over ISIOnoteBasic service typeORepetition rateONOTE:The element should indicate if SS-LE should or shouldnot be invoked over the Inter-System Interface (ISI)5.1.1.3DEFINE-ACK confirmDEFINE-ACK confirm primitive shall be offered from FE3 to application over TNSS-SAP. The primitiveshall contain the SS-LE information elements listed in table 2.Defined group number type shall indicate the number of defined group TETRA identity elements, that shallfollow the element. The element shall also indicate whether the following defined group TETRA identityelements shall be interpreted as one group number, a list of 2-10 group numbers or a range of groupnumbers. In case of range first and last element of the range shall be given.Defined group TETRA identity element is a repeatable element that shall appear and shall be interpretedas indicated by defined group number type element. There shall be at least one defined group TETRAidentity in a DEFINE primitive. Defined group TETRA identity element shall always have address type asfirst partial element. Address type shall be followed by SNA or SSI. Address extension shall always followSSI, if address extension is used. Omitted address extension shall imply that the address extension shallbe the address extension of authorized user. SNA, if used, shall refer to a SNA defined for authorizeduser.It is required that result for definition apply for all group numbers given as defined group TETRA identity.If the result for definition element would be different, FE3 shall deliver separate DEFINE-ACK primitives toapplication.SIST EN 300 392-12-14 V1.1.1:2003
Page 15Draft prETS 300 392-12-14: September 1996Table 2: DEFINE-ACK confirm contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM: = DEFINEDefined group number typeMDefined group TETRA identityMRepeatable
Address type identifierM
Short Number AddressC
Short Subscriber IdentityC
Address extensionCResult for definitionM5.1.1.4INFORM1 indicationINFORM1 indication primitive shall be offered from FE1 to application over TNSS-SAP. The primitive shallcontain the SS-LE information elements listed in table 3.Table 3: INFORM1 indication contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM:= INFORM1Called group numberMCall identifierMSS-LE IndicationMLE Broadcast5.1.1.5INFORM2 indicationINFORM2 indication primitive shall be offered from FE1 to application over TNSS-SAP. The primitive shallcontain the SS-LE information elements listed in table 4. The SS-LE indication of type LEacknowledgement shall imply, that application shall send INFORM2-ACK, if it participates in the call.Table 4: INFORM2 indication contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM:= INFORM2Called group numberMCall identifierMSS-LE IndicationMLE acknowledgement5.1.1.6INFORM2-ACK confirmINFORM2-ACK confirm primitive shall be offered from application to FE1 over TNSS-SAP. Applicationshall send the primitive only if the subscriber joins the call.Application should discard any other LE acknowledgement requests to the same call item:-while it is making the response to the received LE acknowledgement request; and-after sending the LE acknowledgement response for the same call item.However, if the subscriber receives another LE acknowledgement indication after leaving the call and ifthe user
participates in the group call again, application shall send a new LE acknowledgement response.SIST EN 300 392-12-14 V1.1.1:2003
Page 16Draft prETS 300 392-12-14: September 1996If the subscriber leaves the acknowledged call, e.g. due to another call, the application can send aU-RELEASE information flow to SwMI to indicate that the user leaves the call. Thus, U-RELEASE can besent within a group call to indicate a "negative" acknowledgement in case of LE acknowledgement, whichthe user has acknowledged in that call item. The sending of U-RELEASE should also release the call inthe MS.If LE paging is changed to LE acknowledgement within a call item and if the application has sentLE paging response for that call, the sent LE paging response shall be considered also asLE acknowledgement.In case of LE acknowledgement, the acknowledgement shall be sent in the allocated traffic channel, ifany. If the traffic channel is allocated for the call, the application shall send INFORM2-ACK to FE1 afterthe MS has moved to the traffic channel.The primitive shall contain the SS-LE information elements listed in table 5.Table 5: INFORM2-ACK confirm contentsElementC/O/MRemarkSS typeM:= SS-LELE message typeM:= INFORM2Called group numberMCall identifierMSubscriber numberM5.1.1.7INFORM3 indicationINFORM3 indication primitive shall be offered from FE1 to application over TNSS-SAP. The primitive shallcontain the SS-LE information elements listed in table 6. The SS-LE indication of type LE paging shallimply, that application shall send INFORM3-ACK, if the subscriber wishes to participate in the call.Table 6: INFORM3 indication contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM:= INFORM3Called group numberMCall identifierMSS-LE IndicationMLE paging5.1.1.8INFORM3-ACK responseINFORM3-ACK response primitive shall be offered from application to FE1 over TNSS-SAP. Theapplication shall send the primitive only if the subscriber wishes to join the call. The primitive shall containthe SS-LE information elements listed in table 7.Application should discard any other LE paging requests to the same call item while it is making theresponse to the received LE paging request or while it is waiting for an INFORM1 or INFORM2 informationflow after sending the LE paging response.Table 7: INFORM3-ACK response contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM:= INFORM3Called group numberMCall identifierMSIST EN 300 392-12-14 V1.1.1:2003
Page 17Draft prETS 300 392-12-14: September 19965.1.1.9INTERROGATE requestINTERROGATE request primitive shall be offered from application to FE3 over TNSS-SAP. The primitiveshall contain the SS-LE information elements listed in table 8. The interrogation shall be requested to allgiven group numbers.Interrogated group number type shall indicate the number of interrogated group TETRA identity elements,that shall follow the element. The element shall also indicate whether the following interrogated groupTETRA identity elements shall be interpreted as one group number, a list of 2-10 group numbers or arange of group numbers. In case of range first and last element of the range shall be given.Interrogated group TETRA identity element is a repeatable element that shall appear and shall beinterpreted as indicated by interrogated group number type element. There shall be at least oneinterrogated group TETRA identity in a INTERROGATE primitive. Interrogated group TETRA identityelement shall always have address type as first partial element. Address type shall be followed by SNA orSSI. Address extension shall always follow SSI, if address extension is used. Omitted address extensionshall imply that the address extension shall be the address extension of authorized user. SNA, if used,shall refer to a SNA defined for authorized user.Table 8: INTERROGATE request contentsElementC/O/MRemarkSS typeM:= SS-LELE message typeM:= INTERROGATEInterrogated group number typeMInterrogated group TETRA identityMRepeatable
Address type identifierM
Short Number AddressC
Short Subscriber IdentityC
Address extensionC5.1.1.10INTERROGATE-ACK confirmINTERROGATE-ACK confirm primitive shall be offered from FE3 to application over TNSS-SAP. Theprimitive shall contain the SS-LE information elements listed in table 9.Interrogated group number type shall indicate the number of interrogated group TETRA identity elements,that shall follow the element. The element shall also indicate whether the following interrogated groupTETRA identity elements shall be interpreted as one group number, a list of 2-10 group numbers or arange of group numbers. In case of range first and last element of the range shall be given.Interrogated group TETRA identity element is a repeatable element that shall appear and shall beinterpreted as indicated by interrogated group number type element. There shall be at least oneinterrogated group TETRA identity in a INTERROGATE primitive. Interrogated group TETRA identityelement shall always have address type as first partial element. Address type shall be followed by SNA orSSI. Address extension shall always follow SSI, if address extension is used. Omitted address extensionshall imply that the address extension shall be the address extension of authorized user. SNA, if used,shall refer to a SNA defined for authorized user.It is required that result for interrogation and any following elements in the primitive apply for all groupnumbers given as interrogated group TETRA identity. If the elements would be different, FE3 shall deliverseparate INTERROGATE-ACK primitives to application.SIST EN 300 392-12-14 V1.1.1:2003
Page 18Draft prETS 300 392-12-14: September 1996Table 9: INTERROGATE-ACK confirm contentsElementC/O/MRemarkSS typeM:= SS-LELE message typeM:= INTERROGATEInterrogated group number typeMInterrogated group TETRA identityMRepeatable
Address type identifierM
Short Number AddressC
Short Subscriber IdentityC
Address extensionCResult for interrogationMnote 1LE typeOLE used over ISIOnote 2Basic service typeORepetition rateONOTE 1:If the interrogation request failed, the reason is specified here.NOTE 2:The element should indicate if SS-LE should or should not beinvoked over the ISI.5.1.2Parameter descriptionAddress Extension =Mobile Country Code (MCC) + Mobile Network Code (MNC).See ETS 300 392-1 [4] clause 7.Address type Identifier =0Short Number address (SNA)1Short Subscriber Identity (SSI)2TETRA Subscriber Identity (TSI = SSI + Address Extension)See ETS 300 392-1 [4] clause 7.Call identifier, see ETS 300 392-2 [2], subclause 14.Basic service type =0Multipoint circuit mode speech call1Multipoint circuit mode data callDefined group number type =0subscriber number, 1 subscriber number following of any allowed type1range of numbers, 2 subscriber numbers following of any allowed type2list of subscriber numbers, 2-10 subscriber numbers following of any allowed typeDefined group TETRA identity, shall be any of the following:-Address type identifier + Short Number Address (SNA)-Address type identifier + Short Subscriber Identity (SSI)-Address type identifier + Short Subscriber Identity (SSI) + Address extensionSee ETS 300 392-1 [4] clause 7.Called group number = TETRA subscriber identity (TSI).LE used over ISI =0applied over ISI1not applied over ISISIST EN 300 392-12-14 V1.1.1:2003
Page 19Draft prETS 300 392-12-14: September 1996LE type =0LE paging1No LE pagingInterrogated group number type, as defined group number type.Interrogated group TETRA identity, as defined group TETRA identity.Repetition rate =0any rate1low2normal3highResult for definition =0accepted1rejected for any reason2user not Authorized3unknown TETRA identity4parameters not valid5insufficient information6invalid basic serviceResult for interrogation, as Result for definition.Short Number Address (SNA), see ETS 300 392-1 [4] clause 7.Short Subscriber Identity (SSI), see ETS 300 392-1 [4] clause 7.SS-LE Indication =0LE broadcast1LE acknowledgement2LE pagingSIST EN 300 392-12-14 V1.1.1:2003
Page 20Draft prETS 300 392-12-14: September 19965.1.3Mapping of SS-LE primitives to TNSS primitivesTable 10 shows the mapping of the SS-LE primitives to TNSS primitives.Table 10: Mapping of the SS-LE primitives to TNSS primitivesSS-LE primitiveTNSS-SERVICErequestTNSS-SERVICEconfirmTNSS-SERVICEindicationTNSS-SERVICEresponseTNSS-INFOindicationTNSS-ERRORindicationRemarkDEFINEin FE3----DEFINE-ACK-withsuccessfuldefinitionin FE3--withunsuccessfuldefinition inFE3note 1INFORM1in FE1INFORM2in FE1INFORM2-ACKin FE1note 2INFORM3in FE1INFORM3-ACKin FE1note 2INTERROGATEin FE3/FE1----INTERROGATE-ACK-withsuccessfulinterrogation inFE3/FE1-withunsuccessfulinterrogationin FE3/FE1note 3NOTE 1:For this purpose the definition is considered successful if the value for "Result for definition" is"accepted".NOTE 2:Application shall return the INFORM2-ACK/INFORM3-ACK to FE1 only if the subscriber shalljoin or request to join the ongoing call.NOTE 3:For this purpose the interrogation is considered successful if the value for "Result forinterrogation" is "accepted".5.2SS-LE protocol states5.2.1Protocol states of FE15.2.1.1State IDLEIDLE shall be the normal state of FE1. In this state FE1 shall receive all the SS-LE indications related toan ongoing call. FE1 shall send the SS-LE indications to the application. FE1 shall receive the responsesto LE acknowledgement and to LE paging, in state IDLE, too. FE1 shall send the received responses toFE2.The behaviour of FE1 and application collocated to FE1 is described in:annex A:Reception of SS-LE broadcast indications in MS/LS in Layer 3;annex B:Reception of SS-LE acknowledgement indications in MS/LS in Layer 3;annex C:Reception of SS-LE paging indications in MS/LS in Layer 3.5.2.2Protocol states of FE25.2.2.1State IDLEIDLE should be the normal state of FE2. In this state FE2 should receive the definition and interrogationrequests from FE3. FE2 should verify the received definition or interrogation requests. If FE2 accepts theinterrogation request, FE2 should fetch the interrogated data and sends it to FE3. If FE2 accepts thedefinition requests, FE2 should save the new definition data to the database, start the sending ofSS-LE messages (INFORM1, INFORM2 or INFORM3) if the group call in ongoing and FE2 shouldacknowledge the service request to FE3.SIST EN 300 392-12-14 V1.1.1:2003
Page 21Draft prETS 300 392-12-14: September 1996FE2 should receive call invocation messages in order to invoke the SS-LE, if defined for the call. At thereception of call invocation FE2 should determine the used SS-LE type and invoke the SS-LE if theservice is defined for the group. After that, FE2 should move to the state SS-LE ACTIVE.5.2.2.2State SS-LE ACTIVESS-LE ACTIVE should be the state in which FE2 should start the sending of SS-LE invocations and thesending should be ongoing. In state SS-LE ACTIVE FE2 sends the SS-LE indications:-in case of LE broadcast, FE2 should send INFORM1 information flows;-in case of LE acknowledgement, FE2 should send INFORM2 information flows;-in case of LE paging, FE2 should send INFORM2 information flows.If the SS-LE should be invoked in another TETRA system(s) over ISI, FE2 should send theINFORM4 messages to the TETRA system(s).After sending the SS-LE indications, FE2 should set the timer T1. The timer is set with a valuecorresponding to low, normal or high, as defined for the group.
Each time when the timer T1 expires, FE2should send new SS-LE indications.At the reception of LE acknowledgement or LE paging responses from FE1s, FE2 notifies theseresponses. In the case of LE paging response, FE2 should change the SS-LE type to LE broadcast orLE acknowledgement in that area.At the reception of call release indication, FE2 should stop the service and the sending of allSS-LE indications related to the call.5.2.3Protocol states of FE3 (authorized user)5.2.3.1State IDLEIDLE shall be the normal state of FE3. In this state FE3 shall receive the definition or interrogationrequests from the user. FE3 shall verify the requests and if it accepts them, FE3 shall send them to FE2.In IDLE state FE3 shall also receive the acknowledgements and responses for the definition orinterrogation requests. At the reception of these information flows, FE3 shall send them to the application.5.2.4Protocol states of FE45.2.4.1State IDLEIDLE should be the normal state of FE4. In this state FE4 should receive the information flows fromFE3 or FE1 to be delivered to FE2 in another system. And, FE4 should also receive the information flowsfrom FE2 to be delivered to FE1 or FE3 located in this system.At the reception of SS-LE invocations (INFORM4s) from another system, FE4 should determine theLE type to be applied, send the correct SS-LE invocations and move to SS-LE ACTIVE state.5.2.4.2State SS-LE ACTIVESS-LE ACTIVE should be the state in which FE4 should start the sending of SS-LE invocations and thesending should be ongoing. In state SS-LE ACTIVE FE4 should send the SS-LE indications:-in case of LE broadcast, FE4 should send INFORM1 information flows;-in case of LE acknowledgement, FE4 should send INFORM2 information flows;-in case of LE paging, FE4 should send INFORM2 information flows.After sending the SS-LE indications, FE4 should set the timer T1. The timer should be set with a valuecorresponding to low, normal or high, as defined for the group if defined.
Each time when the timerT1 expires, FE4 should send new SS-LE indications.SIST EN 300 392-12-14 V1.1.1:2003
Page 22Draft prETS 300 392-12-14: September 1996At the reception of LE acknowledgement or LE paging responses from FE1s, FE4 should notify theseresponses. In the case of acknowledged group call, FE4 should send the acknowledgements to system 1.In the case of LE paging response, FE4 should change the SS-LE type to LE broadcast or LEacknowledgement in that area.At the reception of call release indication, FE4 should stop the service and the sending of allSS-LE indications related to the call.5.3Procedures5.3.1Procedures for FE15.3.1.1Verification in FE1At the reception of SS-LE INFORM1, INFORM2 or INFORM3 request, FE1 shall inform application aboutthe received LE indication. In case of LE acknowledgement or LE paging FE1 shall send INFORM2-ACK/INFORM3-ACK to FE2 if the application indicates that the subscriber joins (LE acknowledgement) orwishes to join (LE paging) the ongoing call.5.3.2Procedures for FE25.3.2.1Verification in FE2 (for definition)At the reception of SS-LE DEFINE request, FE2 should verify that the request is authorized and that theparameters are in the correct range. The parameters should correspond to the FACILITY elementdefinitions given in subclause 5.5. After making the checks, FE2 should either continue to carry out therequest, or FE2 should reject it.The SNA should refer to authorized user's SNA definitions, if applied. FE2 should replace the SNA in thedefinition saved to database in SwMI by the complete TETRA subscriber identity, GSSI. If applied indefinition, the SNA should be defined for the authorized user, if not, FE2 should not accept it.If address extension is not applied with SSI, that should imply that the address extension should be theaddress extension of authorized user. FE2 should save the definition to the database in SwMI by using thecomplete TETRA subscriber identity, GSSI.If the definition is requested for a
...
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Prizemni snopovni radio (TETRA) - Govor in podatki (V+D) - 12. del: Dopolnilne storitve stopnje 3 - 12.-14. del: Poznejši vstop (LE)Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 12: Supplementary services stage 3; Sub-part 14: Late Entry (LE)33.070.10Prizemni snopovni radio (TETRA)Terrestrial Trunked Radio (TETRA)ICS:Ta slovenski standard je istoveten z:EN 300 392-12-14 Version 1.1.1SIST E76 300 392-12-14en01-MXOLMSIST E76 300 392-12-14SLOVENSKI
STANDARD
DRAFTEUROPEANprETS 300 392-12-14TELECOMMUNICATIONSeptember 1996STANDARDSource: ETSI TC-RESReference: DE/RES-06001-12-14ICS:33.060, 33.060.50Key words:TETRA, V+D, SS, LERadio Equipment and Systems (RES);Trans-European Trunked Radio (TETRA);Voice plus Data (V+D);Part 12: Supplementary Services (SS) Stage 3;Part 12-14: Late Entry (LE)ETSIEuropean Telecommunications Standards InstituteETSI SecretariatPostal address: F-06921 Sophia Antipolis CEDEX - FRANCEOffice address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCEX.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.frTel.: +33 92 94 42 00 - Fax: +33 93 65 47 16Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and theforegoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1996. All rights reserved.SIST EN 300 392-12-14 V1.1.1:2003
Page 2Draft prETS 300 392-12-14: September 1996Whilst 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"ETSI Editing and Committee Support Dept." at the address shown on the title page.SIST EN 300 392-12-14 V1.1.1:2003
Page 3Draft prETS 300 392-12-14: September 1996ContentsForeword.71Scope.92Normative references.93Definitions and abbreviations.93.1Definitions.93.2Abbreviations.104Supplementary Service Late Entry (SS-LE) Stage 3 specification.104.1Functional model.104.1.1Functional model description.104.2SS-LE Service Description.114.2.1Mapping of FEs to Circuit Mode Control Entities (CMCE) sub-entities.114.3Protocol structure and protocol stack.125SS-LE service description.125.1General.125.1.1SS-LE services offered over the TNSS-SAP.135.1.1.1SS-LE primitives.135.1.1.2DEFINE request.135.1.1.3DEFINE-ACK confirm.145.1.1.4INFORM1 indication.155.1.1.5INFORM2 indication.155.1.1.6INFORM2-ACK confirm.155.1.1.7INFORM3 indication.165.1.1.8INFORM3-ACK response.165.1.1.9INTERROGATE request.175.1.1.10INTERROGATE-ACK confirm.175.1.2Parameter description.185.1.3Mapping of SS-LE primitives to TNSS primitives.205.2SS-LE protocol states.205.2.1Protocol states of FE1.205.2.1.1State IDLE.205.2.2Protocol states of FE2.205.2.2.1State IDLE.205.2.2.2State SS-LE ACTIVE.215.2.3Protocol states of FE3 (authorized user).215.2.3.1State IDLE.215.2.4Protocol states of FE4.215.2.4.1State IDLE.215.2.4.2State SS-LE ACTIVE.215.3Procedures.225.3.1Procedures for FE1.225.3.1.1Verification in FE1.225.3.2Procedures for FE2.225.3.2.1Verification in FE2 (for definition).225.3.2.2Verification in FE2 (for interrogation).225.3.2.3Save to database in FE2.235.3.2.4Record ack in FE2.235.3.3Procedures for FE3.235.3.3.1Verification in FE3.235.3.4Procedures for FE4.235.3.4.1Routeing address in FE4.235.4Protocol timers.245.4.1Protocol timers for FE2 and FE4.24SIST EN 300 392-12-14 V1.1.1:2003
Page 4Draft prETS 300 392-12-14: September 19965.4.1.1Protocol timer T1.245.5PDU Descriptions.245.5.1DEFINE request.245.5.2DEFINE-ACK.255.5.3INFORM1.255.5.4INFORM2.265.5.5INFORM2-ACK.265.5.6INFORM3.275.5.7INFORM3-ACK.275.5.8INFORM4.285.5.9INTERROGATE.285.5.10INTERROGATE-ACK.295.5.11Element coding.295.5.11.1Action type.295.5.11.2Basic service type.305.5.11.3Called party GTSI.305.5.11.4Defined party extension.305.5.11.5Defined party SNA.305.5.11.6Defined party SSI.315.5.12Defined party type identifier.315.5.12.1Defined subscriber type.315.5.12.2Interrogated party extension.325.5.12.3Interrogated party SNA.325.5.12.4Interrogated party SSI.325.5.13Interrogated party type identifier.325.5.13.1Interrogated subscriber type.325.5.13.2LE type for acknowledgement response.325.5.13.3LE type for acknowledgement response.335.5.13.4LE type for definition.335.5.13.5LE type for interrogation.335.5.13.6Notification indicator.335.5.13.7Repetition rate.345.5.13.8Result for definition.345.5.13.9Result for interrogation.346SS-LE FE behaviour.346.1Behaviour of FE1.356.1.1Service interaction for FE1 (SS entity in user B).356.1.1.1Process description of FE1 (SS entity in user B).366.1.1.2Service interaction for FE2 (SS entity in SwMI insystem 1).366.1.1.3Process description of FE2 (SS entity in SwMI).376.1.1.4Service interaction for FE3 (SS entity in authorized user).396.1.1.5Process description of FE3 (SS entity in authorized user).406.1.1.6Service interaction for FE4 (SS entity in SwMI insystem 2).416.1.1.7Process description of FE4 (SS entity in SwMI insystem 2).426.2Inter-working considerations.43Annex A (informative):Reception of SS-LE broadcast indications in MS/LS in layer 3.44Annex B (informative):Reception of SS-LE acknowledgement indications in MS /LS in layer 3.45Annex C (informative):Reception of SS-LE paging indications in MS/LS in layer 3.47Annex D (informative):Examples of SS-FACILITY elements.49D.1Example of DEFINE SS-FACILITY element contents.49D.2Examples of DEFINE-ACK SS-FACILITY element contents.49D.3Example of INTERROGATE-ACK SS-FACILITY element contents.50SIST EN 300 392-12-14 V1.1.1:2003
Page 5Draft prETS 300 392-12-14: September 1996History.51SIST EN 300 392-12-14 V1.1.1:2003
Page 6Draft prETS 300 392-12-14: September 1996Blank pageSIST EN 300 392-12-14 V1.1.1:2003
Page 7Draft prETS 300 392-12-14: September 1996ForewordThis draft European Telecommunication Standard (ETS) has been produced by the Radio Equipment andSystems (RES) Technical Committee of the European Telecommunications Standards Institute (ETSI),and is now submitted for the Public Enquiry phase of the ETSI standards approval procedure.This ETS is a multi-part standard as follows:Part 1:"General network design".Part 2:"Air Interface (AI)".Part 3:"Inter-working", (DE/RES-06001-3).Part 4:"Gateways", (DE/RES-06001-4).Part 5:"Terminal equipment interface", (DE/RES-06001-5).Part 6:"Line connected stations", (DE/RES-06001-6).Part 7:"Security".Part 8:"Management services", (DE/RES-06001-8).Part 9:"Performance objectives", (DE/RES-06001-9).Part 10:"Supplementary Services (SS) Stage 1".Part 11:"Supplementary Services (SS) Stage 2".Part 12:"Supplementary Services (SS) Stage 3".Part 13:"SDL Model of the Air Interface".Part 14:"PICS Proforma", (DE/RES-06001-14).Part 15:"Inter-working - Extended Operations", (DE/RES-06001-15).Proposed transposition datesDate of latest announcement of this ETS (doa):3 months after ETSI publicationDate of latest publication of new National Standardor endorsement of this ETS (dop/e):6 months after doaDate of withdrawal of any conflicting National Standard (dow):6 months after doaSIST EN 300 392-12-14 V1.1.1:2003
Page 8Draft prETS 300 392-12-14: September 1996Blank pageSIST EN 300 392-12-14 V1.1.1:2003
Page 9Draft prETS 300 392-12-14: September 19961ScopeThis European Telecommunication Standard (ETS) defines the stage 3 specifications of theSupplementary Service Late Entry (SS-LE) for the Trans-European Trunked Radio (TETRA).SS-LE allows radio users to be informed of and, if they are concerned, to join an already existingpoint-to-multipoint speech call.Man-Machine Interface (MMI) and charging principles are outside the scope of this ETS.Supplementary Service stage 3 specification is preceded by the stage 1 and the stage 2 specifications ofthe service. Stage 1 describes the functional capabilities from the user's point of view. Stage 2 defines thefunctional behaviour in terms of functional entities and information flows. Stage 3 gives a precisedescription of the Supplementary Service from the implementational point of view. It defines the protocolsfor the service and the encoding rules for the information flows. It defines the processes for the functionalentities and their behaviour. The described protocols and behaviour apply for the Switching andManagement Infrastructure (SwMI), for the Mobile Station (MS) and for the Line Station (LS) and can beapplied over the Inter System Interface (ISI) between TETRA systems.2Normative referencesThis ETS incorporates, by dated or undated reference, provisions from other publications. Thesenormative references are cited at the appropriate places in the text and the publications are listedhereafter. For dated references, subsequent amendments to, or revisions of, any of these publicationsapply to this European Telecommunications Standard only when incorporated in it by amendment orrevision. For undated references the latest edition of the publication referred to applies.[1]CCITT Recommendation I.130 (1988): "Method for the characterization oftelecommunication services supported by an ISSN and network capabilities ofan ISDN".[2]ETS 300 392-2: "Radio Equipment and Systems (RES), Trans-EuropeanTrunked Radio (TETRA), Voice plus Data (V+D), Part 2: Air Interface (AI)".[3]ITU-T Recommendation Z.100 (1993): "Specification and Description Language(SDL)".3Definitions and abbreviations3.1DefinitionsFor the purposes of this ETS, the following definitions apply:authorized user: An identified user who is able to define and interrogate the SS-LE parameters. Thedefinition procedure and principles for authorized user are outside the scope of SS-LE.forced LE: The user should join the ongoing multipoint call as soon as he receives a late entry indication.If the user is already engaged in another communication, the user has to join the highest priority call.LE acknowledgement: Indication sent in LE messages by a SwMI to inform a member who would like tojoin the call that he has to inform the SwMI of his entering the call.LE broadcast: Indication sent by a SwMI to inform members of a multipoint call which are currently notalready involved in this call that they can join directly an existing communication (a channel is alreadyallocated in this cell).LE paging: Indication sent by a SwMI to inform members of a multipoint call which are currently notalready involved in this call that they need to ask for a communication channel for that call if they wish toparticipate the call (a channel is not yet allocated in this cell).SIST EN 300 392-12-14 V1.1.1:2003
Page 10Draft prETS 300 392-12-14: September 1996system 1: A TETRA system in which SS-LE can be defined and invoked. System 1 is the TETRAsystem which has same Mobile Network Identity (MNI) as the TETRA group identity to which SS-LE isdefined.system 2: A TETRA system to which SS-LE can be extended and invoked. System 2 is aTETRA system which has a different MNI as the TETRA group identity to which SS-LE is defined.user A: Calling party in a call.user B: In a group call a party that receives the SS-LE indications about an ongoing call.3.2AbbreviationsFor the purposes of this ETS, the following abbreviations apply:CCCall ControlCCACall Control (functional entity Agent)FEFunctional EntityGTSIGroup TETRA Subscriber IdentityISIInter-System InterfaceITSIIndividual TETRA Subscriber IdentityLELate EntryLSLine StationMSMobile StationSSSupplementary ServiceNOTE:The abbreviation SS is only used when referring to a specific supplementary service.SwMISwitching and Management Infrastructure4Supplementary Service Late Entry (SS-LE) Stage 3 specification4.1Functional model4.1.1Functional model descriptionThe functional model shall comprise the following Functional Entities (FEs):-FE1user B functional entity;-FE2SS-LE functional entity;-FE3authorized user's functional entity.NOTE:A member of a group is authorized to interrogate the SS-LE for the group. For suchinterrogation, the INTERROGATE/INTERROGATE-ACK information flow is applicableand is used in the MS/LS as defined for FE3.-FE4SS-LE functional entity in visited system;-FE5user A's (Calling party's) functional entity;-CCCall Control;-CCACall Control Agent.The following relationships shall exist between these FEs:-rabetween FE1 and FE2;-rbbetween FE2s' in different systems;-rcbetween FE2 and FE3;-rdbetween FE2 and FE5;-rebetween FE1 and FE4;-rfbetween FE3 and FE4.SIST EN 300 392-12-14 V1.1.1:2003
Page 11Draft prETS 300 392-12-14: September 1996Figure 1 shows these FEs and relationships for the operational part and figure 2 for the management part.SYSTEM 1SYSTEM 2rarbreFE1FE2 FE4FE1user BSS-LE FESS-LE FEuser B
Figure 1: Functional model for the operational part of SS-LESYSTEM 1SYSTEM 2rcrbrfFE3FE2 FE4FE3authorised SS-LE FE SS-LE FEauthorized user user
Figure 2: Functional model for the management part of SS-LErarbreFE1FE2FE4FE1CCACCCCCCAuser BSS-LE FESS-LE FEuser B
Figure 3: The relationships with a basic service.4.2SS-LE Service Description4.2.1Mapping of FEs to Circuit Mode Control Entities (CMCE) sub-entitiesFunctional Entities (FEs, CCs and CCAs) correspond to sub-entities in CMCE described inETS 300 392-2 [2] according to the following rules:-FE1:supplementary service sub-entity in CMCE in user B's MS/LS;-FE2:supplementary service sub-entity in CMCE in SwMI in system 1;-FE3:supplementary service sub-entity in CMCE in authorized user's MS/LS;-FE4:supplementary service sub-entity in CMCE in SwMI in system 2;-FE5:supplementary service sub-entity in CMCE in user A's MS/LS;-CC:CC sub-entity in CMCE in SwMI;-CCA:CC sub-entity in CMCE in MS/LS.SIST EN 300 392-12-14 V1.1.1:2003
Page 12Draft prETS 300 392-12-14: September 19964.3Protocol structure and protocol stackFigure 4 shows the general position of the layer 3 supplementary services sub-entity within the CMCE andthe TNSS-SAP in both the MS/LS and in the SwMI protocol stack. The SS-LE specific definition, operationand interrogation information elements shall be conveyed in a SS FACILITY element within theSS sub-entity. The FACILITY element is then conveyed in a suitable CMCE PDU (see ETS 300 392-2 [2],subclause 14.7) between the MS/LS and the SwMI or over the ISI. This ETS is only normative for theprotocol architecture and user application SAPs within the mobile station/Line station but gives aninformative description of the protocol and the SAPs within the SwMI.FACILITY elementtransportMLECMCE_SwMICMCE_MS(LS)LCMC-SAPLCMC-SAPTNSS-SAPTNSDS-SAPTNCC-SAPUser applicationsCMCE-MSCircuit Mode Control Entity, Mobile StationCMCE-SwMICircuit Mode Control Entity, SwMI StationLCMC-SAPMobile Link Entity - Circuit Mode Control Service Access PointMLEMobile Link EntityTNCC-SAPTETRA Network - Call Control Service Access PointTNSDS-SAPTETRA Network - Short Data Service Service Access PointTNSS-SAPTETRA Network - Supplementary Service Service Access PointTNSS-SAPMLESS-sub entitySS-sub entityPDU-transportFigure 4: System view5SS-LE service description5.1GeneralClause 5 describes SS-LE specific services offered by the CMCE at the supplementary services SAP(TNSS-SAP) of the TETRA V+D layer 3 service boundary. The specific SS-LE services shall be carried asarguments within the following 3 general generic SS primitives:a)TNSS-SERVICE;b)TNSS-INFO;c)TNSS-ERROR.For a detailed description of the generic SS primitives refer to ETS 300 392-2 [2], subclause 12.3. Theflow of the generic SS primitives shall be as illustrated in figure 5.SIST EN 300 392-12-14 V1.1.1:2003
Page 13Draft prETS 300 392-12-14: September 1996SIGNALTNSS-SAPTNSS-ERROR indication,TNSS-INFO indication,TNSS-INFO confirm,TNSS-SERVICE indication,TNSS-SERVICE confirmTNSS-INFO request,TNSS-INFO response,TNSS-SERVICE request,TNSS-SERVICE responseTNSS-ERROR indication,TNSS-INFO indication,TNSS-INFO confirm,TNSS-SERVICE indication,TNSS-SERVICE confirmTNSS-INFO request,TNSS-INFO response,TNSS-SERVICE request,TNSS-SERVICE responseSS SERVICESwMISS SERVICEMS/LSCMCECMCEFigure 5: General supplementary services provided at the TNSS-SAPThe TNSS-SERVICE shall enable an invoking entity to request, and to be informed about, an operation tobe performed by the performing entity.The TNSS-INFO shall enable an entity to be informed of ongoing transactions.The TNSS-ERROR shall enable a performing entity to return the negative reply of a unsuccessfullyperformed operation to the invoking entity.5.1.1SS-LE services offered over the TNSS-SAP5.1.1.1SS-LE primitivesThe primitives shall as operation argument contain the following SS-LE sub-arguments.-DEFINE request;-DEFINE-ACK confirm;-INFORM1 indication;-INFORM2 indication;-INFORM2-ACK response;-INFORM3 indication;-INFORM3-ACK response;-INFORM4 indication;-INTERROGATE request;-INTERROGATE-ACK confirm.5.1.1.2DEFINE requestDEFINE request primitive shall be offered from application to FE3 over TNSS-SAP. The primitive shallcontain the SS-LE information elements listed in table 1.Defined group number type shall indicate the number of defined group TETRA identity elements, that shallfollow the element. The element shall also indicate whether the following defined group TETRA identityelements shall be interpreted as one group number, a list of 2-10 group numbers or a range of groupnumbers. In case of range first and last element of the range shall be given.SIST EN 300 392-12-14 V1.1.1:2003
Page 14Draft prETS 300 392-12-14: September 1996Defined group TETRA identity element is a repeatable element that shall appear and shall be interpretedas indicated by defined group number type element. There shall be at least one defined group TETRAidentity in a DEFINE primitive. Each defined group TETRA identity element shall comprise of any of thefollowing:-address type identifier and Short Number Address (SNA);-address type identifier and Short Subscriber Identity (SSI);-address type identifier and SSI and address extension.The partial elements of defined group TETRA identity element shall always be in the order given above.Thus, address type shall be the first element which is always followed by any other partial element, exceptaddress extension. Address extension shall always follow SSI, if address extension is used. Omittedaddress extension shall imply that the address extension shall be the address extension of authorizeduser. SNA, if used, shall refer to a SNA defined for authorized user.The SS-LE definition shall be requested to all group numbers given as defined group TETRA identityaccording to the parameters listed after the element defined group TETRA identity.Table 1: DEFINE request contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM:= DEFINEDefined group number typeMDefined group TETRA identityMRepeatable
Address type identifierM
Short Number AddressC
Short Subscriber IdentityC
Address extensionCLE typeOLE used over ISIOnoteBasic service typeORepetition rateONOTE:The element should indicate if SS-LE should or shouldnot be invoked over the Inter-System Interface (ISI)5.1.1.3DEFINE-ACK confirmDEFINE-ACK confirm primitive shall be offered from FE3 to application over TNSS-SAP. The primitiveshall contain the SS-LE information elements listed in table 2.Defined group number type shall indicate the number of defined group TETRA identity elements, that shallfollow the element. The element shall also indicate whether the following defined group TETRA identityelements shall be interpreted as one group number, a list of 2-10 group numbers or a range of groupnumbers. In case of range first and last element of the range shall be given.Defined group TETRA identity element is a repeatable element that shall appear and shall be interpretedas indicated by defined group number type element. There shall be at least one defined group TETRAidentity in a DEFINE primitive. Defined group TETRA identity element shall always have address type asfirst partial element. Address type shall be followed by SNA or SSI. Address extension shall always followSSI, if address extension is used. Omitted address extension shall imply that the address extension shallbe the address extension of authorized user. SNA, if used, shall refer to a SNA defined for authorizeduser.It is required that result for definition apply for all group numbers given as defined group TETRA identity.If the result for definition element would be different, FE3 shall deliver separate DEFINE-ACK primitives toapplication.SIST EN 300 392-12-14 V1.1.1:2003
Page 15Draft prETS 300 392-12-14: September 1996Table 2: DEFINE-ACK confirm contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM: = DEFINEDefined group number typeMDefined group TETRA identityMRepeatable
Address type identifierM
Short Number AddressC
Short Subscriber IdentityC
Address extensionCResult for definitionM5.1.1.4INFORM1 indicationINFORM1 indication primitive shall be offered from FE1 to application over TNSS-SAP. The primitive shallcontain the SS-LE information elements listed in table 3.Table 3: INFORM1 indication contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM:= INFORM1Called group numberMCall identifierMSS-LE IndicationMLE Broadcast5.1.1.5INFORM2 indicationINFORM2 indication primitive shall be offered from FE1 to application over TNSS-SAP. The primitive shallcontain the SS-LE information elements listed in table 4. The SS-LE indication of type LEacknowledgement shall imply, that application shall send INFORM2-ACK, if it participates in the call.Table 4: INFORM2 indication contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM:= INFORM2Called group numberMCall identifierMSS-LE IndicationMLE acknowledgement5.1.1.6INFORM2-ACK confirmINFORM2-ACK confirm primitive shall be offered from application to FE1 over TNSS-SAP. Applicationshall send the primitive only if the subscriber joins the call.Application should discard any other LE acknowledgement requests to the same call item:-while it is making the response to the received LE acknowledgement request; and-after sending the LE acknowledgement response for the same call item.However, if the subscriber receives another LE acknowledgement indication after leaving the call and ifthe user
participates in the group call again, application shall send a new LE acknowledgement response.SIST EN 300 392-12-14 V1.1.1:2003
Page 16Draft prETS 300 392-12-14: September 1996If the subscriber leaves the acknowledged call, e.g. due to another call, the application can send aU-RELEASE information flow to SwMI to indicate that the user leaves the call. Thus, U-RELEASE can besent within a group call to indicate a "negative" acknowledgement in case of LE acknowledgement, whichthe user has acknowledged in that call item. The sending of U-RELEASE should also release the call inthe MS.If LE paging is changed to LE acknowledgement within a call item and if the application has sentLE paging response for that call, the sent LE paging response shall be considered also asLE acknowledgement.In case of LE acknowledgement, the acknowledgement shall be sent in the allocated traffic channel, ifany. If the traffic channel is allocated for the call, the application shall send INFORM2-ACK to FE1 afterthe MS has moved to the traffic channel.The primitive shall contain the SS-LE information elements listed in table 5.Table 5: INFORM2-ACK confirm contentsElementC/O/MRemarkSS typeM:= SS-LELE message typeM:= INFORM2Called group numberMCall identifierMSubscriber numberM5.1.1.7INFORM3 indicationINFORM3 indication primitive shall be offered from FE1 to application over TNSS-SAP. The primitive shallcontain the SS-LE information elements listed in table 6. The SS-LE indication of type LE paging shallimply, that application shall send INFORM3-ACK, if the subscriber wishes to participate in the call.Table 6: INFORM3 indication contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM:= INFORM3Called group numberMCall identifierMSS-LE IndicationMLE paging5.1.1.8INFORM3-ACK responseINFORM3-ACK response primitive shall be offered from application to FE1 over TNSS-SAP. Theapplication shall send the primitive only if the subscriber wishes to join the call. The primitive shall containthe SS-LE information elements listed in table 7.Application should discard any other LE paging requests to the same call item while it is making theresponse to the received LE paging request or while it is waiting for an INFORM1 or INFORM2 informationflow after sending the LE paging response.Table 7: INFORM3-ACK response contentsElementC/O/MRemarkSS typeM:= SS-LELE Message typeM:= INFORM3Called group numberMCall identifierMSIST EN 300 392-12-14 V1.1.1:2003
Page 17Draft prETS 300 392-12-14: September 19965.1.1.9INTERROGATE requestINTERROGATE request primitive shall be offered from application to FE3 over TNSS-SAP. The primitiveshall contain the SS-LE information elements listed in table 8. The interrogation shall be requested to allgiven group numbers.Interrogated group number type shall indicate the number of interrogated group TETRA identity elements,that shall follow the element. The element shall also indicate whether the following interrogated groupTETRA identity elements shall be interpreted as one group number, a list of 2-10 group numbers or arange of group numbers. In case of range first and last element of the range shall be given.Interrogated group TETRA identity element is a repeatable element that shall appear and shall beinterpreted as indicated by interrogated group number type element. There shall be at least oneinterrogated group TETRA identity in a INTERROGATE primitive. Interrogated group TETRA identityelement shall always have address type as first partial element. Address type shall be followed by SNA orSSI. Address extension shall always follow SSI, if address extension is used. Omitted address extensionshall imply that the address extension shall be the address extension of authorized user. SNA, if used,shall refer to a SNA defined for authorized user.Table 8: INTERROGATE request contentsElementC/O/MRemarkSS typeM:= SS-LELE message typeM:= INTERROGATEInterrogated group number typeMInterrogated group TETRA identityMRepeatable
Address type identifierM
Short Number AddressC
Short Subscriber IdentityC
Address extensionC5.1.1.10INTERROGATE-ACK confirmINTERROGATE-ACK confirm primitive shall be offered from FE3 to application over TNSS-SAP. Theprimitive shall contain the SS-LE information elements listed in table 9.Interrogated group number type shall indicate the number of interrogated group TETRA identity elements,that shall follow the element. The element shall also indicate whether the following interrogated groupTETRA identity elements shall be interpreted as one group number, a list of 2-10 group numbers or arange of group numbers. In case of range first and last element of the range shall be given.Interrogated group TETRA identity element is a repeatable element that shall appear and shall beinterpreted as indicated by interrogated group number type element. There shall be at least oneinterrogated group TETRA identity in a INTERROGATE primitive. Interrogated group TETRA identityelement shall always have address type as first partial element. Address type shall be followed by SNA orSSI. Address extension shall always follow SSI, if address extension is used. Omitted address extensionshall imply that the address extension shall be the address extension of authorized user. SNA, if used,shall refer to a SNA defined for authorized user.It is required that result for interrogation and any following elements in the primitive apply for all groupnumbers given as interrogated group TETRA identity. If the elements would be different, FE3 shall deliverseparate INTERROGATE-ACK primitives to application.SIST EN 300 392-12-14 V1.1.1:2003
Page 18Draft prETS 300 392-12-14: September 1996Table 9: INTERROGATE-ACK confirm contentsElementC/O/MRemarkSS typeM:= SS-LELE message typeM:= INTERROGATEInterrogated group number typeMInterrogated group TETRA identityMRepeatable
Address type identifierM
Short Number AddressC
Short Subscriber IdentityC
Address extensionCResult for interrogationMnote 1LE typeOLE used over ISIOnote 2Basic service typeORepetition rateONOTE 1:If the interrogation request failed, the reason is specified here.NOTE 2:The element should indicate if SS-LE should or should not beinvoked over the ISI.5.1.2Parameter descriptionAddress Extension =Mobile Country Code (MCC) + Mobile Network Code (MNC).See ETS 300 392-1 [4] clause 7.Address type Identifier =0Short Number address (SNA)1Short Subscriber Identity (SSI)2TETRA Subscriber Identity (TSI = SSI + Address Extension)See ETS 300 392-1 [4] clause 7.Call identifier, see ETS 300 392-2 [2], subclause 14.Basic service type =0Multipoint circuit mode speech call1Multipoint circuit mode data callDefined group number type =0subscriber number, 1 subscriber number following of any allowed type1range of numbers, 2 subscriber numbers following of any allowed type2list of subscriber numbers, 2-10 subscriber numbers following of any allowed typeDefined group TETRA identity, shall be any of the following:-Address type identifier + Short Number Address (SNA)-Address type identifier + Short Subscriber Identity (SSI)-Address type identifier + Short Subscriber Identity (SSI) + Address extensionSee ETS 300 392-1 [4] clause 7.Called group number = TETRA subscriber identity (TSI).LE used over ISI =0applied over ISI1not applied over ISISIST EN 300 392-12-14 V1.1.1:2003
Page 19Draft prETS 300 392-12-14: September 1996LE type =0LE paging1No LE pagingInterrogated group number type, as defined group number type.Interrogated group TETRA identity, as defined group TETRA identity.Repetition rate =0any rate1low2normal3highResult for definition =0accepted1rejected for any reason2user not Authorized3unknown TETRA identity4parameters not valid5insufficient information6invalid basic serviceResult for interrogation, as Result for definition.Short Number Address (SNA), see ETS 300 392-1 [4] clause 7.Short Subscriber Identity (SSI), see ETS 300 392-1 [4] clause 7.SS-LE Indication =0LE broadcast1LE acknowledgement2LE pagingSIST EN 300 392-12-14 V1.1.1:2003
Page 20Draft prETS 300 392-12-14: September 19965.1.3Mapping of SS-LE primitives to TNSS primitivesTable 10 shows the mapping of the SS-LE primitives to TNSS primitives.Table 10: Mapping of the SS-LE primitives to TNSS primitivesSS-LE primitiveTNSS-SERVICErequestTNSS-SERVICEconfirmTNSS-SERVICEindicationTNSS-SERVICEresponseTNSS-INFOindicationTNSS-ERRORindicationRemarkDEFINEin FE3----DEFINE-ACK-withsuccessfuldefinitionin FE3--withunsuccessfuldefinition inFE3note 1INFORM1in FE1INFORM2in FE1INFORM2-ACKin FE1note 2INFORM3in FE1INFORM3-ACKin FE1note 2INTERROGATEin FE3/FE1----INTERROGATE-ACK-withsuccessfulinterrogation inFE3/FE1-withunsuccessfulinterrogationin FE3/FE1note 3NOTE 1:For this purpose the definition is considered successful if the value for "Result for definition" is"accepted".NOTE 2:Application shall return the INFORM2-ACK/INFORM3-ACK to FE1 only if the subscriber shalljoin or request to join the ongoing call.NOTE 3:For this purpose the interrogation is considered successful if the value for "Result forinterrogation" is "accepted".5.2SS-LE protocol states5.2.1Protocol states of FE15.2.1.1State IDLEIDLE shall be the normal state of FE1. In this state FE1 shall receive all the SS-LE indications related toan ongoing call. FE1 shall send the SS-LE indications to the application. FE1 shall receive the responsesto LE acknowledgement and to LE paging, in state IDLE, too. FE1 shall send the received responses toFE2.The behaviour of FE1 and application collocated to FE1 is described in:annex A:Reception of SS-LE broadcast indications in MS/LS in Layer 3;annex B:Reception of SS-LE acknowledgement indications in MS/LS in Layer 3;annex C:Reception of SS-LE paging indications in MS/LS in Layer 3.5.2.2Protocol states of FE25.2.2.1State IDLEIDLE should be the normal state of FE2. In this state FE2 should receive the definition and interrogationrequests from FE3. FE2 should verify the received definition or interrogation requests. If FE2 accepts theinterrogation request, FE2 should fetch the interrogated data and sends it to FE3. If FE2 accepts thedefinition requests, FE2 should save the new definition data to the database, start the sending ofSS-LE messages (INFORM1, INFORM2 or INFORM3) if the group call in ongoing and FE2 shouldacknowledge the service request to FE3.SIST EN 300 392-12-14 V1.1.1:2003
Page 21Draft prETS 300 392-12-14: September 1996FE2 should receive call invocation messages in order to invoke the SS-LE, if defined for the call. At thereception of call invocation FE2 should determine the used SS-LE type and invoke the SS-LE if theservice is defined for the group. After that, FE2 should move to the state SS-LE ACTIVE.5.2.2.2State SS-LE ACTIVESS-LE ACTIVE should be the state in which FE2 should start the sending of SS-LE invocations and thesending should be ongoing. In state SS-LE ACTIVE FE2 sends the SS-LE indications:-in case of LE broadcast, FE2 should send INFORM1 information flows;-in case of LE acknowledgement, FE2 should send INFORM2 information flows;-in case of LE paging, FE2 should send INFORM2 information flows.If the SS-LE should be invoked in another TETRA system(s) over ISI, FE2 should send theINFORM4 messages to the TETRA system(s).After sending the SS-LE indications, FE2 should set the timer T1. The timer is set with a valuecorresponding to low, normal or high, as defined for the group.
Each time when the timer T1 expires, FE2should send new SS-LE indications.At the reception of LE acknowledgement or LE paging responses from FE1s, FE2 notifies theseresponses. In the case of LE paging response, FE2 should change the SS-LE type to LE broadcast orLE acknowledgement in that area.At the reception of call release indication, FE2 should stop the service and the sending of allSS-LE indications related to the call.5.2.3Protocol states of FE3 (authorized user)5.2.3.1State IDLEIDLE shall be the normal state of FE3. In this state FE3 shall receive the definition or interrogationrequests from the user. FE3 shall verify the requests and if it accepts them, FE3 shall send them to FE2.In IDLE state FE3 shall also receive the acknowledgements and responses for the definition orinterrogation requests. At the reception of these information flows, FE3 shall send them to the application.5.2.4Protocol states of FE45.2.4.1State IDLEIDLE should be the normal state of FE4. In this state FE4 should receive the information flows fromFE3 or FE1 to be delivered to FE2 in another system. And, FE4 should also receive the information flowsfrom FE2 to be delivered to FE1 or FE3 located in this system.At the reception of SS-LE invocations (INFORM4s) from another system, FE4 should determine theLE type to be applied, send the correct SS-LE invocations and move to SS-LE ACTIVE state.5.2.4.2State SS-LE ACTIVESS-LE ACTIVE should be the state in which FE4 should start the sending of SS-LE invocations and thesending should be ongoing. In state SS-LE ACTIVE FE4 should send the SS-LE indications:-in case of LE broadcast, FE4 should send INFORM1 information flows;-in case of LE acknowledgement, FE4 should send INFORM2 information flows;-in case of LE paging, FE4 should send INFORM2 information flows.After sending the SS-LE indications, FE4 should set the timer T1. The timer should be set with a valuecorresponding to low, normal or high, as defined for the group if defined.
Each time when the timerT1 expires, FE4 should send new SS-LE indications.SIST EN 300 392-12-14 V1.1.1:2003
Page 22Draft prETS 300 392-12-14: September 1996At the reception of LE acknowledgement or LE paging responses from FE1s, FE4 should notify theseresponses. In the case of acknowledged group call, FE4 should send the acknowledgements to system 1.In the case of LE paging response, FE4 should change the SS-LE type to LE broadcast or LEacknowledgement in that area.At the reception of call release indication, FE4 should stop the service and the sending of allSS-LE indications related to the call.5.3Procedures5.3.1Procedures for FE15.3.1.1Verification in FE1At the reception of SS-LE INFORM1, INFORM2 or INFORM3 request, FE1 shall inform application aboutthe received LE indication. In case of LE acknowledgement or LE paging FE1 shall send INFORM2-ACK/INFORM3-ACK to FE2 if the application indicates that the subscriber joins (LE acknowledgement) orwishes to join (LE paging) the ongoing call.5.3.2Procedures for FE25.3.2.1Verification in FE2 (for definition)At the reception of SS-LE DEFINE request, FE2 should verify that the request is authorized and that theparameters are in the correct range. The parameters should correspond to the FACILITY elementdefinitions given in subclause 5.5. After making the checks, FE2 should either continue to carry out therequest, or FE2 should reject it.The SNA should refer to authorized user's SNA definitions, if applied. FE2 should replace the SNA in thedefinition saved to database in SwMI by the complete TETRA subscriber identity, GSSI. If applied indefinition, the SNA should be defined for the authorized user, if not, FE2 should not accept it.If address extension is not applied with SSI, that should imply that the address extension should be theaddress extension of authorized user. FE2 should save the definition to the database in SwMI by using thecomplete TETRA subscriber identity, GSSI.If the definition is requested for a
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...