3GPP TS 23.091

Download as pdf or txt
Download as pdf or txt
You are on page 1of 21

3GPP TS 23.091 V7.0.

0 (2007-06)
Technical Specification

3rd Generation Partnership Project; Technical Specification Group Core Network; Explicit Call Transfer (ECT) supplementary service - Stage 2 (Release 7)

GLOBAL SYSTEM FOR MOBILE COMMUNICATIONS

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organisational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organisational Partners' Publications Offices.

Release 7

3GPP TS 23.091 V7.0.0 (2007-06)

Keywords
GSM, UMTS, supplementary serivce, ECT, stage 2

3GPP Postal address

3GPP support office address


650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet
http://www.3gpp.org

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.
2007, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC). All rights reserved.

3GPP

Release 7

3GPP TS 23.091 V7.0.0 (2007-06)

Contents
Foreword ............................................................................................................................................................4 1 2 3
3.1 3.2

Scope ........................................................................................................................................................5 References ................................................................................................................................................5 Definitions and abbreviations...................................................................................................................5


Definitions............................................................................................................................................................... 5 Abbreviations .......................................................................................................................................................... 6

Explicit Call Transfer (ECT)....................................................................................................................6

4.1 Functions ................................................................................................................................................................. 6 4.2 SDL diagrams and information flows ..................................................................................................................... 8 4.2.1 General description ............................................................................................................................................ 8 4.2.2 ECT (both calls answered)................................................................................................................................. 8 4.2.3 ECT (one call answered, the other alerting) .................................................................................................... 11 4.3 Interaction with other supplementary services ...................................................................................................... 14 4.3.1 Line Identification services.............................................................................................................................. 14 4.3.2 Call Forwarding Unconditional (CFU) ............................................................................................................ 16 4.3.3 Call Forwarding on mobile subscriber Busy (CFB) ........................................................................................ 17 4.3.3.1 Call Forwarding on mobile subscriber Busy due to Network Determined User Busy (NDUB)...................... 17 4.3.3.2 Call Forwarding on mobile subscriber Busy due to User Determined User Busy (UDUB) ............................ 17 4.3.4 Call Forwarding on No Reply (CFNRy).......................................................................................................... 18 4.3.5 Call Forwarding on mobile subscriber Not Reachable (CFNRc)..................................................................... 18 4.3.6 Call Waiting (CW)........................................................................................................................................... 18 4.3.7 Call Hold (HOLD) ........................................................................................................................................... 18 4.3.8 Multi Party (MPTY) ........................................................................................................................................ 18 4.3.9 Closed User Group (CUG)............................................................................................................................... 18 4.3.10 Advice of Charge (AoC) services .................................................................................................................... 19 4.3.11 Call Barring services........................................................................................................................................ 19 4.3.12 Explicit Call Transfer (ECT) ........................................................................................................................... 19 4.4 Information stored in the HLR .............................................................................................................................. 19 4.5 State transition model ............................................................................................................................................ 19 4.6 Transfer of information from the HLR to the VLR ............................................................................................... 20 4.7 Information stored in the VLR .............................................................................................................................. 20 4.8 Handover ............................................................................................................................................................... 20

Annex A:

Change history ......................................................................................................................21

3GPP

Release 7

3GPP TS 23.091 V7.0.0 (2007-06)

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document.

3GPP

Release 7

3GPP TS 23.091 V7.0.0 (2007-06)

Scope

The present document gives the stage 2 description of the call transfer supplementary services. Only one call transfer supplementary service has been defined, this is the Explicit Call Transfer (ECT) supplementary service, and is described in the present document.

References
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] [2] [3] [4] [5] 3GPP TR 21.905: "3G Vocabulary". 3GPP TS 23.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 2". 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols - Stage 3". EN 300 368: "Integrated Services Digital network (ISDN); Explicit Call Transfer (ECT) supplementary service; Functional capabilities and information flows". EN 300 356-14: "Integrated Services Digital network (ISDN); Signalling System No. 7; ISDN User Part (ISUP) version 3 for the international interface; Part 14: Explicit Call Transfer (ECT) supplementary service ". 3GPP TS 23.011: Technical realization of Supplementary Services. 3GPP TS 23.018: Basic Call Handling.

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

[6] [7]

3
3.1

Definitions and abbreviations


Definitions

First call: One of the subscriber A calls (answered). Notification Indicator (NI): Indicates to each remote party in which state of the other remote party ECT was performed (active, alerting). Redirection Number (Rdn): Includes the presentation indicator and the directory number of the other remote party. Second call: The other subscriber A call (answered or alerting). Subscriber A (PARTY A): The served mobile subscriber - the one who has subscribed to, and invokes the ECT Supplementary Service. Subscriber B (PARTY B): The other party in the subscriber A first call. Subscriber C (PARTY C): The other party in the subscriber A second call. Subscriber D (PARTY D): The forwarded-to party when the call is forwarded by the subscriber C.

3GPP

Release 7

3GPP TS 23.091 V7.0.0 (2007-06)

Transferred call: The resulting call after successful explicit call transfer between B and C.

3.2
ECT: LI: NI: Rdn: RdnB: RdnD:

Abbreviations
Explicit Call Transfer supplementary service Line Identity Notification Indicator Redirection number Redirection number of party B Redirection number of party D

In addition to those below, abbreviations used in the present document are listed in 3GPP TR 21.905 [1].

4
4.1
MAF027

Explicit Call Transfer (ECT)


Functions

The following function has been identified for the explicit call transfer service:

Explicit Call Transfer related authorizations examination The ability of a PLMN component to determine the authorizations relating to explicit call transfer. See figure 1. Location: VLR

3GPP

Release 7

3GPP TS 23.091 V7.0.0 (2007-06)

Process MAF027
Process in the VLR to check if ECT is provisioned.

391_1(1)
Signals to/from the left are to/from the MSC.

Idle

Check ECT subscription

ECT provisioned Yes

No

No

SS-CSI provisioned? Yes

No

ECT marked in CSI? Yes

Indicator:= ECT_available

Indicator:= ECT_available + SS-CSI

Indicator:= ECT_not_ available

Process ECT

Idle

Figure 1: Explicit Call Transfer related authorizations examination (VLR)

3GPP

Release 7

3GPP TS 23.091 V7.0.0 (2007-06)

4.2
4.2.1

SDL diagrams and information flows


General description

The procedures Handle_ECT_Active and Handle_ECT_Alerting show the behaviour of the service as perceived by the served mobile subscriber and by any of the other parties involved in the transfer. These procedures and the macro Check_ECT show the actions to be taken by the network and the information provided by the network to the users.

The following states for the invocation of the ECT supplementary service are defined: a) First Call (Active, Held), Second Call (Active, Idle); b) First Call (Active, Held), Second Call (Call Delivered, Idle). NOTE: The call state "call delivered" means that an ALERTING message has been sent to the MS, but no ANSWER Message (ANM) has been received.

In the information flows it is assumed that the served subscriber is a mobile subscriber and that the other parties are mobile or fixed subscribers. Party A is the subscriber controlling the Explicit Call Transfer Call (served mobile subscriber). Party B is the first remote party called. Party C is the second remote party called. The served party is disconnected by the generic disconnect/release procedure after a successful transfer request. The connection of the remote parties in a new call (transferred call) is located in the served subscribers MSC. The information flows in figures 4 and 7 show the unsuccessful case (i.e. the check in the VLR or in the MSC fails). The information flows in figures 5 and 8 show the successful case.

4.2.2

ECT (both calls answered)

The SDL for the procedure Handle_ECT_Active (Explicit Call Transfer - both calls have been answered) is shown in figure 2. The checks of whether Explicit Call Transfer is barred or not are shown in figure 3. The corresponding information flows are given in figure 4 and figure 5.

3GPP

Release 7

3GPP TS 23.091 V7.0.0 (2007-06)

Procedure Handle_ECT_Active
Procedure in the originating MSC to handle an Explicit Call Transfer when the first call leg (A-B) is connected and on hold and the other call leg (A-C) is connected and active.

ECT_Ac(1)
Signals to/from the left are to/from the MS; signals to/from the right are to/from all/any remote parties unless stated otherwise.

Check_ECT Pass Fail

Connect both calls

ECT reject

To the held party

Retrieve notification

Result:=Fail

Transfer notification

ECT ack

SS-CSI present? No

Yes

SS Invocation notify

To gsmSCF

For call legs A-B & A-C

Disconnect request

Result:=Pass

Figure 2: Procedure Handle_ECT_Active

3GPP

Release 7

10

3GPP TS 23.091 V7.0.0 (2007-06)

Macrodefinition Check_E CT
Macro in the originating MSC to chec k if an Explicit Call Transfer can be performed.

1(1)

ECT Treatment Indicator present in SII2 (for either ongoing call)?

No Yes ECT Treatment Indic ator set to Reject ECT request (for either ongoing call)? No

Yes

Check ECT subscription Wait_For_ ECT_Status_ Reply Process ECT Int_Release_ Call Release Release transaction

From gsmSSF No ECT activ e? Yes Yes

From distant exchange

From BSS

Transfer barred by SS interaction? No Loop Prev ention procedure No

Yes Loop check? Failure Fail

Success Pass

Figure 3: Macro Check_ECT

3GPP

Release 7
MSa MSCa VLRa A-B (active, held) / A-C (active, idle) ECT request > info request > MAF027 info ack < OR1:N ECT rej < A-B (active, held) / A-C (active, idle)

11
MSCb MSb

3GPP TS 23.091 V7.0.0 (2007-06)


LEc TEc

NOTE:

OR1: Checks in VLR and MSC ok? (Y: yes N: no).

Figure 4: Information flow for failed explicit call transfer request (both calls answered)
MSa MSCa VLRa MSCb MSb A-B (active, held) / A-C (active, idle) ECT request > info request > MAF027 info ack < OR1:Y connect calls notification (retrieve) > notification (retr) > notification (ECT) > notification (ECT) (active, Rdn) > (active, Rdn) notification (ECT) > (active, Rdn) ECT ack < disc req A-B < NORMAL DISCONNECTION A-B disc req A-C < NORMAL DISCONNECTION A-C B-C (active, idle) LEc TEc notification(ECT) > (active, Rdn)

NOTE:

OR1: Checks in VLR and MSC ok? (Y: yes N: no).

Figure 5: Information flow for successful explicit call transfer (both calls answered)

4.2.3

ECT (one call answered, the other alerting)

The SDL for the procedure Handle_ECT_Alerting (Explicit Call Transfer - one call answered, the other alerting) is shown in figure 6. The checks of whether Explicit Call Transfer is barred or not are shown in figure 3.

3GPP

Release 7

12

3GPP TS 23.091 V7.0.0 (2007-06)

The corresponding information flows are given in figure 7 and figure 8.

Procedure Handle_ECT_Alerting
Procedure in the originating MSC to handle an Explicit Call Transfer when the first call leg (A-B) is connected and on hold and the other call leg (A-C) is connected and alerting.

ECT_Al(1)
Signals to/from the left are to/from the MS; signals to/from the right are to/from all/any remote parties unless stated otherwise. False Alerting True

Check_ECT Pass Fail

Connect both calls

ECT reject

Retrieve notification

To the held party

Result:=Fail

ECT notification

ECT ack

SS-CSI present? No

Yes

SS Invocation notify

To gsmSCF

Disconnect request

For call legs A-B & A-C

Result:=Pass

Figure 6: Procedure Handle_ECT_Alerting

3GPP

Release 7

13
MSb

3GPP TS 23.091 V7.0.0 (2007-06)


LEc TEc

MSa MSCa VLRa MSCb A-B (active, held) / A-C (call delivered, idle) ECT request > info request > MAF027 info ack < OR1:N ECT rej < A-B (active, held) / A-C (call delivered, idle)

NOTE:

OR1: Checks in VLR and MSC ok? (Y: yes N: no). Figure 7: Information flow for failed explicit call transfer request (one call answered, the other alerting)

3GPP

Release 7

14

3GPP TS 23.091 V7.0.0 (2007-06)


LEc TEc notification(ECT) > (active, Rdn) CONNECT < CONNECT ACK >

MSa MSCa VLRa MSCb MSb A-B (active, held) / A-C (call delivered, idle) ECT request > info request > MAF027 info ack < OR1:Y connect calls notification (retrieve) > notification (retr) > notification (ECT) > notification (ECT) (alerting) > (alerting) notification (ECT) > ECT ack (active, Rdn) < disc req A-B < disc req A-C < A idle, B hears C ringing ANSWER < notification (ECT) > notification (ECT) (active, Rdn) > (active, Rdn) B-C active, idle

NOTE:

OR1: Checks in VLR and MSC ok? (Y: yes N: no). Figure 8: Information flow for successful explicit call transfer (one call answered, the other alerting)

4.3
4.3.1

Interaction with other supplementary services


Line Identification services

Tables 1 to 4 indicate the information to be provided in the Notification Indicator (NI) and the Redirection Number (Rdn) when the subscribers B and C are notified. Call states refer to the situation before ECT invocation. At that time one of the calls is on hold. If user B was the called subscriber in the call A-B, table 1 applies to the information supplied to subscriber C. If user B was the calling subscriber in the call A-B, table 2 applies to the information supplied to subscriber C. Mobile subscriber A has an active call to subscriber B and: - puts the active call on hold and calls subscriber C, table 3 applies to the information supplied to subscriber B; - receives and accepts a call from subscriber C (by putting B on Hold), table 4 applies to the information supplied to subscriber B.

3GPP

Release 7

15

3GPP TS 23.091 V7.0.0 (2007-06)

Table 1: Mobile subscriber A was calling subscriber B, puts B on hold and calls subscriber C
Call states COLR indication received from subscribers B's network Indicated "allowed" Information provided to C

A-B Active A-C Active / Alerting

At time of transfer: NI: "call transferred, active" Rdn: PI = allowed, LI of B At time of transfer: NI: "call transferred, active" Rdn: PI = restricted (note 1) At time of transfer: NI: "call transferred, active" Rdn: PI = not available

A-B Active A-C Active / Alerting

Indicated "restricted"

A-B Active A-C Active / Alerting

No indication received (e.g. interworking)

Table 2: Mobile subscriber A was called by subscriber B, puts B on hold and calls subscriber C
Call states CLIR indication received from subscribers B's network Indicated "allowed" Information provided to C

A-B Active A-C Active / Alerting

At time of transfer: NI: "call transferred, active" Rdn: PI = allowed, LI of B At time of transfer: NI: "call transferred, active" Rdn: PI = restricted (note 1) At time of transfer: NI: "call transferred, active" Rdn: PI = not available

A-B Active A-C Active / Alerting

Indicated "restricted"

A-B Active A-C Active / Alerting

No indication received (e.g. interworking)

NOTE 1: If the subscriber C has CLIP Override Category then the following information is carried in the Redirection number: PI = restricted, LI of B.

3GPP

Release 7

16

3GPP TS 23.091 V7.0.0 (2007-06)

Table 3: Mobile subscriber A puts the call to B on hold and calls subscriber C
Call states COLR indication received from subscribers C's network Indicated "allowed" Information provided to B

A-B Active A-C Active

At time of transfer: NI: "call transferred, active" Rdn: PI = allowed, LI of C At time of transfer: NI: "call transferred, active" Rdn: PI = restricted (note 2) At time of transfer: NI: "call transferred, active" Rdn: PI = not available At time of transfer: NI: "call transferred, alerting" At subscribers C CONNECT: NI: "call transferred, active" Rdn: PI = allowed, LI of C At time of transfer: NI: "call transferred, alerting" At subscribers C CONNECT: NI: "call transferred, active" Rdn: PI = restricted (note 2) At time of transfer: NI: "call transferred, alerting" At subscribers C CONNECT: NI: "call transferred, active" Rdn: PI = not available

A-B Active A-C Active'

Indicated "restricted"

A-B Active A-C Active

No indication received (e.g. interworking)

A-B Active A-C Alerting

Indicated "allowed" at receipt of CONNECT by subscriber C

A-B Active A-C Alerting

Indicated "restricted" at receipt of CONNECT by subscriber C

A-B Active A-C Alerting

No indication received at receipt of CONNECT by subscriber C (e.g. interworking)

Table 4: Mobile subscriber A was called by subscriber C and accepts the call by putting subscriber B on hold
Call states CLIR indication received from subscriber C's network Indicated "allowed" Information provided to B

A-B Active A-C Active

At time of transfer: NI: "call transferred, active" Rdn: PI = allowed, LI of C At time of transfer: NI: "call transferred, active" Rdn: PI = restricted (note 2) At time of transfer: NI: "call transferred, active" Rdn: PI = not available

A-B Active A-C Active

Indicated "restricted"

A-B Active A-C Active

No indication received (e.g. interworking)

NOTE 2: If the subscriber B was called by subscriber A and has CLIP Override Category, or if subscriber B called subscriber A and has COLP Override Category then the following information is carried in the Redirection number: PI = restricted, LI of C

4.3.2
No impact.

Call Forwarding Unconditional (CFU)

3GPP

Release 7

17

3GPP TS 23.091 V7.0.0 (2007-06)

4.3.3
4.3.3.1
No impact.

Call Forwarding on mobile subscriber Busy (CFB)


Call Forwarding on mobile subscriber Busy due to Network Determined User Busy (NDUB)

4.3.3.2

Call Forwarding on mobile subscriber Busy due to User Determined User Busy (UDUB)

When subscriber A transfers the forwarded call there is no impact. When subscriber C forwards the transferred call to the forwarded-to subscriber D due to UDUB the line identity information of the subscriber B that was received by the subscriber C in the ECT invocation notification shall be sent as calling line identity to the forwarded-to subscriber D instead of the line identity of the subscriber A. The corresponding information flow is given in figure 9. For the line identity information sent to the subscriber B after the call is answered by the forwarded-to subscriber D the table 5 applies.
MSa MSCa VLRa MSCb MSb MSCc MSc A-B (active, held) / A-C (call delivered, idle) ECT request > info request > MAF027 info ack < OR1:Y connect calls notification (retrieve) > notification > (retrieve) notification (ECT) > notification (ECT) (alerting) > (alerting) notification (ECT) > notification (ECT) ECT ack (active, RdnB) > < (active,RdnB) disc req A-B reject (UDUB) < disc req A-C < < set up (LI=RdnB) > ANSWER(LI=D) < notification (ECT) > notification (ECT) (active, RdnD) > (active, RdnD) MSCd MSd setup > connect < con ack >

NOTE:

OR1: Checks in VLR and MSC ok? (Y: yes N: no)

Figure 9: Information flow for interaction of explicit call transfer (one call answered, the other alerting) with call forwarding

3GPP

Release 7

18

3GPP TS 23.091 V7.0.0 (2007-06)

Table 5: Subscriber C forwards the transferred call to the subscriber D


Call states COLR indication received from subscribers D's network Indicated "allowed" at receipt of CONNECT by subscriber D Information provided to B

A-B Active A-C Alerting, forwarded to D

At time of transfer: NI: "call transferred, alerting" At subscribers D CONNECT: NI: "call transferred, active" Rdn: PI = allowed, LI of D At time of transfer: NI: "call transferred, alerting" At subscribers D CONNECT: NI: "call transferred, active" Rdn: PI = restricted (note 1) At time of transfer: NI: "call transferred, alerting" At subscribers D CONNECT: NI: "call transferred, active" Rdn: PI = not available

A-B Active A-C Alerting, forwarded to D

Indicated "restricted" at receipt of CONNECT by subscriber D

A-B Active A-C Alerting, forwarded to D

No indication received at receipt of CONNECT by subscriber D (e.g. interworking)

NOTE 1: If the subscriber B was called by subscriber A and has CLIP Override Category, or if subscriber B called subscriber A and has COLP Override Category then the following information is carried in the Redirection number: PI = restricted, LI of D.

4.3.4

Call Forwarding on No Reply (CFNRy)

Same as the interaction between call forwarding on mobile subscriber busy due to UDUB and explicit call transfer as described in subclause 4.3.3.2. Figure 9 applies except that call forwarding is invoked by the CFNRy timer expiry instead of reception of reject (UDUB) message. For the line identity information sent to the subscriber B after the call is answered by the forwarded-to subscriber D the table 5 applies.

4.3.5
No impact.

Call Forwarding on mobile subscriber Not Reachable (CFNRc)

4.3.6
No impact.

Call Waiting (CW)

4.3.7
No impact.

Call Hold (HOLD)

4.3.8

Multi Party (MPTY)

The MSC/VLR shall reject any ECT request from the served subscriber of a MPTY call.

4.3.9

Closed User Group (CUG)

Closed user group restrictions shall be met between users when the first call is set up. Similarly, closed user group restrictions shall also be met between users when setting up the second call. Finally, for successful explicit call transfer the served mobile subscriber must use the same CUG-Interlock code for both calls. The same rule shall applied regardless of being two MO calls, two MT calls or one MO and one MT call.

3GPP

Release 7

19

3GPP TS 23.091 V7.0.0 (2007-06)

4.3.10
No impact.

Advice of Charge (AoC) services

4.3.11
No impact

Call Barring services

4.3.12

Explicit Call Transfer (ECT)

It is required as a network option that the establishment of endless loops between subscriber A and subscriber B, both of them transferring the call to the other one, is prevented. The same loop prevention mechanism as in ISDN shall be used.

4.4

Information stored in the HLR

The following logical states are applicable for the Explicit Call Transfer service (refer to 3GPP TS 23.011 [6] for an explanation of the notation): Provisioning State (Not Provisioned, (Provisioned, Registration State Not Applicable, Not Applicable, Activation State Not Active, Active and Operative, HLR Induction State Not Induced) Not Induced)

The HLR shall store the logical state of the Explicit Call Transfer service (which shall be one of the valid states listed above) on a per subscriber basis.

4.5

State transition model

Figure 10 shows the successful cases of transition between the applicable logical states of the Explicit Call Transfer service. 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 and are therefore not shown in the diagram.

Figure 10: State transition model

3GPP

Release 7

20

3GPP TS 23.091 V7.0.0 (2007-06)

4.6

Transfer of information from the HLR to the VLR

If the provisioning state for the Explicit Call Transfer service is "Provisioned" then when the subscriber registers on a VLR the HLR shall send that VLR information about the logical state of the Explicit Call Transfer service. If the logical state of the Explicit Call Transfer service is changed while a subscriber is registered on a VLR then the HLR shall inform the VLR of the new logical state of the Explicit Call Transfer service.

4.7

Information stored in the VLR

For the supplementary service Explicit Call Transfer the VLR shall store the service state information received from the HLR.

4.8

Handover

Handover will have no impact on the control procedures and the operation of the service.

3GPP

Release 7

21

3GPP TS 23.091 V7.0.0 (2007-06)

Annex A: Change history


TSG CN# Apr 1999 CN#03 CN#06 CN#09 CN#11 CN#11 CN#16 CN#17 CN#26 CT#36 Spec GSM 03.91 23.091 23.091 23.091 23.091 23.091 23.091 23.091 23.091 23.091 Old Ver 6.0.0 3.0.0 3.1.0 3.2.0 3.2.0 4.0.0 5.0.0 5.1.0 6.0.0 005 CR Change history Rev Phase Cat New Ver R99 R99 R99 Rel-4 Rel-4 Rel-5 Rel-5 Rel-6 Rel-7 3.0.0 3.1.0 3.2.0 4.0.0 4.0.0 5.0.0 5.1.0 6.0.0 7.0.0 Subject/Comment Transferred to 3GPP CN1 Approved at CN#03 Approved at CN#06 SDL refresh Version increased from R99 to Rel-4 after CN#11 Enhancement of ECT SDLs and CAMEL functionality Version increased from Rel-4 to Rel-5 after CN#16 Correction to check of ECT treatment indicator in SII2 parameter Version increased from Rel-5 to Rel-6 after CN#26 Upgraded unchanged from Rel-6

001 002

003

3GPP

You might also like