TETRA MoU TTR Technical Ver Report December 2003

Transcription

1 TETRA MoU TTR Technical Ver Report December 2003 Source: TETRA MoU Technical Forum Keywords: Interoperability, ISI ANF-ISIGC TETRA Memorandum of Understanding (TETRA MoU); TETRA Interoperability Profile (TIP) Part 6: Inter System Interface (ISI) Group Call ANF-ISIGC Implementation TETRA MoU Postal address: P.O. Box 88, St Ives, PE27 6PD, England Internet: http// Tel: Fax: Copyright Notification: Reproduction is only permitted for the purpose of standardisation work undertaken within TETRA MoU. The copyright and the foregoing restrictions extend to reproduction in all media. Liability Notification: TETRA MoU can not be made liable for the contents of this document. TETRA MoU has no liability for any direct or indirect loses and damages this document may cause. TETRA MoU All rights reserved.

2 Page 2 December 2003 Empty Page

3 December 2003 Page 3 Contents 1 Scope References Definitions and abbreviations Definitions Abbreviations Introduction General Notation Inter System Interface (ISI) Group Call ANF-ISIGC Implementation Protocol Specification Documents Service Overview Issues Call set-up issues Behaviour IOP connection modes Disconnection issues PSS1 signalling issues Signalling Diagrams Call Setup Single calling party, no queuing for resources Single calling party, some queuing for resources Single calling party, some queuing for resources, different connect strategy to Single calling party, some queuing for resources, showing multiple releasing Multiple calling parties, a new calling party is on a SwMI not currently in the call Multiple calling parties the second calling OSwMI is ready first. The new setup from the second OSwMI is received while the CSwMI is delaying the call Multiple calling parties the second calling OSwMI is ready first. The new setup from the second OSwMI is received while the CSwMI is activating the call Multiple calling parties the second calling OSwMI is ready first Multiple calling parties the second calling OSwMI is ready first. Shows parties not connected into the call that could have been Multiple calling parties the second calling OSwMI is ready first Multiple calling parties an OSwMI transitions back into a PSwMI Multiple calling parties and no PSwMI Multiple calling parties at the same SwMI Successful Group Call Establishment. The CSwMI does not accept more than one calling party Late Entry A SwMI joins with a Connected Call An emergency priority call to a group that is already in an active, non-emergency, call...42

4 Page 4 December A call Collision at startup Partial Successful Group Call Establishment, Call is not accepted by a PSwMI Unsuccessful Group Call Establishment rejected by an OSwMI Unsuccessful Group Call Establishment, the CSwMI cannot accept some parameters, such as resource allocation, in the ISI Setup Acknowledge from an OSwMI Unsuccessful Group Call Establishment, OSwMI or Party times out Unsuccessful Group Call Establishment rejected by the CSwMI Call Maintenance Call Maintenance Call Termination The release of a SwMI from a call Call Disconnection, as a result of a PSwMI disconnecting Call Disconnection by the CSwMI ANF-ISIGC PDUs ISI-Originating-Setup ISI-Setup-Initiate ISI-Info, sent by a CSwMI to an OSwMI during call setup ISI-Setup-Acknowledge ISI-Delay ISI-Info, sent in a PSS1 Facility by the CSwMI, to update group information ISI-Info, sent by a PSwMI ISI-Tx Demand ISI-Tx Ceased ISI-Tx Granted ISI-Tx Interrupt ISI-Reject ISI-Disconnect ISI-Release Other Issues Security Level at Air Interface Call Restoration Appendix A1. (Informative) Items for Future Consideration List of Figures Figure 1: PSS1 Call set-up Figure 2: Successful Group Call Set-up. Single calling party, no queuing for resources Figure 3: Successful Group Call Set-up. Single calling party, some queuing for resources Figure 4: Figure 5: Figure 6: Successful Group Call Set-up. Single calling party, some queuing for resources, different connect strategy to Successful Group Call Set-up. Single calling party, some queuing for resources, showing multiple releasing Successful Group Call Set-up. Multiple calling parties, a new calling party is on a SwMI not currently in the call... 27

5 December 2003 Page 5 Figure 7: Figure 8: Figure 9: Figure 10: Figure 11: Figure 12: Figure 13: Figure 14: Figure 15: Successful Group Call Set-up. Multiple calling parties the second calling OSwMI is ready first. The new setup from the second OSwMI is received while the CSwMI is delaying the call...28 Successful Group Call Set-up. Multiple calling parties the second calling OSwMI is ready first. The new setup from the second OSwMI is received while the CSwMI is activating the call...30 Successful Group Call Set-up. Multiple calling parties the second calling OSwMI is ready first...32 Successful Group Call Set-up. Multiple calling parties the second calling OSwMI is ready first. Shows parties not connected into the call that could have been...34 Successful Group Call Set-up. Multiple calling parties the second calling OSwMI is ready first...36 Successful Group Call Set-up. Multiple calling parties an OSwMI transitions back into a PSwMI...37 Successful Group Call Set-up. Multiple calling parties and no PSwMI...38 Successful Group Call Set-up. Multiple calling parties at the same SwMI...39 Successful Group Call Set-up. CSwMI only supported one calling party...40 Figure 16: Late Entry...41 Figure 17: A Party joins with an Active Call...41 Figure 18: An emergency priority call to a group that is already active in a call...42 Figure 19: Figure 20: Figure 21: Figure 22: A call collision at startup...43 Partial Successful Group Call Setup, Call is not accepted by a PSwMI...43 Unsuccessful Group Call Establishment, rejected by an OSwMI...44 Unsuccessful Group Call Establishment, the CSwMI cannot accept some parameters in the ISI Setup Acknowledge from an OSwMI...45 Figure 23: Unsuccessful Group Call Establishment, OSwMI or owing Mobile times out...45 Figure 24: Figure 25: Figure 26: Figure 27: Unsuccessful Group Call Establishment, rejected by the CSwMI...46 Examples of Call Maintenance...47 The release of a PSwMI from an ongoing call...49 Call Disconnected...49 Figure 28: Call Disconnected by the CSwMI...50

6 Page 6 December 2003 List of Tables Table 1: ISI-Originating-Setup, PDU Table 2: ISI-Setup-Initiate, PDU Table 3: ISI-Info, PDU, from the CSwMI to the OSwMI, during call setup Table 4: ISI-Setup-Acknowledge, PDU Table 5: ISI-Delay, PDU Table 6:, PDU Table 7: ISI-Info, PDU, sent by the CSwMI to update group information Table 8: ISI-Info, PDU, sent by a PSwMI Table 9: ISI-Tx Demand, PDU Table 10: ISI-Tx Ceased PDU Table 11: ISI-Tx Granted PDU Table 12: ISI-Tx Interrupt, PDU Table 13: ISI-Reject, PDU Table 14: ISI-Disconnect, PDU Table 15: ISI-Release, PDU Foreword This technical report has been produced by the Technical Forum subgroup of the TETRA MoU organisation. The purpose of the report is to specify protocols for basic TETRA services in order to ensure interoperability of these services for equipment produced by different manufacturers. The contents of this report are subject to continuing work within the Technical Forum and may change following TETRA MoU approval. Should Technical Forum modify the contents of this report, it will then be republished by TETRA MoU with an identifying change of release date and an increase in revision number as follows: Revision 1.x.y where y the third digit is incremented when editorial only changes have been incorporated; x the second digit is incremented for other changes, i.e. technical enhancements etc.

7 December 2003 Page 7 1 Scope This TETRA MoU Technical Report defines the requirements for TETRA interoperability. The required features are defined and functional descriptions of these features are specified. Items of functionality are accompanied by a figure illustrating the signalling between engaged SwMIs. Only the names of the Protocol Data Units (PDUs) are shown, together with the salient elements of the PDUs. This document does not replace or supersede the TETRA inter system standards but simply indicates the profile of implemented functionality from the standard. This profile, together with the standard protocol specification, provides the necessary information for a terminal manufacturer skilled in TETRA to implement terminal equipment that will inter-operate with deployed SwMIs and terminals. 2 References [1] ETSI EN : Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 2: Air Interface (AI), v2.4.1, [2] ETS : Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 1: General Network Design, v1.2.1, [3] ETS : Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI); Sub-part 1: General Design, v1.2.1, [4] ETSI : 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), v1.2.0, [5] TETRA MoU TTR : Core, Part 1, February 2003, Ver [6] TETRA MoU TTR : Inter System Interface (ISI) Individual Call ANF-ISIIC Implementation, Part 2, May 2002, Ver [7] ETSI : Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 3: Interworking at the Inter-System Interface (ISI); Sub-part 2: Additional Network Feature Individual Call (ANF-ISIIC), v1.2.0, [8] ETSI EN : Terrestrial Trunked Radio (TETRA); Voice plus Data (V+D); Part 7: Security v2.1.20, Definitions and abbreviations 3.1 Definitions For the purposes of this report, the following definitions apply: Originating SwMI (OSwMI): Controlling SwMI (CSwMI): SwMI at which group call is originated. SwMI which setups and maintains the group call Participating SwMI (PSwMI): SwMI, which participates in a Call, but is not the originating or controlling SwMI.

8 Page 8 December Abbreviations For the purposes of this report, the following abbreviations apply: ANF CswMI IOP ISI OswMI PswMI SwMI TETRA TIP Additional Network Feature Controlling SwMI Inter-Operability Inter-System Interface Originating SwMI. Participating SwMI. Switching and Management Infrastructure TErrestrial Trunked RAdio TETRA Inter-operability Profile

9 December 2003 Page 9 4 Introduction This report documents ISI TETRA interoperability requirements. The purpose of the report is to define the features required to conform to the ISI TETRA Interoperability Profile. The set of features required for this TIP is a limited set of features likely to be required in many TETRA systems.. The interoperability requirements are extended requirements from the conformance and type approval requirements. However, still these requirements are derived from the TETRA standard, once these have been appropriately updated, with additional constraints on parameter variations for some PDUs and mandatory requirements for support on some optional protocol functions. 5 General 5.1 Notation The following sections describe the TIP services and functionalities accompanied by figures illustrating the signalling between SwMIs. Pertinent elements only are shown. In the diagrams, a message shown with a dashed arrow is optional. 6 Inter System Interface (ISI) Group Call ANF-ISIGC Implementation 6.1 Protocol Specification Documents The protocol documents that cover Inter System Interface (ISI) Group Call ANF-ISIGC Implementation functionality are as follows: TETRA V+D Air Interface Specification edition 2, ref. [1] TETRA V+D Interworking at the Inter System Interface (ISI), ref. [3] and [4] 6.2 Service Overview This specification describes the message sequences for group calls. To put the ISI sequences into context, the air interface PDUs are shown on the sequences. The specification concentrates on call signalling. Group attachment will be covered in a later version. The reader is assumed to be familiar with the contents of the referenced documents.the contents of this specification require the associated WG3 change requests, to be applied to the ETSI ISI Group Call specification, reference [4]. This TIP covers the following features: point-to-multipoint group calls. Queuing for resources. Calls with short hang times. Call setup, clear down and maintenance (transmission control). Speech calls. Emergency calls. Fast call setup. Multiple calling parties i.e. no one party prevents the call from setting up due to lack of resources. Flexible call connection criteria at a controlling SwMI.

10 Page 10 December 2003 Flexible call acceptance criteria at a participating/originating SwMI. Re-evaluation by the CSwMI of which PSwMIs should be in the call (i.e. SS-LE). Releasing of resources during call setup. Permanent resource allocation policy during call maintenance. This TIP does not cover the following features which will be supported in later phases: Acknowledged group calls and broadcast calls. Rerouting to a different CSwMI (group linking) Call restoration. Withdrawing from or continuing with a call (wait/continue). Supplementary services (CAD, CLIR, CF, BIC etc). Sending of profile information in the ISI Setup Initiate. Call modification DTMF procedures Critical users Other resource allocation policies during call maintenance. 6.3 Issues Call set-up issues Behaviour Specification and implementation In [4], the basic group call set-up involves the controlling SwMI waiting until all participating (including originating) SwMIs are fully ready before connecting the call (see ). One variation on this is a partial connect when the controlling SwMI connects the call when only some of the participating SwMIs are ready (see [4] ). The intention is that the first subscriber to call the group is successful, providing that resources are available. If the SwMI queues for resources for the first subscriber, that subscriber is still successful, even if the SwMI is able to allocate resources immediately to another subscriber who makes a compatible call request to the same group just after the first. The calling party may request transmission or not. The controlling SwMI allocates call ownership to the calling party. This is not how some SwMI manufacturers currently implement group calls. A party requesting a group call normally requests transmission. When the current talker ceases and there is no one queued to talk, a short hang timer (e.g. 3s) is started. If the timer expires before transmission is granted to another user, then the call is cleared. The next time a group member wishes to talk a U_SETUP is sent to set up the call again. In this way, resources are not wasted during extended periods of silence. In this scenario, it is important that the call is not held up by a party who requests to talk, but for whom the SwMI cannot allocate resources. If, while the SwMI is queuing for resources for one party which has called the group, another party makes a compatible call to the group and the SwMI is able to allocate resources for it, then the call must be connected with the latter party as the calling party. If the new calling party requested the call with a higher priority than the original calling party, then all SwMIs must be informed of the higher priority. The SwMI does not allocate call ownership to any party.

11 December 2003 Page Interworking Whichever way a SwMI manufacturer has implemented intra-swmi group calls, that manufacturer is likely to wish to implement a similar behaviour in ISI group call operation. This presents problems in interworking. If an ISI group call is made in a system deploying SwMIs from different manufacturers, each with different behaviour, then the behaviour of the call may not be as expected by the talking party. If there is no queuing for resources, then the behaviour of each SwMI is likely to be very similar. The call will set up quickly, and predictably. If, however, there is queuing for resources, then the behaviour is less predictable. For example, suppose the CSwMI connects the call when the OSwMI has indicated it is ready and PSwMI1 has indicated that it is ready. The OSwMI was ready when the calling party could be connected into the call and the PSwMI1 was ready when a called party could be connected into the call. Another SwMI, PSwMI2, does not indicate that it is ready, because it waits until all parties are ready before doing this. Another SwMI, PSwMI3, also does not indicate that it is ready because it waits until a number of critical user parties are ready. The result is that the call connects, but without parties on PSwMI2 and PSwMI3 which could have been connected into the call. Such anomalies could be removed by mandating SwMI behaviour within a commonly held group profile. However, this is outside the scope of this TIP. In this TIP, the anomalies are considered acceptable, but usually avoidable. This document proposes a number of possible behaviours for group calls over ISI, which include the ways most manufacturers currently implement group calls together with behaviours from [4]. However, one set of behaviours is recommended. The intention is to minimise extensions to the signalling in [4]. When a group call is made over a system deploying SwMIs which all conform to behaviour described in this document as recommended the behaviour of the call at any party in the call will be highly predictable. When a group call is made over a system deploying one or more SwMIs, which conform only to behaviour, described in this document as acceptable the behaviour of the call at any party in the call will be less predictable IOP connection modes Multiple calling Parties The only case where multiple calling parties are, partially, catered for in the ETSI specification 1, reference [4], is the case of a party calling a group which already has a call setup, but not in the SwMI of the calling party. This feature is only implemented once the existing call has been connected and lacks definition for the sending of the ISI-Setup-Initiate PDU. Since there is very little definition in [4] to indicate how this required feature is to be supported, this document adds to the specification, so that the required functionality can be supported by it. Multiple calling parties are required since it appears that most manufacturers have implemented group calls with a very short hang time, see section The call is set up again, if it is not currently up, when a party requests to talk. It seems that this feature was not expected, and therefore not supported, at the time the ETSI specification was constructed. Support for this feature has been designed to be efficient. It minimises the number of signalling and PSS1 connection needed to implement the feature. Diagrams showing examples of call setup with the multiple calling parties are given in the later stages of section The feature, which is the recommended behaviour, is considered in the following categories. The description in section overrides other sections when an emergency calling party appears and the existing call is not at an emergency priority. 1 with the possible exception of call amalgamation

12 Page 12 December A new calling party appears at a SwMI not currently in the group call This is the area having partial support in [4]. The suggestion is to extend the existing definition so that it has full support, without changing the existing definition. In order to support a new calling party appearing when a group call is setting up, the receipt of ISI- Originating-Setup, on a new PSS1 connection, while the call is in any state is supported. The processing of the ISI-Originating-Setup causes the sending back of the ISI-Setup-Initiate and the merging of the new OSwMI into the call A new, compatible, calling party appears at a SwMI where a group call is active A new, compatible, calling party appearing in a SwMI does not need to send any signalling over the ISI interface. The local call instance joins the party into the call and no signalling is sent to the CSwMI. This is the recommended behaviour. It is acceptable, but optional, that an ISI-Originating-Setup is sent to the CSwMI A new, compatible, calling party appears at an OSwMI where a group call is still in the setup phase Since the OSwMI will already have sent in an ISI-Originating-Setup, it is recommended that another ISI- Originating-Setup is not sent to the CSwMI. The sending of a second or subsequent ISI-Originating- Setup is acceptable, but not required. The OSwMI attempts to get resources so that the new calling party can be connected into the call. The ISI-Setup-Acknowledge is sent to the CSwMI based on the SwMIs strategy for being ready to connect, see section for details on strategies that may be adopted. The ISI-Setup-Acknowledge sent by an OSwMI always contains the ITSI of a calling party. The CSwMI may choose this party, or another party sent in an ISI-Setup-Acknowledge from another OSwMI, as the calling party of the call indicated in the. The CSwMI will only physically add the calling party address into the PDU, when the calling party is different to that sent in the ISI-Setup-Initiate. In this case the call amalgamation field will be set. The ISI-Setup-Acknowledge is modified from the ETSI definition in 7 so that it can carry the ITSI of a calling party that is ready to be connected. See section for the definition of the PDU A new, compatible, calling party appears at a PSwMI where a group call is still in the setup phase An ISI-Originating-Setup is sent to the CSwMI on the existing PSS1 connection, the CSwMI does not send a response PDU. The PSwMI now changes its designation to an OSwMI and proceeds as described in the section above. The strategy it uses for sending back its ISI-Setup-Acknowledge is changed from the one appropriate for a PSwMI, see , to the one appropriate for an OSwMI, see The ISI-Originating-Setup may also be sent on a new PSS1 connection. On receipt of the ISI-Originating-Setup, the CSwMI reclassifies the old PSwMI as a new OSwMI A new calling party requesting an emergency call appears at a SwMI where the existing call is not at an emergency priority If an emergency priority call is received, for a group that is already known to be in a group call at a non emergency priority, then a new PSS1 connection is used to send an ISI-Originating-Setup to the CSwMI. The CSwMI disconnects the existing call and sets up the new emergency call to the same group.

13 December 2003 Page 13 The SwMI of the new calling party may choose to release the existing call, prior to being told to do so by the CSwMI. This is in accordance with [5], section A new, incompatible, calling party appears at a SwMI where a group call is already active If a SwMI decides that a new calling party s call request is not compatible with an existing group call then the SwMI will not join the new party into the call. No ISI signalling is involved in this case. The decision as to what is, and what is not a compatible call is a SwMI dependent matter, reasons could be: The new calling party is not a member of the group Incompatible priority (below emergency) Data call requested Incompatible SS-Facility Resources not available Others Once a SwMI has accepted a new calling party as able to call the group then no other SwMI may reverse that decision A new calling party appears at a CSwMI that only supports a single ISI-Originating- Setup A CSwMI receiving a further ISI-Originating-Setup when it does not support more than one may reject, with an ISI-Reject, the additional call request The sending of subsequent ISI-Originating-Setups to the CSwMI When it is possible to send an ISI-Originating-Setup to the CSwMI this can be done in one of two ways: The ISI-Originating-Setup may be sent on the existing PSS1 connection for the call. In this case the CSwMI will not respond to the ISI-Originating-Setup. The ISI-Originating-Setup is sent in a PSS1 Facility. In order to achieve this the sending SwMI will already have locally merged the new call into the existing call. The ISI-Originating-Setup may be sent on a new PSS1 connection, in a PSS1 Setup, to the CSwMI. In this case the CSwMI will respond, also on the new PSS1 connection, with an ISI-Setup-Initiate. Since the call is already active in the CSwMI, the CSwMI will set the call amalgamation field in the ISI-Setup-Initiate. The SwMI receiving the ISI-Setup-Initiate will merge the call with the existing call to the same group that it already has running. The older PSS1 connection will be used for the merged call. It is the responsibility of the CSwMI to clear down the new PSS1 connection. This is done by sending the ISI-Setup-Initiate in a PSS1 Disconnect. NOTE: The only mandatory uses of a subsequent ISI-Originating-Setup are when a PSwMI turns into an OSwMI during call setup, and when an emergency call is started in a SwMI already having a call to the same group at a non emergency priority. It is recommended that these are the only times a subsequent ISI-Originating-Setup is used Support for Releasing of Resources during Call Setup As in [4], the controlling SwMI sends ISI-Release (delay group call setup) to all SwMIs that have responded with ISI-Setup-Acknowledge when the CSwMI has decided to delay and not to connect the call. In addition, and again as per [4], ISI-Release (delay group call setup) is sent to a SwMI that sends an

14 Page 14 December 2003 ISI-Setup-Acknowledge, but the CSwMI is already delaying the call and decides not to attempt to initiate the call again with ISI-Setup-Initiate(s). This approach results in the complete support for releasing of resources during call setup as outlined in [4]. A PSwMI or OSwMI may decide not to release resources on receiving an ISI-Release (delay group call setup). Diagrams showing examples of call setup with the releasing of resources, using various CSwMI connection strategies, are given in section Call Ownership Call ownership may be allocated by the CSwMI. To prevent an owner party clearing a call where a different party is currently talking, the CSwMI can choose not to allocate call ownership. This is the recommended behaviour for IOP operation Call acceptance by a Participating SwMI It is not clear in [4] what criteria a PSwMI should use before indicating that it has accepted the call (i.e. that it is ready to be connected into the call, and sends in an ISI-Setup-Acknowledge). Possible modes of acceptance include: 1. The PSwMI indicates acceptance if it has resources available to connect at least one group member party at the SwMI. 2. The PSwMI indicates acceptance if it has resources available to connect all critical users at the SwMI. 3. The PSwMI indicates acceptance only when it has resources available to connect all group member parties at the SwMI. 4. If it has not already done so, the PSwMI indicates acceptance after a defined period. 5. The PSwMI indicates acceptance once it has determined that it has called group members present. While all acceptance modes are acceptable for IOP operation, mode 5 is recommended. A discussion of the reason for this is contained in section Call acceptance by an Originating SwMI It is not clear in [4] what criteria an OSwMI should use before indicating that it has accepted the call (i.e. that it is ready to be connected into the call, and sends the CSwMI an ISI-Setup-Acknowledge). Possible modes of acceptance include: 1. The OSwMI indicates acceptance if it has resources available to connect a calling party. 2. The OSwMI indicates acceptance if it has resources available to connect any party at the SwMI. 3. The OSwMI indicates acceptance if it has resources available to connect a calling party and a called group member at the SwMI. 4. The OSwMI indicates acceptance only when it has resources available to connect all group member parties at the SwMI. 5. The OSwMI indicates acceptable when it has resources available to connect a calling party and all group members at the SwMI.

15 December 2003 Page If it has not already done so, the OSwMI indicates acceptance after a defined period. While all acceptance modes are acceptable for IOP operation, mode 1 is recommended. A discussion of the reason for this is contained in section Call connection by Controlling SwMI There are at least four possible modes of call connection for IOP: 1. The CSwMI connects the call as soon as any SwMI is ready. 2. The CSwMI connects the call as soon as any OSwMI is ready. 3. The CSwMI connects the call as soon as both an OSwMI and a PSwMI are ready. 4. The CSwMI connects the call as soon as both a calling OSwMI and all PSwMIs are ready. While all connection modes are acceptable for IOP operation, mode 2 is recommended. A discussion on the reason for this is contained in section Control of which parties are in the call Control of inclusion in the group call of a calling party and/or a called party A previous version of this document gave definitive control to the CSwMI to allow it to connect the call when it knew that there was at least one called party in the call. It did this in a timely manner. This was achieved by the inclusion of the calling_resource_status and called_resource_status into the ISI-Setup- Acknowledge PDU and a change in the protocol to allow a SwMI to send an additional ISI-Setup- Acknowledge when it becomes ready for either the calling or called resource. However, this garnered some opposition, mostly because of the protocol change, and is not the basis of this TIP. The protocol is the same as that described in [4]. However, there are limitations in this approach that manufacturers have accepted. One limitation is that it is not possible for the CSwMI to connect the call in a timely and efficient manner, if it needs to ensure that there is a called party in the call. An ISI group call may be connected with no called party in it. The conditions used by a CSwMI to decide when to connect the call and the conditions used by an OSwMI or PSwMI to send back its ISI-Setup-Acknowledge are flexible and are not prescribed in this specification. However the following strategy is recommended: An OSwMI to send in its ISI-Setup-Acknowledge when it has resources to allow a calling party to be connected into the call. The calling party that is ready to connect is indicated in the ISI-Setup- Acknowledge. A PSwMI that becomes an OSwMI because it hosts a new calling party also follows this rule. The CSwMI to connect the call when it has an OSwMI that has sent in its ISI-Setup-Acknowledge, and thus a calling party, is ready. These rules, together, ensure that a call cannot be connected without a calling party and that the call is set up as soon as is practical 2. It could mean, as noted above, that there is not a called party in the call, see section for an issue with this that can be addressed. The strategy to be used by a PSwMI is recommended to be: To send back its ISI-Setup-Acknowledge as soon as it has determined that called group members exist at the PSwMI.. 2 within the limits of the protocol in [4]. i.e. even when an OSwMI is ready the CSwMI may have to initiate the call to other SwMIs before it can connect the call.

16 Page 16 December 2003 This strategy allows the PSwMIs parties to be connected into the call, as soon as resources are available for them, and the CSwMI has decided to connect the call. Adopting this rule minimizes the chances, identified in section , that the PSwMI can have ready parties that are not brought into a connected call. Manufacturers should be aware that the adoption of other strategies, with the protocol and PDU definitions defined in [7], can lead to anomalies and non efficient call setup. As an example, let us suppose that the strategy of an OSwMI, which also hosted called parties, was to send back its ISI-Setup- Acknowledge only when resources for its calling party and at least one called party were available. The strategy of the CSwMI was to connect only when it had both an OSwMI and a PSwMI in the call. These strategies could be adopted in order to ensure that there is a called party in the call when it connects. Example anomalies are as follows: The calling party could have obtained resources so that it can be connected into the call and there may be called parties with resources on other SwMIs. This should satisfy the conditions to connect the call. However, because the OSwMI does not send in its ISI-Setup-Acknowledge, since it has no ready called party, the CSwMI has no knowledge of the OSwMI being ready for connection and so will not connect the call. Even if an OSwMI, with calling parties, had sent back its ISI-Setup-Acknowledge the call may not be connected immediately. This occurs when the CSwMI does not have a PSwMI ready to fulfill its conditions for connection. The call could actually have been connected since there is a called party ready at the OSwMI. However, the CSwMI doesn t know this from the signalling. These issues are compounded by the releasing mechanism. This is because if the call is not connected when it really could have been the CSwMI will release all of the SwMIs, which have sent in ISI-Setup- Acknowledge from the call. There is therefore no guarantee that the released resources can be obtained again when the resource that is being waited for becomes available. Another reason for the recommendation of the CSwMI connection strategy is that the recommendation does not rely on having a PSwMI in the call before connecting. If it did, the strategy used would have to be flexible to allow a different rule to be used when there was no PSwMI in the call. It would also need to be dynamic, and modify its rule, when a PSwMI that is in the call changes into an OSwMI. We believe that having one fixed rule will be easier to implement. Diagrams showing examples of call setup using various connection strategies are given in section Allowing all parties, that are ready, to be connected into the call in a timely manner If a PSwMI did not send back its ISI-Setup-Acknowledge when it had called parties available with resources to connect into the call there is a problem if the CSwMI decides to partially connect the call while the PSwMI is in this state. The called parties at the PSwMI will not be connected into the call although they are ready to be connected and the call has connected. An OSwMI may have called parties that are ready, but since it is waiting for a calling party to be ready, does not send in its ISI-Setup-Acknowledge. The parties at the OSwMI are not connected although the call itself has connected. This issue is resolved by the CSwMI, optionally, sending any delaying SwMI (one that has sent in an ISI- Delay) an ISI-Info PDU. The call_status field in the ISI-Info PDU is used to indicate that the call had connected. The receiving SwMI now has extra information. It could use the information to decide to change its strategy for sending back its ISI-Setup-Acknowledge. The recommendation is that the delaying SwMI, receiving an indication that the call had connected, would send back its ISI-Setup-Acknowledge immediately. As per, [4], the CSwMI will immediately connect the new SwMI into the call on receipt of the ISI-Setup- Acknowledge Allocation of Talk Permission at Call Connection Time Following the standard IOP rules, outlined in [5], the calling party of the group call is allocated the first talk permission. All other parties, including any that tried to setup the call, are told that another user has

17 December 2003 Page 17 talk permission. When the call is connected, all implied requests to talk (by other parties that tried to setup the call, but were not the calling party allocated talk permission) are not taken account of by the CSwMI, in the allocation of subsequent talk permission. These parties can only be allocated talk permission by the CSwMI if an ISI-TX Demand is received from a PSwMI hosting the party. This is consistent with behaviour defined in[1], section This section states that if a party was not granted permission to talk in a d_connect, or d_setup, it may then follow the transmission control procedures defined in Throttling of Demands It is recommended that a CSwMI limits the number of transmit demands which it queues. To avoid unnecessary loading of the CSwMI, it is recommended that a PSwMI should limit the number of transmit demands which it sends to the CSwMI Disconnection issues As stated earlier (see ), in the basic group call set-up described in [4], there is only one calling party at the OSwMI and ownership is given to the OSwMI in the ISI-Setup-Initiate. If the calling party disconnects during call set-up, the OSwMI sends ISI-Disconnect to the CSwMI indicating that this is from the owner. The CSwMI disconnects the call. In the implementation of group calls by some SwMI manufacturers, there may be more than one calling party. The CSwMI does not allocate call ownership to the OSwMI in the ISI-Setup-Initiate. Nevertheless, if a calling party disconnects during call set-up, it will send a U-Disconnect to its local SwMI because the MS is not informed whether it is the owner or not until it receives a D-Connect. If there are other calling parties in the call, then the call should not clear because another party may become the calling party, and the called group member parties on the OSwMI are still required to be in the call. To achieve this, if a calling party disconnects, and that party is not the only calling party on the OSwMI, then the OSwMI does not send in an ISI_Disconnect. If, however, the party is the only calling party on the OSwMI, then the OSwMI should send an ISI-Disconnect message indicating that the disconnection was requested by a call owner to the CSwMI. The CSwMI should disconnect the call only if there are no other OSwMIs in the call or calling parties on the CSwMI. If a disconnecting SwMI knows that the call is to be cleared in the disconnecting SwMI, then it can initiate the clearing before sending the ISI-Disconnect to the CSwMI. The underlying PSS1-Disconect PDU is used in this case. Otherwise, the disconnecting SwMI would send its ISI-Disconnect in a PSS1 Facility PDU. The CSwMI will determine if the P/OSwMI is to be removed from the call, if it does then an ISI- Release will be sent from the CSwMI in a PSS1 Disconnect. The CSwMI may release the call at any time. After the call is active, PSwMIs may disconnect when there are no longer any active parties on the SwMI PSS1 signalling issues In [7], for each ISI PDU, it is explicitly stated which PSS1 message is used to carry that PDU. The set-up of the ISI call is coupled to the set-up of the underlying PSS1 call. For example, an ISI-Alerting message is carried in a PSS1-Alerting message and an message is carried in a PSS1-Connect message. In [4], it is also stated which PSS1 messages may be used to carry a particular ISI message. However, further analysis shows that this is unnecessary; the set-up of the PSS1 call is driven from the setup of the ISI call. The first ISI PDU to be sent goes in the PSS1 Setup, the second, providing it is not a disconnect case, goes in the PSS1 Connect etc, Note that an ISI call set-up may initiate the set-up of several PSS1 calls. Figure 1 shows the PSS1 messages for a typical ISI call between two SwMIs.

18 Page 18 December 2003 SwMI 1 SwMI 2 PSS1Setup PSS1 Call Proceeding PSS1 Alerting PSS1 Connect PSS1 Connect Acknowledge PSS1 Facility PSS1 Facility PSS1 Facility PSS1 Facility PSS1 Disconnect PSS1 Release PSS1 Release Complete Notes Figure 1: PSS1 Call set-up 1) The PSS1 Call Proceeding and PSS1 Connect Acknowledge PDUs do not carry ISI PDUs. 2) The PSS1 Alerting PDU is not used during the set-up of an ISI group call. 3) The ISI call cannot be connected before the PSS1 call is connected. 4) After PSS1 call connection, PSS1 Facility PDUs are used to carry further signalling for the ISI call (e.g. call maintenance signalling). There is no set ordering or direction of travel for PSS1 Facility PDU. 5) For an individual call only, PSS1 Facility messages can be used prior to the PSS1 Connect. 6) The PSS1 Disconnect may be in either direction resulting in a change of direction for the PSS1 Release and PSS1 Release Complete PDUs. 7) The PSS1 call may be disconnected any time after the PSS1 Call Proceeding has been sent. 8) If a disconnecting SwMI is clearing the call in the disconnecting SwMI then it must instruct the PSS1 software to send the ISI-Disconnect PDU in a PSS1-Disconnect PDU. Otherwise, it must instruct the PSS1 software to send the ISI-Disconnect PDU in a PSS1-Facility PDU. 9) The PSS1 software must indicate the type of PSS1 PDU in which an ISI PDU was received. This enables the CSwMI to distinguish between an ISI-Disconnect PDU received when the sending SwMI has not already initiated local clearing of the call and an ISI-Disconnect PDU received when the sending SwMI has already initiated local clearing of the call. 10) It is possible to respond to a PSS1 Setup with a PSS1 Release Complete to clear the PSS1 call. 11) The Originating SwMI, or PSS1 calls initiated by the CSwMI (to PSwMIs), may release a PSS1 call before receiving a PSS1 Call Proceeding with a PSS1 Release (to which the called SwMI responds with a PSS1 Release Complete).

19 December 2003 Page 19 12) The ISI-Release PDU is sometimes sent in a PSS1 Release PDU. This occurs when the CSwMI receives an ISI-Disconnect PDU in a PSS1 Disconnect PDU. Since the PSS1 Release does not have end to end significance, there is a high probability that any ISI PDU sent in a PSS1 Release will not arrive at the destination SwMI. However, since the call is disconnecting when the ISI-Release is sent, and no useful information is carried in the PDU (the disconnect cause comes from the receiving SwMI) the probable loss of the ISI-Release PDU, in these circumstances, is considered acceptable. 6.4 Signalling Diagrams The definition of the ANF-ISIGC for phase 2 (see TF for ISI user requirement phases) is based on adherence to the following diagrams. The diagrams are separated into three distinct sections. Those for call setup, for maintenance and for call termination Call Setup The following sections give examples of call set-up scenarios for some of the possible call acceptance and call connection modes. The examples, deliberately, ignore the case of parties being at the CSwMI. This is because the reason for these diagrams is to demonstrate the ISI signalling Single calling party, no queuing for resources CSwMI connects on any strategy The CSwMI waits for all responses to its ISI-Setup-Initiate before determining if the call can be connected. Originating SwMI Controlling SwMI Participating SwMI 1 Participating SwMI 2 U-Setup() D-Call-Proceeding() ISI-Originating Setup ISI-Setup-Acknowledge 1 ISI-Setup-Acknowledge ISI-Setup Acknowledge D-Connect() not call amalgamation transmission granted not call amalgamation transmission granted to another user not call amalgamation transmission granted to another user Figure 2: Successful Group Call Set-up. Single calling party, no queuing for resources

20 Page 20 December 2003 Notes 1) The CSwMI waits for all initial responses (ISI-Setup-Acknowledge or ISI-Delay) from all external SwMIs. It then performs an evaluation to determine if the call should be delayed (i.e. ISI-Release sent to ready SwMIs) or a partial call setup (i.e. send to ready SwMIs). In this case it has no (sensible!) option but to connect the call. 2) Since there is no queuing there is never any need to release resources due to the CSwMI being unable to connect the call. So it doesn t matter, in this case, if the CSwMI is capable of sending ISI- Release during call setup or not. 3) This is the normal and most common case.

21 December 2003 Page Single calling party, some queuing for resources CSwMI connects when the OSwMI is ready. The CSwMI waits for all responses to its ISI-Setup-Initiate before determining if the call can be connected. Originating SwMI Controlling SwMI Participating SwMI 1 Participating SwMI 2 U-Setup() D-Call-Proceeding() ISI-Originating Setup ISI-Delay ISI-Delay 1 ISI-Setup Acknowledge ISI-Release 2 delay group call setup ISI-Setup Acknowledge ISI-Setup-Acknowledge 3 ISI-Release delay group call setup ISI-Setup Acknowledge ISI-Delay 4 D-Connect() Not call amalgamation transmission gramted Not call amalgamation transmission granted to another user ISI-Info 5 ISI-Setup Acknowledge call connected Not call amalgamation transmission granted to another user Figure 3: Successful Group Call Set-up. Single calling party, some queuing for resources

22 Page 22 December 2003 Notes 1) CSwMI waits for all initial responses (ISI-Setup-Acknowledge or ISI-Delay) from all external SwMIs. It then performs an evaluation to determine if the call should be delayed (i.e. ISI-Release sent to ready SwMIs) or a partial call setup (i.e. send to ready SwMIs). In this case, since the CSwMI wants an OSwMI to be ready before it connects, but as it isn t, it decides to delay the call. 2) Any ISI-Setup-Acknowledge received after the CSwMI has delayed the call causes a new reevaluation of what the CSwMI should do. The alternatives are to continue to delay the call (send an ISI-Release to the newly ready SwMI) or attempt to get the call to setup (by initiating the call again to all delayed SwMIs). In the example since the OSwMI is still not ready the CSwMI decides to continue to delay the call. 3) The condition that the CSwMI is looking for is fulfilled when the ISI-Setup-Acknowledge comes in from the calling party. As in 2) a re-evaluation is performed but this time a decision is taken to try to reactivate the call. This is because the call can now be connected. To do this an ISI-Setup-Initiate is sent to all delayed SwMIs (those that have been sent ISI-Release) 4) When all of the responses to the ISI-Setup-Initiate have been received (ISI-Setup-Acknowledge or ISI-Delay) then another re-evaluation is performed. In this example, it can decide nothing other than to connect the call, so is sent to all SwMIs that are ready to connect. In the example one of the SwMIs is not ready to connect. It will be connected later when it sends in its ISI-Setup- Acknowledge. 5) If the delaying SwMIs strategy on sending in its ISI-Setup-Acknowledge is to wait for more than one of its called parties to be ready then there will be parties that are ready but have not been connected into the call. The PSwMI may take account of the ISI-Info(call connected) to return its ISI-Setup- Acknowledge when a party can be connected into the call, thus avoiding the problem. It is possible that the call has been connected without a calling party. This would be the case if the OSwMI had not based the sending in of its ISI-Setup-Acknowledge on the basis of its called party being ready (for example it could have sent it in based on any party (called or calling) being available, and it was a called party that was available). It is possible (but probably unlikely) that the call could have been connected with no called parties. This assumes that there are no ready called parties at the OSwMI and that the PSwMI did not wait for called parties to be ready before sending in its ISI-Setup-Acknowledge.

23 December 2003 Page Single calling party, some queuing for resources, different connect strategy to CSwMI connects when the OSwMI and a PSwMI is ready. The CSwMI waits for all responses to its ISI-Setup-Initiate before determining if the call can be connected. Originating SwMI Controlling SwMI Participating SwMI 2 Participating SwMI 2 U-Setup() D-Call-Proceeding() ISI-Originating Setup ISI-Delay ISI-Delay 1 ISI-Setup Acknowledge 2 ISI-Release delay group call setup ISI-Setup Acknowledge ISI-Setup-Acknowledge 3 ISI-Release delay group call setup ISI-Setup-Initiate ISI-Delay ISI-Delay 4 ISI-Release delay group call setup ISI-Setup Acknowledge 5 ISI-Setup Acknowledge ISI-Setup-Acknowledge 6 D-Connect() Not call amalgamation transmission granted Not call amalgamation Transmission granted to another user Not call amalgamation Transmission granted to another user Figure 4: Successful Group Call Set-up. Single calling party, some queuing for resources, different connect strategy to

24 Page 24 December 2003 Notes CSwMI waits for all initial responses (ISI-Setup-Acknowledge or ISI-Delay) from all external SwMIs. It then performs an evaluation to determine if the call should be delayed (i.e. ISI-Release sent to ready SwMIs) or a partial call setup (i.e. send to ready SwMIs). In this case since the CSwMI wants the OSwMI and a PSwMI to be ready before it connects, but only a PSwMI is ready, it decides to delay the call. 1) Any ISI-Setup-Acknowledge received after the CSwMI has delayed the call causes a new reevaluation of what the CSwMI should do. The alternatives are to continue to delay the call (send an ISI-Release to the newly ready SwMI) or attempt to get the call to setup (by initiating the call again to all delayed SwMIs). In the example part of the conditions the CSwMI needs have been fulfilled, a PSwMI is ready, however since the OSwMI is delaying the CSwMI decides to continue to delay the call. 2) As in 2) a re-evaluation is performed when an ISI-Setup-Acknowledge is received but the CSwMI is delaying the call. This time a decision is taken to try to reactivate the call, this is because the OSwMI is now available and if one of the delayed PSwMIs was still to be available then the call could be connected. To do this an ISI-Setup-Initiate is sent to all delayed SwMIs (those that have been sent ISI-Release) 3) When all of the responses from the SwMIs that have been sent the ISI-Setup-Initiate have been received (ISI-Setup-Acknowledge or ISI-Delay) then another re-evaluation is performed. In this example, both of the PSwMIs have indicated an ISI-Delay. The CSwMI has not met the conditions it needs to connect the call and so decides that the call should again be delayed. It sends ISI-Release to all SwMIs that are ready. In this case this is only the OSwMI. 4) The receipt of an ISI-Setup-Acknowledge while the call is being delayed causes a new re-evaluation by the CSwMI of what it should do next. The CSwMI still only has part of the condition satisfied that it needs to connect the call (it has only a PSwMI available). Since the OSwMI is currently being delayed by the CSwMI, the CSwMI now decides it must attempt to reactivate the call again. It sends an ISI-Setup-Initiate to all delayed SwMIs. In this case this is only the OSwMI. 5) The first ISI-Setup-Acknowledge to arrive is from the delaying PSwMI. This does not cause a reevaluation of what the CSwMI should do, since the CSwMI is looking for responses from all of the SwMIs to which it has just sent an ISI-Setup-Initiate. This is not one of them (however, the CSwMI must remember that this PSwMI is no longer delaying itself). The next ISI-Setup-Acknowledge is from the OSwMI. Since all of the responses that the CSwMI had been looking for have now come in a re-evaluation is performed. This determines that both an OSwMI and a PSwMI are now available for connection. Therefore, the call is connected.