GSM GSM 03.84 TECHNICAL December 1996 SPECIFICATION Version 5.0.0 Source: ETSI TC-SMG Reference: TS/SMG-030384Q ICS: 33.020 Key words: Digital cellular telecommunications system, Global System for Mobile communications (GSM) GLOBAL SYSTEM FOR MOBILE COMMUNICATIONS R Digital cellular telecommunications system; Multi Party () supplementary services - Stage 2 (GSM 03.84) ETSI European Telecommunications Stards Institute ETSI Secretariat Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.fr Tel.: +33 4 92 94 42 00 - Fax: +33 4 93 65 47 16 Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright the foregoing restriction extend to reproduction in all media. European Telecommunications Stards Institute 1996. All rights reserved.
Page 2 Whilst every care has been taken in the preparation publication of this document, errors in content, typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to "ETSI Editing Committee Support Dept." at the address shown on the title page.
Page 3 Contents Foreword...5 0 Scope...7 0.1 Normative references...7 0.2 Abbreviations...7 1 Multi Party service ()...7 1.1 Functions information flows...7 1.2 Information stored in the HLR...24 1.3 State transition model...24 1.4 Transfer of information from HLR to VLR...24 1.5 Information stored in the VLR...24 1.6 Hover...24 1.7 Simultaneous use of Multi Party operations...24 History...25
Page 4 Blank page
Page 5 Foreword This Global System for Mobile communications Technical Specification (GTS) has been produced by the Special Mobile Group (SMG) Technical Committee (TC) of the European Telecommunications Stards Institute (ETSI). This GTS defines the stage 2 of the Multi Party () supplementary services within the digital cellular telecommunications system. The contents of this GTS are subject to continuing work within TC-SMG may change following formal TC-SMG approval. Should TC-SMG modify the contents of this GTS it will then be republished by ETSI with an identifying change of release date an increase in version number as follows: Version 5.x.y where: y x the third digit is incremented when editorial only changes have been incorporated in the specification; the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, updates, etc. The specification from which this GTS has been derived was originally based on CEPT documentation, hence the presentation of this GTS may not be entirely in accordance with the ETSI/PNE rules.
Page 6 Blank page
Page 7 0 Scope This Global System for Mobile communications Technical Specification (GTS) gives the stage 2 description of the multi party supplementary services. Only one multi party supplementary service has been defined, this is the Multi Party () service, is described in clause 1. 0.1 Normative references This GTS incorporates by dated undated reference, provisions from other publications. These normative references are cited at the appropriate places in the text the publications are listed hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply to this GTS only when incorporated in it by amendment or revision. For undated references, the latest edition of the publication referred to applies. [1] GSM 01.04 (ETR 350): "Digital cellular telecommunications system (Phase 2+); Abbreviations acronyms". [2] GSM 03.11 (ETS 300 928): "Digital cellular telecommunications system; Technical realization of supplementary services". [3] GSM 03.83: "Digital cellular telecommunications system; Call Waiting (CW) Call Hold (HOLD) supplementary services - Stage 2". 0.2 Abbreviations Abbreviations used in this GTS are listed in GSM 01.04. 1 Multi Party service () 1.1 Functions information flows The following Mobile Additional Function has been identified for Multi Party service: MAF026 Multi Party service related authorizations examination The ability of a PLMN component to determine the authorizations relating to Multi Party service (see figure 2.1). Location: VLR The overall SDL-diagram of Multi Party service is shown in figure 1.2. This overall SDL-diagram represents the network as a whole. The overall SDL-diagram shows the status of the service as perceived by the served mobile subscriber, as well as the status as perceived by any of the other parties. Beside this, the overall SDL-diagram shows the actions to be taken by the network the information provided by the network to the users. Within the authorization examinations diagram, the messages shown to from the left are to from the VLR. Within the overall SDL diagram, messages to from the served mobile subscriber are indicated to from the left, whereas messages to from remote parties are indicated to from the right. The information flow for Multi Party service is shown in figure 1.3.
Page 8 In the information flow it is assumed that the served subscriber is a mobile subscriber that the other parties are all fixed ISDN subscribers. For the purposes of the information flow diagrams it is assumed that there are only two remote parties. Where there are more than two remote parties, signals to any party connected to the bridge shall apply to all other parties connected to the bridge, except where a single remote party is to be selected for a private communication. As a consequence of this assumption, after the is split (to establish a private communication) it only contains one remote party. However, the end state for ion of or by that remaining remote party is shown as A-B ACTIVE / HELD. This is to indicate that the ion by a single remote party will not necessarily cause the to be released. This will only happen when that remote party is the only remaining party in the. Party A is the subscriber controlling the (serviced mobile subscriber). Party B is the first remote party ed. Party C is the second remote party ed. Remote parties are ed by the generic /release procedure. Any scenario requiring ion of remote parties shown in the SDL diagrams but not explicitly shown in the flow diagrams shall follow the procedure shown in the flow diagrams for similar scenarios. Functions to be performed by the fixed ISDN (for example authorizations examination) are not shown in the information flow; only the functions to be performed by the PLMN are shown. It is assumed that the Multi Party bridge is located in the MSC. In the SDL-diagrams a two dimensional state in conjunction with is used: (active, request). - The first dimension is a normal basic state "active". - The second dimension is " request" (abbreviated req) meaning that a request has been made for the function. To avoid having two s on at the same time the reception of the request is supervised by timer T as defined in GSM 03.83. Note that while the Multi Party is on, the remote parties can continue to communicate with each other.
Page 9 Process _MAF026 384_11(1) Figure 1.1 idle initiate hling of provisioned no yes process idle : Multi Party service. Figure 1.1: MAF026 Multi Party service related authorizations examination (VLR)
Page 10 Process _overall 384_121(7) Figure 1.2 (sheet 1 of 7) held active P1 Multi Party request P1: Call procedure (see GSM 03.83). no conditions met yes Applicability check in MSC (see GSM 02.84). request accepted yes no connect A, B C (to B) Multi Party (to B) Multi Party (to C) Multi Party reject Multi party acknowledge held active Figure 1.2 (sheet 1 of 7): Overall SDL diagram of Multi Party service
Page 11 Process _overall 384_122(7) Figure 1.2 (sheet 2 of 7) one party (e.g. C) private communication (e.g. F) (e.g. C) C make F active C ed (to all parties except F) (to all remote parties) any remaining remote party no private communication acknowledge acknowledge yes idle held active held active Figure 1.2 (sheet 2 of 7): Overall SDL diagram of Multi Party service
Page 12 Process _overall 384_123(7) Figure 1.2 (sheet 3 of 7) held (NOTE) one party (e.g. C) (e.g. C) C held C ed (to remote parties) no any remaining held party acknowledge yes idle held held NOTE: It is also possible to initiate a new or process a waiting request from this state (see GSM 03.83). In either case, this is likely to result in a held active. Figure 1.2 (sheet 3 of 7): Overall SDL diagram of Multi Party service
Page 13 Process _overall 384_124(7) Figure 1.2 (sheet 4 of 7) held active active party (e.g. F) from held party (e.g. C) held party (e.g. C) add party (e.g. F) active from active (e.g. F) no another party permitted start T yes F C connect F to held (active, req) F ed C ed (to remote parties except F) no any remaining held party (to remote parties) yes add party reject add acknowledge active (no ) held held active held active held active Figure 1.2 (sheet 4 of 7): Overall SDL diagram of Multi Party service
Page 14 Process _overall 384_125(7) Figure 1.2 (sheet 5 of 7) held (active, req) request for reqest for single single (from single ) in from in stop T stop T T expires reject (single ) to single no any remaining party in acknowledge (single ) reject reject (single ) yes single ed ed ed (to remote parties in ) reject reject (single ) stop T stop T acknowledge held held active held active held active (no ) held (active, req) Figure 1.2 (sheet 5 of 7): Overall SDL diagram of Multi Party service
Page 15 Process _overall 384_126(7) Figure 1.2 (sheet 6 of 7) held held (e.g. F) from active party (e.g. C) add party (e.g. F) active private communication from held (e.g. F) active party (e.g. C) private communication reject Indication is sent to the served mobile subscriber. F C no another party permitted yes start T held F ed C ed connect F to held (active, req) no any remaining active party (to F) yes add party reject (to remote parties) held (no ) held add acknowledge held held Figure 1.2 (sheet 6 of 7): Overall SDL diagram of Multi Party service
Page 16 Process _overall 384_127(7) Figure 1.2 (sheet 7 of 7) held (active, req) request for single request for single (from single ) in from in T expires stop T stop T any remaining party in yes no to all remote parties reject () reject () reject () reject () acknowledge ( ) single single ed ed ed (to single ) reject () stop T stop T acknowledge active held held held held (no ) held (active, req) Figure 1.2 (sheet 7 of 7): Overall SDL diagram of Multi Party service
Page 17 06D06&D9/5D+/5D/(E7(E/(F7(F ¹ ¹ ¹ ¹ ¹ ¹ ¹ ¹ $%+(/'$&$&7,9( 6XEVFULEHU$ZDQWVWRLQLWLDWHDPXOWLSDUW\FRQYHUVDWLRQ EXLOG037< ¼! UHTXHVW LQIRUHT ¼! 0$) ½ LQIRDFN 25 EXLOG037< 1 ½ UHMHFW $%+(/'$&$&7,9( 25 < FRQQHFW EULGJH QRWLILFDWLRQ ¼ À À À À! QRWLILFDWLRQ UHWULHYDO ¼! UHWULHYDO QRWLILFDWLRQ ¼ À À À À! QRWLILFDWLRQ PXOWLSDUW\ ¼! PXOWLSDUW\ QRWLILFDWLRQ EXLOG037< ¼ À À À À À À À À! QRWLILFDWLRQ ½ PXOWLSDUW\ ¼! DFNQRZOHGJH PXOWLSDUW\ $&7,9(08/7,3$57<&219(56$7,21 $&7,9(08/7,3$57<&219(56$7,21 6XEVFULEHU$ZDQWVWRWHUPLQDWHWKHPXOWLSDUW\FDOO GLVFRQQHFW! % GLVFRQQHFW ¼ À À À À! GLVFRQQHFW GLVFRQQHFW ¼!! & UHOHDVH UHOHDVHFRQILUPDWLRQ ½ À À À À ½ UHOHDVH% GLVFRQQHFW ¼ À À À À À À À À! GLVFRQQHFW ¼! UHOHDVH UHOHDVHFRQILUPDWLRQ ½ UHOHDVH& À À À À À À À À ½ ½,'/( OR1: Multi party acceptable Y: Yes N: No Figure 1.3 (sheet 1 of 7): Information flow for Multi Party service
Page 18 06D06&D9/5D+/5D/(E7(E/(F7(F ¹ ¹ ¹ ¹ ¹ ¹ ¹ ¹ $&7,9(08/7,3$57<&219(56$7,21 6XEVFULEHU$ZDQWVWRGLVFRQQHFWRQHUHPRWHSDUW\HJ& GLVFRQQHFW ¼! GLVFRQQHFW ¼ À À À À À À À À! GLVFRQQHFW! UHOHDVH UHOHDVHFRQILUPDWLRQ ½ UHOHDVH À À À À À À À À ½ ½ $&7,9(08/7,3$57<&219(56$7,21 $&7,9(08/7,3$57<&219(56$7,21 2QHUHPRWHSDUW\HJ&ZDQWVWRGLVFRQQHFW GLVFRQQHFW GLVFRQQHFW ½ À À À À À À À À ½ GLVFRQQHFW ½ UHOHDVH ¼! UHOHDVHFRQILUPDWLRQ ¼ À À À À À À À À! UHOHDVH ¼! $&7,9(08/7,3$57<&219(56$7,21 $&7,9(08/7,3$57<&219(56$7,21 2QHUHPRWHSDUW\HJ%ZDQWVWRKROG KROG QRWLILFDWLRQ ½ QRWLILFDWLRQ À À À À ½ UHTXHVW ½ KROG KROG KROG ¼! FRQILUPDWLRQ $&7,9(08/7,3$57<&219(56$7,21 $&7,9(08/7,3$57<&219(56$7,21 2QHUHPRWHSDUW\HJ%ZDQWVWRUHWULHYHWKHKHOGFDOO UHWULHYH QRWLILFDWLRQ ½ QRWLILFDWLRQ À À À À ½ UHTXHVW ½ UHWULHYDO UHWULHYDO UHWULHYH ¼! FRQILUPDWLRQ $&7,9(08/7,3$57<&219(56$7,21 Figure 1.3 (sheet 2 of 7): Information flow for Multi Party service
Page 19 06D06&D9/5D+/5D/(E7(E/(F7(F ¹ ¹ ¹ ¹ ¹ ¹ ¹ ¹ $&7,9(08/7,3$57<&219(56$7,21 6XEVFULEHU$ZDQWVWRKROGHQWLUHPXOWLSDUW\FRQYHUVDWLRQ KROGUHTXHVW ¼! KROG KROG EULGJH ½ QRWLILFDWLRQ FRQILUPDWLRQ¼ À À À À! QRWLILFDWLRQ KROG ¼! KROG QRWLILFDWLRQ ¼ À À À À À À À À! QRWLILFDWLRQ KROG ¼! KROG +(/'08/7,3$57<&219(56$7,21 +(/'08/7,3$57<&219(56$7,21 6XEVFULEHU$ZDQWVWRUHWULHYHWKHKHOGPXOWLSDUW\FRQYHUVDWLRQ UHWULHYH ¼! UHTXHVW UHWULHYH EULGJH QRWLILFDWLRQ ¼ À À À À! QRWLILFDWLRQ UHWULHYDO ¼! UHWULHYDO QRWLILFDWLRQ UHWULHYH ¼ À À À À À À À À! ½ UHWULHYDO QRWLILFDWLRQ FRQILUPDWLRQ ¼! UHWULHYDO $&7,9(08/7,3$57<&219(56$7,21 $&7,9(08/7,3$57<&219(56$7,21 6XEVFULEHU$ZDQWVWRHVWDEOLVKDSULYDWHFRPPXQLFDWLRQZLWKRQHSDUW\HJ% 3ULY&RPP ¼! UHTXHVW KROG EULGJH 3ULY&RPP ½ FRQILUPDWLRQ QRWLILFDWLRQ ¼ À À À À À À À À! QRWLILFDWLRQ KROG ¼! KROG $%$&7,9(037<+(/' Figure 1.3 (sheet 3 of 7): Information flow for Multi Party service
Page 20 06D06&D9/5D+/5D/(E7(E/(F7(F ¹ ¹ ¹ ¹ ¹ ¹ ¹ ¹ +(/'08/7,3$57<&219(56$7,21 6XEVFULEHU$ZDQWVWRGLVFRQQHFWHQWLUHPXOWLSDUW\FRQYHUVDWLRQ GLVFRQQHFW! % GLVFRQQHFW ¼ À À À À! GLVFRQQHFW GLVFRQQHFW ¼!! UHOHDVH & UHOHDVHFRQILUPDWLRQ ½ À À À À ½ UHOHDVH% GLVFRQQHFW ¼ À À À À À À À À! GLVFRQQHFW ¼! UHOHDVH UHOHDVHFRQILUPDWLRQ ½ À À À À À À À À ½ UHOHDVH UHOHDVH& EULGJH ½,'/( +(/'08/7,3$57<&219(56$7,21 2QHUHPRWHSDUW\HJ%ZDQWVWRGLVFRQQHFW GLVFRQQHFW GLVFRQQHFW ½ GLVFRQQHFW À À À À ½ ½ UHOHDVH ¼! UHOHDVHFRQILUPDWLRQ ¼ À À À À! UHOHDVH ¼! +(/'08/7,3$57<&219(56$7,21 +(/'08/7,3$57<&219(56$7,21 2QHUHPRWHSDUW\HJ%ZDQWVWRKROG KROGUHTXHVW QRWLILFDWLRQ ½ QRWLILFDWLRQ À À À À ½ ½ KROG KROGFRQILUPDWLRQ KROG ¼! +(/'08/7,3$57<&219(56$7,21 Figure 1.3 (sheet 4 of 7): Information flow for Multi Party service
Page 21 06D06&D9/5D+/5D/(E7(E/(F7(F ¹ ¹ ¹ ¹ ¹ ¹ ¹ ¹ +(/'08/7,3$57<&219(56$7,21 2QHUHPRWHSDUW\HJ%ZDQWVWRUHWULHYHWKHKHOGFDOO UHWULHYHUHTXHVW QRWLILFDWLRQ ½ QRWLILFDWLRQ À À À À ½ ½ UHWULHYDO UHWULHYH UHWULHYDO ¼! FRQILUPDWLRQ +(/'08/7,3$57<&219(56$7,21 $%$&7,9(037<+(/' 6XEVFULEHU$ZDQWVWRWHUPLQDWHWKHPXOWLSDUW\FDOO GLVFRQQHFW ¼! GLVFRQQHFW ¼ À À À À À À À À! GLVFRQQHFW ¼! UHOHDVH UHOHDVHFRQILUPDWLRQ ½ À À À À À À À À ½ UHOHDVH UHOHDVH ½EULGJH $%$&7,9( $%$&7,9(037<+(/' 2QHUHPRWHSDUW\HJ&ZDQWVWRGLVFRQQHFW GLVFRQQHFW GLVFRQQHFW ½ GLVFRQQHFW À À À À À À À À ½ ½ UHOHDVH ¼! UHOHDVHFRQILUPDWLRQ ¼ À À À À À À À À! UHOHDVH ¼! $%$&7,9(037<+(/' $%$&7,9(037<+(/' $FWLYHUHPRWHSDUW\%ZDQWVWRGLVFRQQHFW GLVFRQQHFW GLVFRQQHFW ½ GLVFRQQHFW À À À À ½ ½ UHOHDVH ¼! UHOHDVHFRQILUPDWLRQ ¼ À À À À! UHOHDVH ¼! +(/'037< Figure 1.3 (sheet 5 of 7): Information flow for Multi Party service
Page 22 06D06&D9/5D+/5D/(E7(E/(F7(F ¹ ¹ ¹ ¹ ¹ ¹ ¹ ¹ $%$&7,9(037<+(/' 6XEVFULEHU$ZDQWVWRDGGDFWLYHFDOO$%WRPXOWLSDUW\FDOO EXLOG037< ¼! UHTXHVW 25 EXLOG037< 1 ½ UHMHFW $%$&7,9(037<+(/' 25 < QRWLILFDWLRQ ¼ À À À À! QRWLILFDWLRQ PXOWLSDUW\ ¼! PXOWLSDUW\ QRWLILFDWLRQ ¼ À À À À À À À À! QRWLILFDWLRQ UHWULHYHG ¼! UHWULHYHG QRWLILFDWLRQ EXLOG037< ¼ À À À À À À À À! QRWLILFDWLRQ ½ PXOWLSDUW\ ¼! DFNQRZOHGJH PXOWLSDUW\ $&7,9(08/7,3$57<&219(56$7,21 OR2: Extra remote party allowed within maximum number? Y: Yes N: No Figure 1.3 (sheet 6 of 7): Information flow for Multi Party service
Page 23 06D06&D9/5D+/5D/(E7(E/(F7(F ¹ ¹ ¹ ¹ ¹ ¹ ¹ ¹ $%$&7,9(037<+(/' 2QHUHPRWHSDUW\HJ%ZDQWVWRKROG KROGUHTXHVW QRWLILFDWLRQ ½ QRWLILFDWLRQ À À À À ½ ½ KROG KROGFRQILUPDWLRQ KROG ¼! $%$&7,9(037<+(/' $%$&7,9(037<+(/' 2QHUHPRWHSDUW\HJ%ZDQWVWRUHWULHYHWKHKHOGFDOO UHWULHYHUHTXHVW QRWLILFDWLRQ ½ QRWLILFDWLRQ À À À À ½ ½ UHWULHYDO UHWULHYH UHWULHYDO ¼! FRQILUPDWLRQ $%$&7,9(037<+(/' $%$&7,9(037<+(/' 6HUYHGPRELOHVXEVFULEHUZLVKHVWRDOWHUQDWHEHWZHHQDFWLYHFDOODQGKHOG037< KROGUHTXHVW ¼! IRU% VWDUW 7 $%$&7,9(+2/'5(4037<+(/' UHWULHYHUHT ¼! VWRS QRWLILFDWLRQ IRU037< 7 À À À À! QRWLILFDWLRQ KROG! KROG QRWLILFDWLRQ À À À À À À À À! QRWLILFDWLRQ UHWULHYDO! UHWULHYDO 037<$&7,9($%+(/' Figure 1.3 (sheet 7 of 7): Information flow for Multi Party service
Page 24 1.2 Information stored in the HLR The following logical states are applicable for (refer to GSM 03.11 for an explanation of the notation): Provisioning State Registration State Activation State HLR Induction State (Not Provisioned, Not Applicable, Not Active, Not Induced) (Provisioned, Not Applicable, Active Operative, Not Induced) The HLR shall store the logical state of (which shall be one of the valid states listed above) on a per subscriber basis. 1.3 State transition model The following figure shows the successful cases of transition between the applicable logical states of. The state changes are caused by actions of the service provider. Note that error cases are not shown in the diagram as they normally do not cause a state change. Additionally, some successful requests may not cause a state change. Hence they are not shown in the diagram. Provision (Not Provisioned, Not Applicable, Not Active, Not Induced) (Provisioned, Not Applicable, Active Operative, Not Induced) Withdrawal Figure 1.4: State transition model for 1.4 Transfer of information from HLR to VLR If the provisioning state for is "Provisioned" then, when the subscriber registers on a VLR, the HLR shall send that VLR information about the logical state of. If the logical state of is changed while a subscriber is registered on a VLR then the HLR shall inform the VLR of the new logical state of. 1.5 Information stored in the VLR For the VLR shall store the service state information received from the HLR. 1.6 Hover Hover will have no impact on the control procedures the operation of the service. 1.7 Simultaneous use of Multi Party operations The operations Build, Split, Hold Retrieve interact with each other, cannot be applied simultaneously. Once the mobile station has initiated one of these operations, it shall not initiate another Multi Party operation until the first operation has been acknowledged by the network, or the MS loy determines (due to timer expiry) that the first operation has failed.
Page 25 History Document history December 1996 Publication of GSM 03.84 version 5.0.0 ISBN 2-7437-1201-5 Dépôt légal : Décembre 1996