4 Explicit Call Transfer (ECT)
23.0913GPPExplicit Call Transfer (ECT) supplementary serviceRelease 17Stage 2TS
4.1 Functions
The following function has been identified for the explicit call transfer service:
MAF027
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
Figure 1: Explicit Call Transfer related authorizations examination (VLR)
4.2 SDL diagrams and information flows
4.2.1 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 subscriber’s 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.
Figure 2: Procedure Handle_ECT_Active
Figure 3: Macro Check_ECT
MSa MSCa VLRa MSCb MSb LEc TEcá
┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
│ 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) │ │ │ │ │ │ │ │
│ ───────────────────────────────────────── │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
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 LEc TEc
┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
│ 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) │ │ │ │ │ │ │ │
│ │ │ │ ─────────────────────────────────────────────────────────> │ │ notification(ECT)│
│ │ │ │ (active, Rdn) │ │ │ │ │ │ ────────────> │ │
│ │ │ │ │ │ │ │ │ │ │ │ (active, Rdn) │ │
│ │ ECT ack │ │ │ │ │ │ │ │ │ │ │ │
│ │ <───────────── │ │ │ │ │ │ │ │ │ │ │ │
│ │ disc req A-B │ │ │ │ │ │ │ │ │ │ │ │
│ │ <───────────── │ │ │ │ │ │ │ │ │ │ │ │
│ │ NORMAL DISCONNECTION A-B │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ disc req A-C │ │ │ │ │ │ │ │ │ │ │ │
│ │ <───────────── │ │ │ │ │ │ │ │ │ │ │ │
│ │ NORMAL DISCONNECTION A-C │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
│ B-C (active, idle) │ │ │ │ │ │ │ │ │ │ │
│ ──────────────────── │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
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.
The corresponding information flows are given in figure 7 and figure 8.
Figure 6: Procedure Handle_ECT_Alerting
MSa MSCa VLRa MSCb MSb LEc TEc
┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
│ 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)
MSa MSCa VLRa MSCb MSb LEc TEc
┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
│ 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) │ │ │ │ │ │ │ │
│ │ │ │ ─────────────────────────────────────────────────────────> │ │ notification(ECT)│
│ │ ECT ack │ │ (active, Rdn) │ │ │ │ │ │ ────────────> │ │
│ │ <───────────── │ │ │ │ │ │ │ │ │ │ (active, Rdn) │ │
│ │ disc req A-B │ │ │ │ │ │ │ │ │ │ │ │
│ │ <───────────── │ │ │ │ │ │ │ │ │ │ │ │
│ │ disc req A-C │ │ │ │ │ │ │ │ │ │ │ │
│ │ <───────────── │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
│ A idle, B hears C ringing │ │ │ │ │ │ │ │ │ │
│ ─────────────────────────── │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ CONNECT │ │
│ │ │ │ ANSWER │ │ │ │ │ │ │ │ <────────── │ │
│ │ │ │ <───────────────────────────────────────────────────────── │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ CONNECT ACK │ │
│ │ │ │ │ │ │ │ │ │ │ │ ───────────> │ │
│ │ │ │ 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 Interaction with other supplementary services
4.3.1 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.
Table 1: Mobile subscriber A was calling subscriber B, puts B on hold and calls subscriber C
|
Call states |
COLR indication received from |
Information provided to C |
|
subscribers B’s network |
||
|
A-B Active |
Indicated "allowed" |
At time of transfer: |
|
A-C Active / Alerting |
NI: "call transferred, active" |
|
|
Rdn: PI = allowed, LI of B |
||
|
A-B Active |
Indicated "restricted" |
At time of transfer: |
|
A-C Active / Alerting |
NI: "call transferred, active" |
|
|
Rdn: PI = restricted (note 1) |
||
|
A-B Active |
No indication received |
At time of transfer: |
|
A-C Active / Alerting |
(e.g. interworking) |
NI: "call transferred, active" |
|
Rdn: PI = not available |
Table 2: Mobile subscriber A was called by subscriber B, puts B on hold and calls subscriber C
|
Call states |
CLIR indication received from |
Information provided to C |
|
subscribers B’s network |
||
|
A-B Active |
Indicated "allowed" |
At time of transfer: |
|
A-C Active / Alerting |
NI: "call transferred, active" |
|
|
Rdn: PI = allowed, LI of B |
||
|
A-B Active |
Indicated "restricted" |
At time of transfer: |
|
A-C Active / Alerting |
NI: "call transferred, active" |
|
|
Rdn: PI = restricted (note 1) |
||
|
A-B Active |
No indication received |
At time of transfer: |
|
A-C Active / Alerting |
(e.g. interworking) |
NI: "call transferred, active" |
|
Rdn: PI = not available |
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.
Table 3: Mobile subscriber A puts the call to B on hold and calls subscriber C
|
Call states |
COLR indication received from |
Information provided to B |
|
subscribers C’s network |
||
|
A-B Active |
Indicated "allowed" |
At time of transfer: |
|
A-C Active |
NI: "call transferred, active" |
|
|
Rdn: PI = allowed, LI of C |
||
|
A-B Active |
Indicated "restricted" |
At time of transfer: |
|
A-C Active’ |
NI: "call transferred, active" |
|
|
Rdn: PI = restricted (note 2) |
||
|
A-B Active |
No indication received |
At time of transfer: |
|
A-C Active |
(e.g. interworking) |
NI: "call transferred, active" |
|
Rdn: PI = not available |
||
|
A-B Active |
Indicated "allowed" at receipt of |
At time of transfer: |
|
A-C Alerting |
CONNECT by subscriber C |
NI: "call transferred, alerting" |
|
At subscribers C CONNECT: |
||
|
NI: "call transferred, active" |
||
|
Rdn: PI = allowed, LI of C |
||
|
A-B Active |
Indicated "restricted" at receipt of |
At time of transfer: |
|
A-C Alerting |
CONNECT by subscriber C |
NI: "call transferred, alerting" |
|
At subscribers C CONNECT: |
||
|
NI: "call transferred, active" |
||
|
Rdn: PI = restricted (note 2) |
||
|
A-B Active |
No indication received at receipt of |
At time of transfer: |
|
A-C Alerting |
CONNECT by subscriber C |
NI: "call transferred, alerting" |
|
(e.g. interworking) |
At subscribers C CONNECT: |
|
|
NI: "call transferred, active" |
||
|
Rdn: PI = not available |
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 |
Information provided to B |
|
subscriber C’s network |
||
|
A-B Active |
Indicated "allowed" |
At time of transfer: |
|
A-C Active |
NI: "call transferred, active" |
|
|
Rdn: PI = allowed, LI of C |
||
|
A-B Active |
Indicated "restricted" |
At time of transfer: |
|
A-C Active |
NI: "call transferred, active" |
|
|
Rdn: PI = restricted (note 2) |
||
|
A-B Active |
No indication received |
At time of transfer: |
|
A-C Active |
(e.g. interworking) |
NI: "call transferred, active" |
|
Rdn: PI = not available |
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 Call Forwarding Unconditional (CFU)
No impact.
4.3.3 Call Forwarding on mobile subscriber Busy (CFB)
4.3.3.1 Call Forwarding on mobile subscriber Busy due to Network Determined User Busy (NDUB)
No impact.
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 MSCd MSd
┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
│ 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) │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ ─────────────────> │ setup │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │──>│ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ connect │
│ │ │ │ │ │ │ │ ANSWER(LI=D) │ │ │ │ │ │ │ │<──│ │
│ │ │ │ <────────────────────────────────────────────────────────────────────── │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ con ack │
│ │ │ │ notification (ECT) │ │ │ │ │ │ │ │ │ │──>│ │
│ │ │ │ ─────────────────────> │ notification (ECT) │ │ │ │ │ │ │ │ │
│ │ │ │ (active, RdnD) │ │ ───────────> │ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │(active, RdnD)│ │ │ │ │ │ │ │ │ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
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
Table 5: Subscriber C forwards the transferred call to the subscriber D
|
Call states |
COLR indication received from |
Information provided to B |
|
subscribers D’s network |
||
|
A-B Active |
Indicated "allowed" at receipt of |
At time of transfer: |
|
A-C Alerting, |
CONNECT by subscriber D |
NI: "call transferred, alerting" |
|
forwarded to D |
At subscribers D CONNECT: |
|
|
NI: "call transferred, active" |
||
|
Rdn: PI = allowed, LI of D |
||
|
A-B Active |
Indicated "restricted" at receipt of |
At time of transfer: |
|
A-C Alerting, |
CONNECT by subscriber D |
NI: "call transferred, alerting" |
|
forwarded to D |
At subscribers D CONNECT: |
|
|
NI: "call transferred, active" |
||
|
Rdn: PI = restricted (note 1) |
||
|
A-B Active |
No indication received at receipt of |
At time of transfer: |
|
A-C Alerting, |
CONNECT by subscriber D |
NI: "call transferred, alerting" |
|
forwarded to D |
(e.g. interworking) |
At subscribers D CONNECT: |
|
NI: "call transferred, active" |
||
|
Rdn: PI = not available |
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 clause 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 Call Forwarding on mobile subscriber Not Reachable (CFNRc)
No impact.
4.3.6 Call Waiting (CW)
No impact.
4.3.7 Call Hold (HOLD)
No impact.
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.
4.3.10 Advice of Charge (AoC) services
No impact.
4.3.11 Call Barring services
No impact
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 Registration State Activation State HLR Induction State
(Not Provisioned, Not Applicable, Not Active, Not Induced)
(Provisioned, Not Applicable, Active and Operative, 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
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.
Annex A:
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
Apr 1999 |
Transferred to 3GPP CN1 |
||||||
|
CN#03 |
Approved at CN#03 |
3.0.0 |
|||||
|
CN#06 |
001 |
Approved at CN#06 |
3.1.0 |
||||
|
CN#09 |
002 |
1 |
SDL refresh |
3.2.0 |
|||
|
CN#11 |
Version increased from R99 to Rel-4 after CN#11 |
4.0.0 |
|||||
|
CN#11 |
003 |
1 |
Enhancement of ECT SDLs and CAMEL functionality |
4.0.0 |
|||
|
CN#16 |
Version increased from Rel-4 to Rel-5 after CN#16 |
5.0.0 |
|||||
|
CN#17 |
005 |
Correction to check of ECT treatment indicator in SII2 parameter |
5.1.0 |
||||
|
CN#26 |
Version increased from Rel-5 to Rel-6 after CN#26 |
6.0.0 |
|||||
|
CT#36 |
Upgraded unchanged from Rel-6 |
7.0.0 |
|||||
|
CT#42 |
Upgraded unchanged from Rel-7 |
8.0.0 |
|||||
|
CT#46 |
– |
– |
Update to Rel-9 version (MCC) |
9.0.0 |
|||
|
2011-03 |
– |
– |
Update to Rel-10 version (MCC) |
10.0.0 |
|||
|
2012-09 |
– |
– |
Update to Rel-11 version (MCC) |
11.0.0 |
|||
|
2014-09 |
– |
– |
Update to Rel-12 version (MCC) |
12.0.0 |
|||
|
2015-12 |
– |
– |
Update to Rel-13 version (MCC) |
13.0.0 |
|||
|
2017-03 |
– |
– |
Update to Rel-14 version (MCC) |
14.0.0 |
|||
|
2018-06 |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|||
|
2020-07 |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|||
|
2022-03 |
– |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |