3 Call forwarding on no reply

03.823GPPCall Forwarding (CF) Supplementary ServicesStage 2TS

3.1 Handling of call forwarding on no reply

3.1.1 Registration

The same rules apply for the registration of Call Forwarding on No Reply as were described for Call Forwarding Unconditional in subclause 1.1.1 above, with the exceptions described below. Basic registration of information is illustrated in figure 3.2.

The No Reply Condition Timer

If a value for the no reply condition timer is not included in the registration request received from the MS, then the previous value set by the mobile user or the network operator applies.

Supplementary Service Interaction

Possible interaction situations between CFNRy and other supplementary services must then be checked. This is described in figure 3.2. Also see GSM 02.04 and 02.82. For interaction between CFNRy 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 CFNRy and CAMEL Phase 2 or higher is described in figure 3.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 call forwarding on no reply is shown in figure 3.1.

MS MSC VLR HLR

____ ____ ____ _______

| | | | | | | |

| |Register CFNRy | | | | | |

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

| | | |Register CFNRy| | | |

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

| | | | | |Register CFNRy| |

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

| | | | | | |CFNRy1|

| | | | | | Acknowledge | |

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

| | | | Acknowledge | | | |

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

| |Release complete| | | | | |

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

| | \Facility | | | | | |

| | | | | | | |

Figure 3.1: Registration of call forwarding on no reply

Figure 3.2: CFNRy1 Call forwarding on no reply registration process

3.1.2 Erasure

The same rules apply for the erasure of Call Forwarding on No Reply as were described for Call Forwarding Unconditional in subclause 1.1.2 above. However, no checks for interaction with other supplementary services are required for erasure of CFNRy, see figures 3.3 and 3.4.

MS MSC VLR HLR

____ ____ _____ _______

| | | | | | | |

| | Erase CFNRy | | | | | |

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

| | | |Erase CFNRy | | | |

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

| | | | | |Erase CFNRy | |

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

| | | | | | |CFNRy2|

| | | | | | Acknowledge| |

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

| | | | Acknowledge| | | |

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

| |Release complete| | | | | |

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

| | \Facility | | | | | |

| | | | | | | |

Figure 3.3: Erasure of call forwarding on no reply

Figure 3.4: CFNRy2 Call forwarding on no reply erasure process

3.1.3 Activation

The same rules apply for the activation of Call Forwarding on No Reply as were described for Call Forwarding Unconditional in subclause 1.1.3 above, with the exception of the checking of interaction with other supplementary services. Basic activation of CFNRy is illustrated in figure 3.6.

Supplementary Service Interaction

Possible interaction situations between CFNRy and other supplementary services must then be checked. This is described in figure 3.6. Also see GSM 02.04 and 02.82. For interaction between CFNRy and other supplementary services (i.e. 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 CFNRy is shown in figure 3.5.

MS MSC VLR HLR

___ ___ ____ _______

| | Activate CFNRy | | | | | |

| |—————>| |Activate CFNRy| | | |

| | | |————->| |Activate CFNRy| |

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

| | | | | | |CFNRy3|

| | | | | | Acknowledge | |

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

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

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

| | \Facility | | | | | |

| | | | | | | |

Figure 3.5: Activation of call forwarding on no reply

Figure 3.6: CFNRy3 Call forwarding on no reply activation process

3.1.4 Deactivation

The same rules apply for the deactivation of CFNRy as were described for CFU in subclause 1.1.4 above, see figure 3.7 and 3.8.

MS MSC VLR HLR

___ ___ ___ _______

| |Deactivate CFNRy| | | | | |

| |—————>| |Deactivate CFNRy| | | |

| | | |—————>| |DeactivateCFNRy| |

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

| | | | | | |CFNRy4|

| | | | | | Acknowledge | |

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

| | | | Acknowledge | | | |

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

| |Release complete| | | | | |

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

| | \Facility | | | | | |

| | | | | | | |

Figure 3.7: Deactivation of call forwarding on no reply

Figure 3.8: CFNRy4 Call forwarding on no reply deactivation process

3.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 CFNRy is handled by the VLR which returns the required information or error to the MS, see figure 3.9.

MS MSC VLR HLR

___ ___ ___ ___

| |Interrogate CFNRy| | | | | |

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

| | | |Interrogate CFNRy| | | |

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

| | | | | | | |

| | | | Acknowledge | | | |

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

| |Release complete | | | | | |

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

| | \Facility | | | | | |

| | | | | | | |

Figure 3.9: Interrogation of call forwarding on no reply

3.2 Functions and information flows

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

MAF009

Call forwarding on no reply authorisations examination

The ability of a PLMN component to determine the authorisations relating to call forwarding on no reply. See figure 3.10.

Location: VLR.

The information flows for forwarding to fixed terminal and to mobile station are shown in figures 3.11 and 3.12 respectively.

Figure 3.10: MAF008 Call forwarding on no reply authorisations examination (VLR)

MSa/TEa GMSC HLRb VLRb MSCb MSb LEc

_____ _____ _____ _______ ________ _____ _____

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

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

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

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

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

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

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

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

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

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

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

| | | | | | | | Info req | | | | | |

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

| | | | | | |MAF009| | | | | | |

| | | | | | | | Info ack | | Set-up | | | |

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

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

| | | | | | | | | |Call conf| | | |

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

| | | | | | | | | timer | | | | |

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

| | | | | | | | | timer | | | | |

| | | | | | | | Info req |expires| | | | |

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

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

| | | | | | | |Impossible| | | | | |

| | | | | | | | call | | | | | |

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

| | | | | | |OR1:N |———>| | | | | |

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

| | | | Release | | | | | |

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

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

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

| | | | | | | |Connect to| | | | | |

| | | | | | | | following| | | | | |

| | | | | | | | address | | | | | |

| | | | | | |OR1:Y |———>| | Set-up | |

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

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

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

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

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

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

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

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

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

NOTE: info: information Y: Yes req: request N: No ack: acknowledge
notif: notification
conf: confirmation
OR1: Call to be forwarded OR2: Notification to forwarding subscriber required OR3: Notification to calling subscriber required

Figure 3.11: Information flow for call forwarding on no reply
(to fixed terminal)

MSa/TEa GMSC HLRb VLRb MSCb MSb HLRc MSCc

___ ____ ____ _______ ________ ____ ____ ____

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

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

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

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

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

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

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

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

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

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

| | | | | | | | Info req | | | | | | | |

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

| | | | | | |MAF009| | | | | | | | |

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

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

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

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

| | | | | | | | | |Call conf| | | | | |

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

| | | | | | | | | timer | | | | | | |

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

| | | | | | | | Info req | timer | | | | | | |

| | | | | | | |<———|expires░ | | | | | |

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

| | | | | | | |impossible| | | | | | | |

| | | | | | | | call | | | | | | | |

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

| | | | | | |OR1:N |———>| | | | | | | |

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

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

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

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

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

| | | | | | | |Connect to| | | | | | | |

| | | | | | | |following | | | | | | | |

| | | | | | | | address | | | | | | | |

| | | | | | |OR1:Y |———>| | Info request | | | |

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

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

| | | | | | | | | | Info acknowledge | | | |

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

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

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

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

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

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

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

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

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

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

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

NOTE: info: information Y: Yes req: request N: no ack: acknowledge
notif: notification
conf: confirmation
OR1: Call to be forwarded OR2: Notification to forwarding subscriber required OR3: Notification to calling subscriber required

Figure 3.12: Information flow for call forwarding on no reply
(to mobile station)

3.3 Information stored in the HLR

The following logical states are applicable for CFNRy (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 CFNRy (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;

– the registration parameter "no reply condition timer" for each applicable elementary basic service group.

This parameter may take values in the range 5 – 30 seconds in steps of 5 seconds.

3.4 State transition model

The following figure shows the successful cases of transition between the applicable logical states of CFNRy. 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 3.13: State transition model for CFNRy

3.5 Transfer of information from HLR to VLR

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

If the registration state for CFNRy is "Registered" then, when the subscriber registers on a VLR, the HLR shall send that VLR the registration parameter "forwarded-to number" and "no reply condition timer" 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, the registration parameter "forwarded-to number" or the registration parameter "no reply condition timer" of CFNRy 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 CFNRy.

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

3.6 Information stored in the VLR

For CFNRy the VLR shall store the service state information, the registration parameter "forward-to number", the registration parameter "no reply condition timer" and the subscription options received from the HLR.

3.7 Handover

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

3.8 Cross phase compatibility

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

In response to a CFNRy 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 CFNRy 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, CFNRy Registration requests which use a sub-address and all CFNRy Activation and Deactivation requests will be rejected, as these are not specified in Phase 1.

3.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.

3.8.3 VLR only supports Phase 1 updating of subscriber information

When passing CFNRy 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 subaddress to a Phase 1 VLR.

3.8.4 VLR only supports Phase 1 call handling

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

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

When passing CFNRy 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 CFNRy 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 CFNRy 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 3.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 3.8.3 shall be performed by the HLR.