3 Call forwarding on no reply
23.0823GPPCall Forwarding (CF) Supplementary ServicesRelease 17Stage 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 clause 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 3GPP TS 22.004 and 3GPP TS 22.082. 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 clause 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 clause 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 3GPP TS 22.004 [2] and 3GPP TS 22.082 [3]. 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.
CFNRy may be active simultaneously with ACR (see 3GPP TS 23.088 [12]). If CFNRy and ACR are active simultaneously, then the ACR supplementary service shall take precedence over the CFNRy service, i.e. a call which is terminated for the served subscriber when CLI presentation is restricted shall be rejected according to the ACR supplementary service.
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 clause 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 authorizations examination
The ability of a PLMN component to determine the authorizations 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: MAF009 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 3GPP TS 23.011 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 subscription option "MSISDN of the served subscriber can be presented to the forwarded-to subscriber" on a per subscriber basis;
This subscription option takes one of the following values:
– presentation restricted;
– presentation allowed.
– 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.
– the default forwarded-to number (containing less than 16 digits) for each applicable elementary basic service group.
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", "notification to the forwarding party" and "MSISDN of the served subscriber can be presented to the forwarded-to subscriber".
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" and "MSISDN of the served subscriber can be presented to the forwarded-to subscriber" 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 subaddress (if registered) will not be included.
Note that if any network element involved is of Phase 1, CFNRy Registration requests which use a subaddress 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 subaddress to the VLR, calls shall be forwarded without the subaddress.
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 clause 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 clause 3.8.3 shall be performed by the HLR.
3.9 Contents of messages
The same additions apply for CFNRy as for CFB, see clause 2.9 (additions to Send Routing Info and Send Routing Info ack are not used in this case).
3.10 Support of Long Forwarded-to Numbers
The handling for early CFNRc is the same as that for CFU, see clause 1.10.
The handling for late CFNRy is the same as that for CFB, see clause 2.10.