2 Call forwarding on mobile subscriber busy
23.0823GPPCall Forwarding (CF) Supplementary ServicesRelease 17Stage 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 clause 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 3GPP TS 22.004 and 3GPP TS 22.082. 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 clause 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 clause 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 3GPP TS 22.004 [2] and 3GPP TS 22.082 [3]. 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.
CFB may be active simultaneously with ACR (see 3GPP TS 23.088 [12]). If CFB and ACR are active simultaneously, then the ACR supplementary service shall take precedence over the CFB 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 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 clause 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
2.2.1 Call re-routed from VLR
The following Mobile Additional Function has been identified for the PLMN:
MAF008
Call forwarding on mobile subscriber busy authorizations examination
The ability of a PLMN component to determine the authorizations 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.
2.2.2 Call re-routed from HLR
The following Mobile Additional Function has been identified for the PLMN:
MAF008
Call forwarding on mobile subscriber busy authorizations examination
The ability of a PLMN component to determine the authorizations relating to call forwarding on mobile subscriber busy. See figure 2.10.
Location: HLR.
The information flow for call forwarding on mobile subscriber busy with busy state as a result of CCBS blocking is shown in figure 2.14a.
Figure 2.10: MAF008 Call forwarding on mobile subscriber busy authorisations examination (VLR and HLR)
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)
MSa/TEa GMSC HLRb MSCb LEc ß
─────────────────────────────────
││││││││││
││Set-up │ │ │ │ │ │ │ │
││————->││Info request │ │ │ │ │ │
││││————->│ │ │ │ │ │
││││││││││
││││Info ack │MAF008│ │ │ │ │
││││<————-│ │ │ │ │ │
││││││││││
││││Set-up │ │ │ │ ││
│││OR1:N │—————————>│ │ │ │
││││││││││
││││Set-up │ │ │ │ │ │
│││OR1:Y │————————————–>│ │
││││││││││
││Notification │ │ │ │ │ │ │ │
││<————-│OR2:Y │ ││││││
││││││││││
MSa/TEa GMSC HLRb MSCb HLRc SCcß
────────────────────────────
││││││││││││
││Set-up │ │ │ │ │ │ │ │ │ │
││————->│ │ Info request │ │ │ │ │ │ │ │
││││————->│ │ │ │ │ │ │ │
││││││││││││
││││Info ack │MAF008│ │ │ │ │ │ │
││││<————-│ │ │ │ │ │ │ │
││││││││││││
││││Set-up │ │ │ │ │ │ │ │
│││OR1:N │————————–>│ │ │ │ │ │
││││││││││││
││││Information request │ │ │ │ │ │
│││OR1:Y │———————————->││││
││││││││││││
││││Information acknowledge │ │ │ │ │ │
││││<———————————-│ │ │ │
││││││││││││
││││Set-up │ │ │ │ │ │ │ │
││││——————————————–>│ │
││Notification │ │ ││││││││
││<————-│OR2:Y │ │ │ │ │ │ │ │ │
││││││││││││
NOTE: info: information Y: Yes
req: request N: No
ack: acknowledge
OR1: Forwarding requested
OR2: Notification to calling subscriber required
Figure 2.14a: Information flow for call forwarding on mobile subscriber busy with busy state as a result of CCBS blocking (see 3GPP TS 23.093 [11] clause 11.2.2)
2.3 Information stored in the HLR
The following logical states are applicable for CFB
(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 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 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 default forwarded-to number (containing less than 16 digits) 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", "notification to the forwarding party" and "MSISDN of the served subscriber can be presented to the forwarded-to subscriber".
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" and "MSISDN of the served subscriber can be presented to the forwarded-to subscriber" 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 subaddress (if registered) will not be included.
Note that if any network element involved is of Phase 1, CFB Registration requests which use a subaddress 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 subaddress 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 subaddress to the VLR, calls shall be forwarded without the subaddress.
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 clause 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 clause 2.8.3 shall be performed by the HLR.
2.8.6 GMSC only supports Phase 1 call handling
When a call is forwarded on busy, the HLR shall not pass the subaddress to a Phase 1 GMSC. Calls shall be forwarded without the subaddress.
2.8.7 GMSC does not support CAMEL or supports CAMEL Phase 1 only
If the activation state of CFB is "Active and Operative" and if the forwarded-to number is registered in a format other than international and if the GMSC does not support CAMEL or supports CAMEL Phase 1 only, then when a request for routeing information for a mobile terminated call is received in the HLR, CFB shall not be invoked. The HLR shall return a busy subscriber error.
2.9 Contents of messages
The same additions apply for CFB as for CFU, see clause 1.9. The following additions are specific to CFB.
2.9.1 Messages on the B interface (MSC-VLR)
2.9.1.1 Send Info For Incoming Call ack
This message is specified in 3GPP TS 23.018.
Send Info For Incoming Call ack contains the following amendmentto the Forwarded-to number IE,
specific to Long Forwarded-to Numbers:
|
Information element name |
Required |
Description |
|
Forwarded-to number |
M |
Number of the C subscriber. |
2.9.2 Messages on the D interface (VLR-HLR)
2.9.2.1 Insert Subscriber Data
This message corresponds to the MAP-INSERT-SUBSCRIBER-DATA service specified in 3GPP TS 29.002.
Insert Subscriber Data contains the following IE
specificto Long Forwarded-to Numbers:
|
Information element name |
Required |
Description |
|
Long forwarded-to number |
C |
Shall be present if the subscriber has a long forwarded-to number registered; otherwise shall be absent. |
2.9.2.2 Update Location
This message corresponds to theMAP_UPDATE_LOCATION service specified in 3GPP TS 29.002.
Update Location contains the following IE specific
to Long Forwarded-to Numbers:
|
Information element name |
Required |
Description |
|
Long FTN supported |
C |
Shall be present if the VLR supports Long Forwarded-to Numbers; otherwise shall be absent. |
2.9.2.3 Provide Roaming Number
This message is specified in 3GPP TS 23.018.
Provide Roaming Number contains the following IE specific
to Long Forwarded-to Numbers:
|
Information element name |
Required |
Description |
|
Long FTN supported |
C |
Shall be present if the GMSC and the HLR both support Long Forwarded-to Numbers; otherwise shall be absent. |
2.9.2.4 Restore Data
This message corresponds to the MAP_RESTORE_DATA service specified in 3G TS 29.002.
Restore Data contains the following IE specific to Long Forwarded-to Numbers:
|
Information element name |
Required |
Description |
|
Long FTN supported |
C |
Shall be present if the VLR supports Long Forwarded-to Numbers; otherwise shall be absent. |
2.9.3 Messages on the E interface (VMSC-GMSC)
2.9.3.1 Resume Call Handling
This message is specified in 3GPP TS 23.079.
Resume Call Handling contains the following amendment to the Forwarded-to number IE and an additional IE specific to Long Forwarded-to Numbers:
|
Information element name |
Required |
Description |
|
Forwarded-to number |
C |
E.164 number of the C subscriber. Shall be present if the VMSC does not support Long Forwarded-to Numbers; otherwise shall be absent. |
|
Long forwarded-to number |
C |
Number of the C subscriber. Shall be present if the VMSC supports Long Forwarded-to Numbers; otherwise shall be absent. |
2.9.4 Messages on the MSC internal interface
2.9.4.1 Perform Call Forwarding
This message is specified in 3GPP TS 23.018.
Perform Call Forwarding contains the following amendment to the Forwarded-to number IE specific to Long Forwarded-to Numbers:
|
Information element name |
Required |
Description |
|
Forwarded-to number |
M |
Number of the C subscriber. |
2.9.4.2 Perform Call Forwarding ack
This message is specified in 3GPP TS 23.018.
Perform Call Forwarding ack contains the following amendment to the Forwarded-to number IE specific to Long Forwarded-to Numbers:
|
Information element name |
Required |
Description |
|
Forwarded-to number |
M |
Number of the C subscriber. |
2.10 Support of Long Forwarded-to Numbers
2.10.1 MS does not support Long Forwarded-to Numbers
The handling for CFB is the same as that for CFU, see clause 1.10.1.
2.10.2 HLR does not support Long Forwarded-to Numbers
The handling for CFB is the same as that for CFU, see clause 1.10.2.
2.10.3 GMSC does not support Long Forwarded-to Numbers
The MSC/VLR can determine from the PRN whether the GMSC supports Long Forwarded-to Numbers. If the GMSC does not support Long Forwarded-to Numbers and a long forwarded-to number is registered for CFB, then on invocation of CFB, ORLCF shall not be invoked.
2.10.4 MSC/VLR does not support Long Forwarded-to Numbers
The handling for CFB in the HLR is the same as that for CFU, see clause 1.10.3.
The VLR shall indicate whether it supports Long Forwarded-to Numbers in the Update Location and Restore Data messages to the HLR. If the VLR does not support Long Forwarded-to Numbers and a Long Forwarded-to Number is registered for CFB, then:
– If a default forwarded-to number (containing a maximum of 15 digits) is stored in the HLR, the HLR shall send to the VLR an Insert Subscriber Data message containing the default forwarded-to number in the Forwarded-to number parameter.
– Otherwise, the HLR shall send the VLR the following service state information:
– (Provisioned, Not Registered, Not Active, Not Induced)
For an MT call, if the following conditions are met then the HLR shall include the Forwarding interrogation required parameter in the first Send Routing Info ack:
– The GMSC supports Optimal Routeing and Long Forwarded-to Numbers, and
– The MSC/VLR does not support Long Forwarded-to Numbers,and
– CFB is active and operative, and
– A long forwarded-to number is registered for CFB.
According to the rules of Optimal Routeing, when the GMSC receives a Resume Call Handling message from the MSC/VLR, it shall send a second Send Routing Info message to the HLR allowing the HLR to insert the correct long forwarded-to number.