4.4 Description of CAMEL BCSMs
23.0783GPPCustomised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4Release 17Stage 2TS
4.4.1 General Handling
The BCSM is used to describe the actions in an MSC or GMSC or VMSC during originating, forwarded or terminating calls.
The BCSM identifies the points in basic call processing when Operator Specific Service (OSS) logic instances (accessed through the gsmSCF) are permitted to interact with basic call control capabilities.
Figure 4.2 shows the components that have been identified to describe a BCSM.
Figure 4.2: BCSM Components
4.4.2 Originating Basic Call State Model (O‑BCSM)
4.4.2.1 Description of O‑BCSM
The O‑BCSM is used to describe the actions in an MSC during originating (MSC) , forwarded (MSC or GMSC) and trunk originating (MSC) calls.
When encountering a DP the O‑BCSM processing is suspended at the DP and the MSC or GMSC indicates this to the gsmSSF which determines what action, if any, shall be taken if the DP is armed. For gsmSCF initiated new calls the O‑BCSM is initially suspended at DP Collected_Info.
NOTE: The DP O_Busy also includes the ‘not reachable’ case.
Figure 4.3: Originating BCSM for CAMEL
The table below defines the different DPs which apply to mobile originating and forwarded calls and trunk originating calls.
Table 4.2: Description of O‑BCSM DPs in the MSC
|
CAMEL Detection Point: |
DP Type |
Description: |
|
DP Collected_Info |
TDP‑R, EDP-R (note 7) |
Indication that the O‑CSI is analysed, the gsmSCF has initiated a call attempt (in this case the DP is neither triggered nor reported) or additional digits have been collected. |
|
DP Analysed_Information |
TDP‑R (note 2) |
Availability of routeing address and nature of address. |
|
DP Route_Select_Failure |
TDP‑R (note 3), EDP‑N, EDP‑R |
Indication that the call establishment failed. |
|
DP O_Busy |
EDP‑N, EDP‑R |
Indication that: – a busy indication is received from the terminating party, – a not reachable event is determined from a cause IE in the ISUP Release message. |
|
DP O_No_Answer |
EDP‑N, EDP‑R |
Indication that: – an application timer associated with the O_No_Answer DP expires, – a no answer event is determined from a cause IE in the ISUP Release message. |
|
DP O_Term_Seized |
EDP‑N, EDP‑R |
Indication that the called party is being alerted. |
|
DP O_Answer |
EDP‑N, EDP‑R |
Indication that the call is accepted and answered by the terminating party. |
|
DP O_Mid_Call |
EDP‑N, EDP‑R |
Indication that a service/service feature indication is received from the originating party (DTMF – note 4, note 5). |
|
DP O_Change_Of_Position |
EDP‑N |
Indication that the originating party has changed position (note 6). |
|
DP O_Disconnect |
EDP‑N, EDP‑R |
A disconnect indication is received from the originating party or from the terminating party. |
|
DP O_Abandon |
EDP‑N, EDP‑R |
Indication that a disconnect indication is received from the originating party during the call establishment procedure. |
|
DP O_Service_Change |
EDP‑N |
Indication that the bearer service has changed. |
|
NOTE 1: The DPs are defined in ITU‑T Recommendation Q.1224 [44]. NOTE 2: For TDP‑R Analysed_Information new relationship to gsmSCF is opened. NOTE 3: DP Route_Select_Failure shall be reported as TDP‑R when there is no relationship to gsmSCF. If a relationship to gsmSCF is already open, it shall be reported as EDP‑R or EDP‑N if armed so. DP Route_Select_Failure cannot be armed as TDP-R for Trunk Originating Calls. NOTE 4: DTMF is only applicable for the Mobile Originating or Trunk Originating Call in the VMSC. DTMF is not applicable at the O_Alerting PIC. NOTE 5: Call Processing is suspended at DP O_Mid_Call if a Call Party Handling information flow is handled. However, the DP is not reported. NOTE 6: DP O_Change_Of_Position is applicable only for the Mobile Originating Call in the VMSC. NOTE 7: DP Collected_Info as a EDP-R is applicable only for Trunk Originating Calls. |
||
4.4.2.1.1 Description of the call model (PICs)
This subclause describes the call model for originating and forwarded calls. For each PIC a description can be found of the entry events, functions and exit events.
It should be noted that although the names used for PICs match those used in ITU‑T Recommendation Q.1224 [44] the specific descriptions differ.
4.4.2.1.1.1 O_Null & Authorise_Origination_Attempt_Collect_Info
Entry events:
– Disconnection and clearing of a previous call (DP O_Disconnect) or default handling of exceptions by gsmSSF/(G)MSC completed.
– Abandon event is reported from Analyse_Information or Routing and Alerting PIC.
– Exception event is reported.
– gsmSCF requests additional digits (DP CollectedInfo or DP AnalysedInfo).
Actions:
If entry event is ‘gsmSCF requests additional digits’ then MSC starts collecting additional digits.
Otherwise:
– Interface is idled.
– Mobile Originating call:
– SETUP information flow containing the dialled number is received from MS, preceeding call leg or originating exchange.
– The supplementary service "barring of all outgoing calls" is checked and invoked if necessary.
– The ODB category "barring of all outgoing calls" is checked and ODB is invoked if necessary.
NOTE: the ODB category "barring of all outgoing calls when roaming" causes the HLR to send the category "barring of all outgoing call" if the VLR is not in the HPLMN.
– CUG checks done in the originating MSC/VLR are performed.
– Information being analysed e.g. O-CSI is analysed.
– Trunk Originating call:
– The initial information flow containing the complete dialled number or an initial information package/ dialling string is received from the trunk interface.
– Any operator specific service checks done in the originating MSC are performed.
– Information being analysed e.g., TO‑CSI is analysed.
Exit events:
If entry event was ‘gsmSCF requests additional digits’ then:
– Additional digits collected.
– Inter-digit timer expires
– An exception condition is encountered. For example, collection of additional digits fails due to a lack of switch resources (e.g. no digit receivers are available) or calling party abandons call.
Otherwise:
– Originating CSI is analysed.
– Trunk Originating CSI is analysed.
– An exception condition is encountered. For this PIC, if the call encounters one of these exceptions during the PIC processing, the exception event is not visible because there is no corresponding DP. Example exception condition: Calling party abandons call.
4.4.2.1.1.2 Analyse_Information
Entry events:
– Originating CSI is analysed. (DP Collected Info).
– Trunk Originating CSI is analysed (DP Collected Info).
– Additional digits collected (DP Collected Info) in trunk originated call.
– The gsmSCF has initiated a call attempt (DP Collected_Info). In this case the DP has neither been triggered nor has it been reported.
– New routeing information is received when the Busy event (DP O_Busy), Route Select Failure event (DP Route_Select_Failure), Not Reachable event (DP O_Busy) or No Answer event (DP O_No_Answer) is reported from the Routing and Alerting PIC.
– New routeing information is received when the Disconnect event is reported from the O_Active PIC.
Actions:
– Compare the called party number with the dialled services information.
Exit events:
– Availability of routeing address and nature of address. (DP Analysed_Information).
– An exception condition is encountered (e.g. invalid number); this leads to the O_Exception PIC.
– The calling party abandons the call; this leads to the O_Abandon DP.
4.4.2.1.1.3 Routing
Entry events:
– Availability of routeing address and nature of address. (DP Analysed_Information).
Actions:
– Information is being analysed and/or translated according to dialling plan to determine routeing address.
– Routeing address being interpreted.
– Mobile Originating or forwarded call: Outgoing barring services and ODB categories not already applied are checked and invoked if necessary.
– Trunk Originating call: Any operator specific service checks in the originating MSC are performed.
Exit events:
– An alerting indication (ISUP ACM) is received from the terminating party; this leads to the O_Term_Seized DP.
– The attempt to select the route for the call fails; this leads to the Route_Select_Failure DP.
– A busy indication is received from the terminating party; this leads to the O_Busy DP.
– A not reachable indication is received from the terminating party; this leads to the O_Busy DP.
– A no reply indication is received from the terminating party or a no reply condition is determined at the MSC/ gsmSSF; this leads to the O_No_Answer DP
– An indication is received from the terminating half BCSM that the call is accepted and answered by the terminating party; this leads to O_Answer DP.
– The calling party abandons the call’ this leads to the O_Abandon DP.
– An exception condition is encountered; this leads to the O_Exception PIC.
4.4.2.1.1.4 O_Alerting
Entry events:
– Called Party is being alerted (DP O_Term_Seized).
– Continue is received in O_Mid_Call DP.
Actions:
– Call is being processed by the terminating half BCSM. Waiting for indication from terminating half BCSM that the call has been answered by terminating party.
– Send a notification to the gsmSCF if the originating party changes position and DP O_Change_Of_Position is armed.
Exit events:
– An indication is received from the terminating half BCSM that the call is accepted and answered by the terminating party; this leads to the O_Answer DP.
– A route select failure indication is received from the terminating party; this leads to the Route_Select_Failure DP.
– A busy indication is received from the terminating party; this leads to the O_Busy DP.
– A not reachable indication is received from the terminating party; this leads to the O_Busy DP.
– A no reply indication is received from the terminating party or a no reply condition is determined at the MSC/ gsmSSF; this leads to the O_No_Answer DP.
– The calling party abandons the call; this leads to the O_Abandon DP.
– An exception condition is encountered; this leads to the O_Exception PIC.
4.4.2.1.1.5 O_Active
Entry events:
– Indication from the terminating half BCSM that the call is accepted and answered by the terminating party. (DP O_Answer)
– Continue is received in O_Mid_Call DP.
Actions:
– Connection established between originating party and terminating party. Call supervision is provided.
– Send a notification to the gsmSCF if the originating party changes position and DP O_Change_Of_Position is armed.
– Send a notification to the gsmSCF if the bearer is changed due to the SCUDIF and DP O_Service_Change is armed.
– Call release is awaited.
Exit events:
– A service/service feature request is received from the originating party (DTMF) or DP O_Mid_Call is used for Call Party Handling (DP O_Mid_Call).
– A disconnection indication is received from the originating party, or received from the terminating party via the terminating half BCSM (DP O_Disconnect).
– An exception condition is encountered.
4.4.2.1.1.6 O_Exception
Entry events:
– An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIC can not be met.
Actions:
– Default handling of the exception condition is being provided. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as:
– If any relationship exists between the gsmSSF and the gsmSCF, the gsmSSF shall send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion.
– The (G)MSC/gsmSSF should make use of vendor-specific procedures to ensure release of resources within the (G)MSC/gsmSSF, so that line, trunk and other resources are made available for new calls.
Exit events:
– Default handling of the exception condition by gsmSSF/(G)MSC completed.
4.4.3 Terminating Basic Call State Model (T‑BCSM)
4.4.3.1 Description of T‑BCSM
The T‑BCSM is used to describe the actions in a GMSC and in a VMSC during terminating calls.
When encountering a DP the T‑BCSM processing is suspended at the DP and the GMSC or VMSC indicates this to the gsmSSF which determines what action, if any, shall be taken if the DP is armed.
Figure 4.4: T‑BCSM in the GMSC or VMSC
In the table below the different DPs (in the T‑BCSM) are described.
Table 4.3: Description of T‑BCSM DPs in the GMSC or VMSC
|
CAMEL Detection Point: |
DP Type |
Description: |
|
DP Terminating_Attempt_ |
TDP‑R |
Indication that the T‑CSI / VT‑CSI is analysed. |
|
DP T_Busy |
TDP‑R (note 2), EDP‑N, EDP‑R |
Indication that: – a busy indication is received from the destination exchange, – Busy event is determined in the visited MSC, – Not reachable or call establishment failure event is determined from the HLR response or upon a cause IE in the ISUP Release message. |
|
DP T_No_Answer |
TDP‑R (note 2), EDP‑N, EDP‑R |
Indication that: – an application timer associated with the T_No_Answer DP expires – a no answer event is determined from a cause IE in the ISUP Release message. |
|
DP Call_Accepted |
EDP‑N, EDP‑R |
Indication that the called party is being alerted. |
|
DP T_Answer |
EDP‑N, EDP‑R |
Call is accepted and answered by terminating party. |
|
DP T_Mid_Call |
EDP‑N, EDP‑R |
Indication that a service/service feature is received from the terminating party (DTMF – note 3, note 4). |
|
DP T_Change_Of_Position |
EDP‑N |
Indication that the terminating party has changed position (note 5). |
|
DP T_Disconnect |
EDP‑N, EDP‑R |
A disconnect indication is received from the terminating party or from the originating party. |
|
DP T_Abandon |
EDP‑N, EDP‑R |
A disconnect indication is received from the originating party during the call establishment procedure. |
|
DP T_Service_Change |
EDP‑N |
Indication that the bearer service has changed. |
|
NOTE 1: The DPs are defined in ITU‑T Recommendation Q.1224 [44]. NOTE 2: DP T_No_Answer and DP T_Busy shall be reported as TDP‑R when there is no relationship to gsmSCF. If a relationship to gsmSCF is already open, it shall be reported as EDP‑R or EDP‑N if armed so. NOTE 3: DTMF is only applicable for the VMSC but not for the GMSC. DTMF is not applicable at the T_Alerting PIC. NOTE 4: Call Processing is suspended at DP T_Mid_Call if a Call Party Handling information flow is handled. However, the DP is not reported. NOTE 5: DP T_Change_Of_Position is applicable only for the Mobile Terminating Call in the VMSC. |
||
4.4.3.1.1 Description of the call model (PICs)
This subclause describes the call model for terminating calls in the GMSC and in the VMSC. For each PIC a description can be found of the entry events, functions, information available and exit events.
It should be noted that although the names used for PICs match those used in ITU‑T Recommendation Q.1224 [44] the specific descriptions differ.
4.4.3.1.1.1 T_Null
Entry events:
– Disconnection and clearing of a previous call (DP T_Disconnect) or default handling of exceptions by gsmSSF/GMSC or VMSC completed.
– Abandon event is reported from Terminating Call Handling PIC.
– Exception event is reported.
Actions:
– Interface is idled.
– If ISUP Initial Address Message is received, the appropriate information is analysed.
– If the T‑BCSM is in the GMSC, a Send Routeing Info information flow is sent to the HLR.
– If the T‑BCSM is in the VMSC, a Send Info For Incoming Call information flow is sent to the VLR.
– If the T‑BCSM is in the GMSC:
– The supplementary services "barring of all incoming calls" and "barring of incoming calls when roaming" are checked in the HLR and invoked if necessary.
– The ODB categories "barring of all incoming calls" and "barring of incoming calls when roaming" are checked in the HLR and ODB is invoked if necessary.
– The supplementary service "CUG" is checked in the HLR and invoked if necessary.
– T‑CSI/VT‑CSI is received and analysed.
Exit events:
– Response is received from HLR or VLR and terminating CSI (if available) is analysed.
– An exception condition is encountered. For this PIC, if the call encounters one of these exceptions during the PIC processing, the exception event is not visible because there is no corresponding DP.
Example exception condition is:
– The calling party abandons call.
4.4.3.1.1.2 Terminating Call Handling
Entry events:
– Response is received from HLR or VLR and terminating CSI (if available) is analysed (DP Terminating_Attempt_Authorised).
– New routeing information is received when a Busy or not reachable event (DP T_Busy) or a No Answer event (DP T_No_Answer) is reported from the Terminating Call Handling PIC.
– New routeing information is received when a Disconnect event is reported from the T_Active PIC.
NOTE: The HLR may use MAP signalling to indicate to the GMSC before the call is extended to the destination VMSC that the terminating party is not reachable, or the destination VMSC may use telephony signalling to indicate to the GMSC after the call has been extended to the destination VMSC that the terminating party is not reachable.
Actions:
– The response from the HLR or VLR is analysed.
– Routeing address and call type are interpreted. The next route or terminating access is selected.
– The Call Forwarding supplementary service is invoked if necessary.
Exit events:
– The call is accepted and answered by terminating party; this leads to the T_Answer DP.
– An indication is received that the called party is being alerted; this leads to the Call_Accepted DP.
– An exception condition is encountered; this leads to the T_Exception PIC. Example exception conditions: the call setup to the MSC or GMSC was not successful.
– The calling party abandons the call; this leads to the T_Abandon DP.
– The terminating access is busy in the VMSC or a busy indication is received from the destination exchange in the GMSC; this leads to the T_Busy DP.
– A not reachable event detected or failure of attempt to select the route for the terminating leg in the GMSC fails or the MS cannot be reached in the VMSC; this leads to the T_Busy DP.
– The no reply timer expires; this leads to the T_No_Answer DP.
4.4.3.1.1.3 T_Alerting
Entry events:
– Called party is being alerted (DP Call_Accepted)
– Continue is received in T_Mid_Call DP.
Actions:
– Waiting for the call to be answered by terminating party.
– The Call Forwarding supplementary service is invoked if necessary.
– Send a notification to the gsmSCF if the terminating party changes position and DP T_Change_Of_Position is armed.
Exit events:
– The call is accepted and answered by terminating party; this leads to the T_Answer DP.
– An exception condition is encountered; this leads to the T_Exception PIC. Example exception conditions: the call setup to the MSC or GMSC was not successful.
– The calling party abandons the call; this leads to the T_Abandon DP.
– A busy indication (UDUB) is received from the destination exchange; this leads to the T_Busy DP.
– A not reachable event is detected or the attempt to select the route for the terminating leg in the GMSC fails or the MS cannot be reached in the VMSC; this leads to the T_Busy DP.
– The no reply timer expires; this leads to the T_No_Answer DP.
– A Call Party Handling information flow is executed; this leads to the T_Mid_Call DP.
4.4.3.1.1.4 T_Active
Entry events:
– Indication that the call is accepted and answered by the terminating party. (DP T_Answer).
– Continue is received in T_Mid_Call DP.
Actions:
– Connection established between originating party and terminating party. Call supervision is being provided.
– Send a notification to the gsmSCF if the terminating party changes position and DP T_Change_Of_Position is armed.
– Send a notification to the gsmSCF if the bearer is changed due to the SCUDIF and DP T_Service_Change is armed.
– Wait for call release.
Exit events:
– A disconnection indication is received from the terminating party, or received from the originating party via the originating half BCSM; this leads to the T_Disconnect DP.
– An exception condition is encountered. In addition to the specific examples listed above, exception events include any type of failure that means that the normal exit events for a PIC cannot be met.
– A service/service feature request is received from the called party (DTMF) or a Call Party Handling information flow is executed; this leads to the T_Mid_Call DP.
4.4.3.1.1.5 T_Exception
Entry events:
– An exception condition is encountered. In addition to the specific examples listed above, exception events include any type of failure, which means that the normal exit events for PIC cannot be met.
Actions:
– Default handling of the exception condition is being provided. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as:
– If any relationship exists between the gsmSSF and the gsmSCF, the gsmSSF shall send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion.
– The GMSC or VMSC / gsmSSF should make use of vendor-specific procedures to ensure release of resources within the GMSC or VMSC / gsmSSF, so that line, trunk and other resources are made available for new calls.
Exit events:
– Default handling of the exception condition by gsmSSF/GMSC is completed.
4.4.4 Rules for Implicit Disarming of Event Detection Points
The tables below give the rules for implicit disarming of event detection points.
Implicit EDP disarming rules are specified in the tables below for Originating BCSM and Terminating BCSM respectively. Each table specifies which EDP’s shall be disarmed (i.e. MonitorMode set to Transparent) if/when each EDP is encountered, irrespective of the EDP’s Monitor Mode (Transparent, Notify And Continue, or Request).
When EDPs armed with MonitorMode ‘Request’ (EDP‑Rs) are encountered, any implicit EDP disarming shall take place before reporting the EDP and transiting the gsmSSF to the Waiting_For_Instruction state (if not already suspended in the Waiting_For_Instruction state).
If the BCSM has encountered DP O/T_Answer then an originator release must be detected as a DP O/T_Disconnect.
The table entry ‘X’ means that if the DP is encountered (independently of arming and reporting to the gsmSCF) the marked DP is implicitly disarmed.
It shall be possible to rearm explicitly an implicitly disarmed DP, e.g. for follow on call.
Table 4.4: Implicit disarmed DPs in the O‑BCSM
|
Encountered DP |
Implicit disarmed DPs |
|||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Collected_Info |
Route_Select_Failure |
O_Busy |
O_No_Answer |
O_Answer |
O_Mid_Call Leg 1 |
O_Disconnect Leg 1 |
O_Disconnect any other Leg |
O_Abandon |
O_Term_Seized |
O_Change_Of_Position |
O_Service_Change |
|
|
Collected_Info |
X |
|||||||||||
|
Route_Select_Failure |
X |
X |
X |
X |
X |
X |
||||||
|
O_Busy |
X |
X |
X |
X |
X |
X |
||||||
|
O_No_Answer |
X |
X |
X |
X |
X |
X |
||||||
|
O_Answer |
X |
X |
X |
X |
X |
X |
||||||
|
O_Mid_Call Leg 1 (note 1) |
X |
|||||||||||
|
O_Disconnect Leg 1 |
X |
X |
X |
X |
X |
|||||||
|
O_Disconnect any other Leg |
X |
X |
X |
X |
X |
X |
||||||
|
O_Abandon |
X |
X |
X |
X |
X |
X |
||||||
|
O_Term_Seized |
X |
|||||||||||
|
O_Change_Of_Position (note 1) |
X |
|||||||||||
|
O_Service_Change (note 1) |
X |
|||||||||||
|
Note 1 If the Automatic Rearm IE was present in the Request Report BCSM Event information flow for the O_Change_Of_Position DP, O_Service_Change or the O_Mid_Call DP and armed as EDP‑N, then the DP shall be automatically rearmed by the gsmSSF when it is encountered. |
||||||||||||
Table 4.5: Implicit disarmed DPs in the T‑BCSM
|
Encountered DP |
Implicit disarmed DPs |
|||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
T_Busy |
T_No_Answer |
T_Answer |
T_Mid_Call Leg 2 |
T_Disconnect Leg 1 |
T_Disconnect Leg 2 |
T_Abandon |
Call_Accepted |
T_Change_Of_Position |
T_Service_Change |
|
|
T_Busy |
X |
X |
X |
X |
X |
X |
X |
X |
||
|
T_No_Answer |
X |
X |
X |
X |
X |
X |
X |
X |
||
|
T_Answer |
X |
X |
X |
X |
X |
|||||
|
T_Mid_Call Leg 2 (note 1) |
X |
|||||||||
|
T_Disconnect Leg 1 |
X |
X |
||||||||
|
T_Disconnect Leg 2 |
X |
X |
X |
X |
X |
X |
X |
X |
||
|
T_Abandon |
X |
X |
||||||||
|
Call_Accepted |
X |
|||||||||
|
T_Change_Of_Position (note 1) |
X |
|||||||||
|
T_Service_Change (note 1) |
X |
|||||||||
|
Note 1 If the Automatic Rearm IE was present in the Request Report BCSM Event information flow for the T_Change_Of_Position DP, T_Service_Change or the T_Mid_Call DP and armed as EDP‑N, then the DP shall be automatically rearmed by the gsmSSF when it is encountered. |
||||||||||
4.4.5 BCSM Modelling of Call Scenarios
This subclause describes how the BCSMs defined above are used to model CS call scenarios. For each scenario the used and unused BCSMs involved in the call are shown.
In some cases these models may have an allocation to physical nodes different from that shown. However, the physical separation of the logical functions shown shall not impact the modelling. This subclause describes the call scenarios without optimal routeing. If optimal routeing is invoked then the physical configurations may be different from those shown, but the modelling is not changed.
CAMEL may be applied simultaneously and independently for each subscriber involved in a call. This is not shown in these scenarios.
Subscribers other than those being served by CAMEL may be either PSTN subscribers, other subscribers or any other addressable subscriber.
4.4.5.1 Mobile Originated Call
For the call from A to B, an instance of the O‑BCSM will be created in the MSC (labelled "O(A‑B)"). If the A‑party has an active O‑CSI or D‑CSI, or the MSC has an active N‑CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship with gsmSCF(1) shall be established.
Figure 4.5: BCSM Scenario for Mobile Originated Call
4.4.5.2 Mobile Terminated Call at the GMSC or VMSC
For the call from A to B, an instance of the T‑BCSM will be created in the GMSC (labelled "T(A‑B)") and an instance of the T‑BCSM will be created in the VMSC (labelled "T(A‑B)").
If the B‑party has an active T‑CSI in the GMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC and the gsmSCF(1) shall be established. If the B‑party has an active VT‑CSI in the VMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the VMSC and the gsmSCF(2) shall be established.
The relationships with gsmSCF (1) and gsmSCF(2) may exist simultaneously. The two gsmSCF endpoints of the relationships are treated independently.
The nodes gsmSCF (1) and gsmSCF (2) may be the same or different entities.
Figure 4.6: BCSM Scenario for Mobile Terminated Calls at the GMSC or VMSC
4.4.5.3 Call Forwarding at the GMSC or VMSC
If the B‑party has an active T‑CSI in the GMSC or VT‑CSI in the VMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(1) shall be established.
Following processing at the GMSC or VMSC the call will be extended to the VMSC serving the B‑party. This VMSC may be physically integrated with the GMSC.
A new call leg to a "C" party shall be created if:
– a Call Forwarding supplementary service or Call Deflection supplementary service forwards the call to C. An instance of the O‑BCSM O(B‑C) will be created for the forwarding leg. If the B‑party has an active O‑CSI or D‑CSI in the GMSC or VMSC, or the GMSC or VMSC has an active N‑CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(2) shall be established. If the GMSC or VMSC receives the ‘Suppress O-CSI’ parameter, then O‑CSI shall not be used for the forwarding leg or deflecting leg; or
– a CAMEL service in a control relationship with T(A‑B) performs a CAMEL-based call forwarding by using a Connect information flow. An instance of the O‑BCSM O(B‑C) will be created for the forwarding leg. If the B‑party has an active O‑CSI or D‑CSI in the GMSC or VMSC, or the GMSC or VMSC has an active N‑CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(2) shall be established. The O‑CSI shall be used for the forwarding leg only if the last Connect information flow includes the "O‑CSI applicable" flag.
The relationship with gsmSCF (1) and the relationship with gsmSCF(2) may exist simultaneously. The two relationships are treated independently at the GMSC. The instance of the BCSM T(A‑B) and the instance of the BCSM O(B‑C) are linked by an internal interface which is assumed to behave in a similar way to an ISUP interface.
The nodes gsmSCF (1) and gsmSCF (2) may be the same or different physical entities.
Figure 4.7: BCSM Scenario for Call Forwarding at the GMSC or VMSC
4.4.5.4 gsmSCF Initiated Call
When the gsmSCF wishes to originate a new call, the gsmSCF establishes communication with the network using CAP signalling. When the gsmSCF wishes to originate a new leg within an existing call, the gsmSCF uses the already established communication with the gsmSSF. It sends an Initiate Call Attempt information flow which shall contain the address of the called party. Afterwards the gsmSCF shall instruct the gsmSSF to continue with the call processing. The MSC constructs an ISUP Initial Address Message using the parameters received from the gsmSCF and sends it to the destination exchange.
The O‑BCSM for the gsmSCF initiated call to B (labelled "O(M‑B)") is invoked on request of the gsmSCF. A control relationship with gsmSCF (1) is created for the initiation of a new call.
NOTE: The term ISUP is used to denote UNI or NNI signalling system used in a given network.
Figure 4.8: BCSM Scenario for gsmSCF Initiated New Call
4.4.5.5 Trunk Originated Call
For the call from A to B, an instance of the O‑BCSM will be created in the MSC (labelled "O(A‑B)"). If the MSC has an active TO‑CSI for the trunk on which the call has originated, or an active N-CSI, and the trigger criteria (if present) are fulfilled, then a CAMEL control relationship with gsmSCF(1) shall be established.
Figure 4.4.5.5.1: BCSM Scenario for Trunk Originated Call
4.4.6 Leg Handling
A call may consist of several call parties with each party connected to the call, e.g. there may be a calling party and several called parties.
From a call handling point of view it is necessary to distinguish between a leg, which is a concept internal to the call handling model, and a connection, which is the external link to the party. A connection to the call party will be set up using telephony (e.g. ISUP) or radio access signalling. The outgoing leg already exists when the connection is set up. On the other hand, if a connection is released, e.g. because the destination user is busy, the leg still exists, and the gsmSCF can send a Connect Information Flow to connect this leg to another call party.
4.4.6.1 Leg is created
For the purposes of the formal description, one or more legs are created in the following cases:
– When a call is to be established, i.e. when an incoming Setup or ISUP IAM is being handled or when a call is to be forwarded, the incoming leg (leg1) and the outgoing leg (leg2) are created before the first CS_gsmSSF process is invoked for that call in this MSC. In particular, this applies before the Call Control Function (CCF) sends DP_Collected_Info (for originating, forwarded or deflected calls) or DP_Terminating_Attempt_Authorised (for terminating calls) to the CS_gsmSSF process;
– When the CS_gsmSSF process receives an Initiate Call Attempt Information Flow, an outgoing leg is created.
4.4.6.2 Leg continues to exist
For the purposes of the formal description, a leg continues to exist in the following cases:
– The CCF sends any DP to the CS_gsmSSF the leg will continue to exist at least until the CS_gsmSSF instructs the CCF to continue its processing for the leg;
– A connection to a called party is not successful and the gsmSCF sends a new Connect Information Flow for that leg;
– A called party releases her connection and the gsmSCF sends a new Connect Information Flow for that leg;
– The CS_gsmSSF processes either of the Call Party Handling Information Flows Move Leg and Split Leg;
4.4.6.3 Leg is released
Before a leg is released the corresponding connection is released. All outstanding reports for the leg are sent to the gsmSCF and the corresponding call records are closed.
For the purposes of the formal description, a leg ceases to exist when any of the following events occurs:
– The calling party releases the connection, the CCF sends a DP to the CS_gsmSSF and the CCF receives Int_Continue or Int_Continue_With_Argument from the CS_gsmSSF process;
– A connection to a called party is not successful (DPs Route_Select_Failure, O_Busy, O_No_Answer, T_Busy and T_No_Answer), the CCF sends a DP to the CS_gsmSSF and the CCF does not receive Int_Connect for that outgoing leg from the CS_gsmSSF;
– The called party releases her connection, the CCF sends a DP to the CS_gsmSSF and the CCF does not receive Int_Connect for that outgoing leg from the CS_gsmSSF;
– The CCF receives Int_Disconnect_Leg from the CS_gsmSSF;
– The timer Tcp expires for a leg and the condition "Release if duration exceeded" is true for that leg;
– The CCF receives Int_Release_Call from the CS_gsmSSF.
If a call is released, either on instruction from the CS_gsmSSF or on normal call handling without any CAMEL interaction, then all legs involved in the call cease to exist.
4.4.6.4 Leg is moved
A leg can be moved from one call segment (source call segment) to another call segment (target call segment) as a result of a Move Leg or Split Leg information flow. When the CSA_gsmSSF receives a Split Leg Information Flow it creates a new call segment and moves the specified leg into this call segment. When the CSA_gsmSSF receives a Move Leg Information Flow it moves the specified leg into call segment 1.
A leg is no longer contained in the source call segment when the source CS_gsmSSF receives Int_Export_Leg_ack from the CCF.
A leg is contained in the target call segment when the target CS_gsmSSF receives Int_Import_Leg_ack from the CCF.