2 Call forwarding on mobile subscriber busy

03.823GPPCall Forwarding (CF) Supplementary ServicesStage 2TS

2.1 Handling of call forwarding on mobile subscriber busy

2.1.1 Registration

The same rules apply for the registration of Call Forwarding on Mobile Subscriber Busy as were described for Call Forwarding Unconditional in subclause 1.1.1 above, with the exception of the checking of interaction with other supplementary services. Basic registration of information is illustrated in figure 2.2.

Supplementary Service Interaction

Possible interaction situations between CFB and other supplementary services must then be checked. This is described in figure 2.2. Also see GSM 02.04 and 02.82. For interaction between CFB and other supplementary services (ie not call barring or call forwarding services), the reader is referred to the respective technical specification for those supplementary services.

Interaction with CAMEL Phase 2 or higher

Possible interaction between CFB and CAMEL Phase 2 or higher is described in figure 2.2. If CAMEL Phase 2 or higher is not supported in the HLR, processing continues from the "No" exit of the test "Result=Pass".

The information flow for registration of CFB is shown in figure 2.1.

MS MSC VLR HLR

_____ _____ _____ _____

| | | | | | | |

| | Register CFB | | | | | |

| |—————>| | | | | |

| | | |Register CFB| | | |

| | | |———–>| | | |

| | | | | |Register CFB| |

| | | | | |———–>| |

| | | | | | |CFB1|

| | | | | | Acknowledge| |

| | | | | |<———–| |

| | | | Acknowledge| | | |

| | | |<———–| | | |

| |Release complete| | | | | |

| |<—————| | | | | |

| | \Facility | | | | | |

| | | | | | | |

Figure 2.1: Registration of call forwarding on mobile subscriber busy

Figure 2.2: CFB1 Call forwarding on mobile subscriber busy registration process

2.1.2 Erasure

The same rules apply for the erasure of CFB as were described for CFU in subclause 1.1.2 above. However, no checks for interaction with other supplementary services are required for erasure of CFB, see figure 2.4.

The information flow for registration of CFB is shown in figure 2.3.

MS MSC VLR HLR

_____ _____ _____ _____

| | | | | | | |

| | Erase CFB | | | | | |

| |—————>| | | | | |

| | | | Erase CFB | | | |

| | | |———–>| | | |

| | | | | | Erase CFB | |

| | | | | |———–>| |

| | | | | | |CFB2|

| | | | | | Acknowledge| |

| | | | | |<———–| |

| | | | Acknowledge| | | |

| | | |<———–| | | |

| |Release complete| | | | | |

| |<—————| | | | | |

| | \Facility | | | | | |

| | | | | | | |

Figure 2.3: Erasure of call forwarding on mobile subscriber busy

Figure 2.4: CFB2 Call forwarding on mobile subscriber busy erasure process

2.1.3 Activation

The same rules apply for the activation of CFB as were described for CFU in subclause 1.1.3 above, with the exception of the checking of interaction with other supplementary services. Basic activation of CFNRc is illustrated in figure 2.6.

Supplementary Service Interaction

Possible interaction situations between CFB and other supplementary services must then be checked. This is described in figure 2.6. Also see GSM 02.04 and 02.82. For interaction between CFB and other supplementary services (ie not call barring or call forwarding services), the reader is referred to the respective technical specification for those supplementary services.

The information flow for activation of call forwarding on MS busy is shown in figure 2.5.

MS MSC VLR HLR

___ ____ ____ _____

| | Activate CFB | | | | | |

| |—————>| | Activate CFB | | | |

| | | |————–>| | Activate CFB | |

| | | | | |————->| |

| | | | | | |CFB3|

| | | | | | Acknowledge | |

| | | | Acknowledge | |<————-| |

| |Release complete| |<————–| | | |

| |<—————| | | | | |

| | \Facility | | | | | |

| | | | | | | |

Figure 2.5: Activation of call forwarding on MS busy

Figure 2.6: CFB3 Call forwarding on mobile subscriber busy activation process

2.1.4 Deactivation

The same rules apply for the deactivation of CFB as were described for CFU in subclause 1.1.4 above, see figure 2.8.

The information flow for deactivation of call forwarding on mobile subscriber busy is shown in figure 2.7.

MS MSC VLR HLR

___ ____ ____ _____

| |Deactivate CFB | | | | | |

| |—————>| |Deactivate CFB | | | |

| | | |————–>| |Deactivate CFB| |

| | | | | |————->| |

| | | | | | |CFB4|

| | | | | | Acknowledge | |

| | | | | |<————-| |

| | | | Acknowledge | | | |

| | | |<————–| | | |

| |Release complete| | | | | |

| |<—————| | | | | |

| | \Facility | | | | | |

| | | | | | | |

Figure 2.7: Deactivation of call forwarding on mobile subscriber busy

Figure 2.8: CFB4 Call forwarding on mobile subscriber busy deactivation process

2.1.5 Interrogation

Data request

The data request procedure enables the mobile subscriber to obtain information about the data stored in the PLMN. Interrogation of CFB is handled by the VLR which returns the required information or error to the MS, see figure 2.9.

MS MSC VLR HLR

___ ____ ____ ____

| | | | | | | |

| |Interrogate CFB | | | | | |

| |—————>| | | | | |

| | | |Interrogate CFB| | | |

| | | |————–>| | | |

| | | | | | | |

| | | | Acknowledge | | | |

| | | |<————–| | | |

| |Release complete| | | | | |

| |<—————| | | | | |

| | \Facility | | | | | |

| | | | | | | |

Figure 2.9: Interrogation of call forwarding on mobile subscriber busy

2.2 Functions and information flows

The following Mobile Additional Function has been identified for the PLMN:

MAF008

Call forwarding on mobile subscriber busy authorisations examination

The ability of a PLMN component to determine the authorisations relating to call forwarding on mobile subscriber busy. See figure 2.10.

Location: VLR.

The information flows for forwarding to fixed terminal and to mobile station are shown in figures 2.11 & 2.12 and 2.13 & 2.14 respectively.

Figure 2.10: MAF008 Call forwarding on mobile subscriber busy authorisations examination (VLR)

MSa/TEa GMSC HLRb VLRb MSCb MSb LEc

____ _____ _____ _______ ______ _____ _____

| | | | | | | | | | | | | |

| | Set-up | | | | | | | | | | | |

| |———–>| |Info req | | | | | | | | | |

| | | |——–>| | | | | | | | | |

| | | | | | | | | | | | | |

| | | |Info ack | | | | | | | | | |

| | | |<——–| | | | | | | | | |

| | | | | | | | | | | | | |

| | | | Set-up | | | | | |

| | | |——————————————>| | | | | |

| | | | | | | | | | | | | |

| | | | | | | | Info request | | | | | |

| | | | | | | |<—————| | | | | |

| | | | | | | | | | | | | |

| | | | | | | | Page MS | | | | | |

| | | | | | | |—————>| | | | | |

| | | | | | | | |NDUB | | | | |

| | | | | | | |Busy subscriber | | | | | |

| | | | | | | |<—————| | | | | |

| | | | | | | | (NDUB) | | | | | |

| | | | | | |MAF008| | | | | | |

| | | | | | | | | | | | | |

| | | | | | |OR1:N | Impossible call| | | | | |

| | | | | | | | completion | | | | | |

| | | | | | | |—————>| | | | | |

| | | | Release | | | | | |

| | Release | |<——————————————| | | | | |

| |<———–| | | | | | | | | | | |

| | | | | | | | | | | | | |

| | | | | | |OR1:Y |Connect to fol- | | | | | |

| | | | | | | |lowing address | | | | | |

| | | | | | | |—————>| | Set-up | |

| | | | | | | | | |—————–>| |

| | | | | | | | | | | | | |

| | | | | | | | | | Notif | | | |

| | | | | | | | |OR2:Y|——>| | | |

| | | | | | | | | | | | | |

| | | | | | | | | | | | | |

| | | | Notification |OR3:Y| | | | |

| |Notification| |<——————————————| | | | | |

| |<———–| | | | | | | | | | | |

| | | | | | | | | | | | | |

NOTE: NDUB: Network Determined User Busy info: information Y: Yes req: request N: No ack: acknowledge notif: notification OR1: Call to be forwarded OR2: Notification to forwarding subscriber required OR3: Notification to calling subscriber required

Figure 2.11: Information flow for call forwarding on mobile subscriber busy
(to fixed terminal) (NDUB)

MSa/TEa GMSC HLRb VLRb MSCb MSb LEc

____ _____ _____ _______ ______ ______ ____

| | | | | | | | | | | | | |

| | Set-up | | | | | | | | | | | |

| |———–>| |Info req | | | | | | | | | |

| | | |——–>| | | | | | | | | |

| | | | | | | | | | | | | |

| | | |Info ack | | | | | | | | | |

| | | |<——–| | | | | | | | | |

| | | | | | | | | | | | | |

| | | | Set-up | | | | | |

| | | |——————————————>| | | | | |

| | | | | | | | | | | | | |

| | | | | | | | Info request | | | | | |

| | | | | | | |<—————| | | | | |

| | | | | | | | | | | | | |

| | | | | | | | Page MS | | | | | |

| | | | | | | |—————>| |Set-up | | | |

| | | | | | | | | |——>| | | |

| | | | | | | | | | |UDUB | | |

| | | | | | | | | | UDUB | | | |

| | | | | | | |Busy subscriber | |<——| | | |

| | | | | | | |<—————| | | | | |

| | | | | | | | (UDUB) | | | | | |

| | | | | | |MAF008| | | | | | |

| | | | | | | | | | | | | |

| | | | | | |OR1:N |Impossible call | | | | | |

| | | | | | | | completion | | | | | |

| | | | | | | |—————>| | | | | |

| | | | Release | | | | | |

| | Release | |<——————————————| | | | | |

| |<———–| | | | | | | | | | | |

| | | | | | | | | | | | | |

| | | | | | |OR1:Y |Connect to fol- | | | | | |

| | | | | | | |lowing address | | | | | |

| | | | | | | |—————>| | Set-up | |

| | | | | | | | | |——————>| |

| | | | | | | | | | | | | |

| | | | Notification |OR2:Y| | | | |

| |Notification| |<——————————————| | | | | |

| |<———–| | | | | | | | | | | |

| | | | | | | | | | | | | |

NOTE: UDUB: User Determined User Busy info: information Y: Yes req: request N: No ack: acknowledge notif: notification
OR1: Call to be forwarded OR2: Notification to calling subscriber required

Figure 2.12: Information flow for call forwarding on mobile subscriber busy
(to fixed terminal) (UDUB)

MSa/TEa GMSC HLRb VLRb MSCb MSb HLRc MSCc

____ ____ ____ _______ ______ _____ _____ ____

| | | | | | | | | | | | | | | |

| |Set-up | | | | | | | | | | | | | |

| |——>| |Info req| | | | | | | | | | | |

| | | |——->| | | | | | | | | | | |

| | | | | | | | | | | | | | | |

| | | |Info ack| | | | | | | | | | | |

| | | |<——-| | | | | | | | | | | |

| | | | | | | | | | | | | | | |

| | | | Set-up | | | | | | | |

| | | |—————————————->| | | | | | | |

| | | | | | | | | | | | | | | |

| | | | | | | | Info request | | | | | | | |

| | | | | | | |<—————| | | | | | | |

| | | | | | | | | | | | | | | |

| | | | | | | | Page MS | | | | | | | |

| | | | | | | |—————>| | | | | | | |

| | | | | | | | |NDUB | | | | | | |

| | | | | | | |Busy subscriber | | | | | | | |

| | | | | | | |<—————| | | | | | | |

| | | | | | |MAF008| (NDUB) | | | | | | | |

| | | | | | | | | | | | | | | |

| | | | | | |OR1:N |Impossible call | | | | | | | |

| | | | | | | | completion | | | | | | | |

| | | | | | | |—————>| | | | | | | |

| | | | Release | | | | | | | |

| |Release| |<—————————————-| | | | | | | |

| |<——| | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |

| | | | | | |OR1:Y |Connect to fol- | | | | | | | |

| | | | | | | | lowing address | | | | | | | |

| | | | | | | |—————>| |Information req | | | |

| | | | | | | | | |—————>| | | |

| | | | | | | | | | | | | | | |

| | | | | | | | | |Information ack | | | |

| | | | | | | | | |<—————| | | |

| | | | | | | | | | | | | | | |

| | | | | | | | | | Set-up | |

| | | | | | | | | |————————–>| |

| | | | | | | | | | | | | | | |

| | | | | | | | | |Notif| | | | | |

| | | | | | | | |OR2:Y|—->| | | | | |

| | | | | | | | | | | | | | | |

| | | | Notification |OR3:Y| | | | | | |

| | Notif | |<—————————————-| | | | | | | |

| |<——| | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |

NOTE: NDUB: Network Determined User Busy info: information Y: Yes req: request N: No ack: acknowledge notif: notification
OR1: Call to be forwarded OR2: Notification to forwarding subscriber required OR3: Notification to calling subscriber required

Figure 2.13: Information flow for call forwarding on mobile subscriber busy
(to mobile station) (NDUB)

MSa/TEa GMSC HLRb VLRb MSCb MSb HLRc MSCc

____ ____ ____ _______ ______ _____ ____ ____

| | | | | | | | | | | | | | | |

| |Set-up | | | | | | | | | | | | | |

| |——>| |Info req | | | | | | | | | | | |

| | | |——–>| | | | | | | | | | | |

| | | | | | | | | | | | | | | |

| | | |Info ack | | | | | | | | | | | |

| | | |<——–| | | | | | | | | | | |

| | | | | | | | | | | | | | | |

| | | | Set-up | | | | | | | |

| | | |—————————————->| | | | | | | |

| | | | | | | | | | | | | | | |

| | | | | | | | Info request | | | | | | | |

| | | | | | | |<————–| | | | | | | |

| | | | | | | | | | | | | | | |

| | | | | | | | Page MS | | | | | | | |

| | | | | | | |————–>| | Set-up| | | | | |

| | | | | | | | | |——>| | | | | |

| | | | | | | | | | |UDUB| | | | |

| | | | | | | | | | UDUB | | | | | |

| | | | | | | |Busy subscriber| |<——| | | | | |

| | | | | | | |<————–| | | | | | | |

| | | | | | |MAF008| (UDUB) | | | | | | | |

| | | | | | | | | | | | | | | |

| | | | | | |OR1:N |Impossible call| | | | | | | |

| | | | | | | | completion | | | | | | | |

| | | | | | | |————–>| | | | | | | |

| | | | Release | | | | | | | |

| |Release| |<—————————————-| | | | | | | |

| |<——| | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |

| | | | | | |OR1:Y |Connect to fol-| | | | | | | |

| | | | | | | |lowing address | | | | | | | |

| | | | | | | |————–>| | Information req | | | |

| | | | | | | | | |—————–>| | | |

| | | | | | | | | | | | | | | |

| | | | | | | | | | Information ack | | | |

| | | | | | | | | |<—————–| | | |

| | | | | | | | | | | | | | | |

| | | | | | | | | | Set-up | |

| | | | | | | | | |————————–>| |

| | | | Notification |OR2:Y| | | | | | |

| | Notif | |<—————————————-| | | | | | | |

| |<——| | | | | | | | | | | | | |

| | | | | | | | | | | | | | | |

NOTE: UDUB: User Determined User Busy info: information Y: Yes req: request N: No ack: acknowledge notif: notification OR1: Call to be forwarded OR2: Notification to calling subscriber required

Figure 2.14: Information flow for call forwarding on mobile subscriber busy
(to mobile station) (UDUB)

2.3 Information stored in the HLR

The following logical states are applicable for CFB (refer to GSM 03.11 for an explanation of the notation):

Provisioning State

Registration State

Activation State

HLR Induction State

(Not Provisioned,

Not Registered,

Not Active,

Not Induced)

(Provisioned,

Not Registered,

Not Active,

Not Induced)

(Provisioned,

Registered,

Not Active,

Not Induced)

(Provisioned,

Registered,

Active and Quiescent,

Not Induced)

(Provisioned,

Registered,

Active and Operative,

Not Induced)

The registration and activation state may be different for each applicable elementary basic service group.

The provisioning state shall be on a per subscriber basis, and hence the same for all basic service groups.

The HLR shall store:

– the state of CFB (which shall be one of the valid states listed above) for each applicable elementary basic service group;

– the subscription option "notification to the calling party" on a per subscriber basis;

This subscription option takes one of the following values:

– no notification;

– notification.

– the subscription option "notification to the forwarding party" on a per subscriber basis;

This subscription option takes one of the following values:

– no notification;

– notification.

– the registration parameter "forwarded-to number" (possibly including a forwarded-to sub-address) for each applicable elementary basic service group.

2.4 State transition model

The following figure shows the successful cases of transition between the applicable logical states of CFB. The state changes are either caused by actions of the service provider, the mobile user or the network.

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. The diagram only shows operations on an elementary basic service group.

Figure 2.15: State transition model for CFB

2.5 Transfer of information from HLR to VLR

If the provisioning state for CFB is "Provisioned" then, when the subscriber registers on a VLR, the HLR shall send that VLR information about the logical state of CFB for all relevant elementary basic service groups.

If the registration state for CFB is "Registered" then, when the subscriber registers on a VLR, the HLR shall send that VLR the registration parameter "forwarded-to number" for all relevant elementary basic service groups and information about the subscription options "notification to the calling party" and "notification to the forwarding party".

If the logical state or the registration parameter "forwarded-to number" of CFB is changed while a subscriber is registered on a VLR then for the affected basic service groups, the HLR shall inform the VLR respectively of the new logical state or the new registration parameter of CFB.

If information about the subscription options "notification to the calling party" and "notification to the forwarding party" of CFB is changed while a subscriber is registered on a VLR and the registration state of CFB is "Registered" then the HLR shall inform the VLR of the new information about the subscription options of CFB.

2.6 Information stored in the VLR

For CFB the VLR shall store the service state information, the registration parameter "forward-to number" and the subscription options received from the HLR.

2.7 Handover

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

2.8 Cross phase compatibility

2.8.1 MS, MSC, VLR or HLR only support Phase 1 control of SS by the subscriber

In response to a CFB interrogation request, if the MS or any network element involved is of Phase 1, only information concerning basic service groups for which the activation state has the value "Active and Operative" will be returned. This means that the subscriber will not be aware that the forwarded to number is registered if CFB is deactivated or active (quiescent). A sub-address (if registered) will not be included.

Note that if any network element involved is of Phase 1, CFB Registration requests which use a sub-address and all CFB Activation and Deactivation requests will be rejected, as these are not specified in Phase 1.

2.8.2 HLR only supports Phase 1 updating of subscriber information

If the VLR receives the SS-Status parameter from a Phase 1 HLR it shall act if it has received the SS-Status parameter with the values shown in the following:

1) Registered, Activated => P bit =1, R bit = 1, A bit = 1, Q bit = 0;

2) Registered, Deactivated => P bit =1, R bit = 1, A bit = 0, Q bit = 0 or 1;

3) Erased => P bit =1, R bit = 0, A bit = 0, Q bit = 0 or 1.

2.8.3 VLR only supports Phase 1 updating of subscriber information

When passing CFB information to a Phase 1 VLR, the HLR shall send the service state information in a form which the VLR can accept, based on the logical state held in the HLR, as follows:

1) (Provisioned, Not Registered, Not Active, Not Induced)

=> Erased, Deactivated;

2) (Provisioned, Registered, Not Active, Not Induced)

=> Registered, Deactivated;

3) (Provisioned, Registered, Active and Operative, Not Induced)

=> Registered, Activated;

4) (Provisioned, Registered, Active and Quiescent, Not Induced)

=> Registered, Deactivated.

The HLR shall not pass a sub-address to a Phase 1 VLR.

2.8.4 VLR only supports Phase 1 call handling

When a call is forwarded on busy, as the HLR does not pass the sub-address to the VLR, calls shall be forwarded without the sub-address.

2.8.5 VLR does not support CAMEL or supports CAMEL Phase 1 only

When passing CFB information to a VLR not supporting CAMEL or supporting CAMEL Phase 1 only, the HLR shall send the registration parameter "forwarded-to number" only if it is registered in a format which the VLR can accept, i.e. international format.

If the registration state for CFB is "Registered" and the forwarded-to number is registered in a format other than international, then when updating a VLR not supporting CAMEL or supporting CAMEL Phase 1 only the HLR shall modify the service state information of CFB as follows.

1) (Provisioned, Registered, Not Active, Not Induced)

=> (Provisioned, Not Registered, Not Active, Not Induced)

2) (Provisioned, Registered, Active and Operative, Not Induced)

=> (Provisioned, Not Registered, Not Active, Not Induced)

3) (Provisioned, Registered, Active and Quiescent, Not Induced)

=> (Provisioned, Not Registered, Not Active, Not Induced)

According to the definitions in section 2.5 no forwarded-to number will be passed to the VLR in these cases. The modification of the service state information sent to the VLR shall have no impact on the service state information stored in the HLR.

If the VLR supports Phase 1 updating of subscriber information only, a further translation of the service state information as defined in section 2.8.3 shall be performed by the HLR.