7 Description of CAMEL BCSMs

03.783GPPCcustomized Applications for Mobile network Enhanced Logic (CAMEL) Phase 2Release 1998Stage 2TS

7.1 General Handling

The BCSM is used to describe the actions in an MSC/GMSC 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 2 shows the components that have been identified to describe a BCSM.

Figure 2: BCSM Components

7.2 Originating Basic Call State Model (O-BCSM)

7.2.1 Description of O-BCSM

The O-BCSM is used to describe the actions in an MSC during originating (MSC) or forwarded (MSC or GMSC) calls.

When encountering a DP the O-BCSM processing is suspended at the DP and the MSC/GMSC indicates this to the gsmSSF which determines what action, if any, shall be taken in case the DP is armed.

Figure 3: Originating BCSM for CAMEL

The following table defines the different DPs which apply to mobile originating and forwarded calls.

Table 1: Description of O-BCSM DPs in the MSC

CAMEL Detection Point:

DP Type

Description:

DP2 Collected_Info

TDP-R

Indication that the O-CSI is analysed.

DP 4 Route_Select_Failure

EDP-N, EDP-R

Indication that the call establishment failed

DP 5 O_Busy

EDP-N, EDP-R

Indication that:

– a busy indication is received from the terminating party,

– a not reachable event is determined upon a cause IE in the ISUP release message.

DP6 O_No_Answer

EDP-N, EDP-R

Indication that an application timer associated with the O_No_Answer DP expires

DP7 O_Answer

EDP-N, EDP-R

Indication that the call is accepted and answered by the terminating party.

DP9 O_Disconnect

EDP-N, EDP-R

A disconnect indication is received from the originating party or from the terminating party.

DP 10 O_Abandon

EDP-N

Indication that a disconnect indication is received from the originating party during the call establishment procedure

NOTE: the DPs 2, 4, 5, 6, 7, 9, 10 are defined in ITU-T Q.1214 ([6]).

7.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 Q.1214 [6] the specific descriptions differ.

7.2.1.1.1 O_Null & Authorise_Origination_Attempt_Collect_Info

Entry events:

– Disconnection and clearing of a previous call (DP9 – O_Disconnect) or default handling of exceptions by gsmSSF/(G)MSC completed.

– Abandon event is reported from Analyse, Routing and Alerting PIC.

– Exception event is reported.

Functions:

– Interface is idled.

– Originating call: SETUP message containing the dialled number is received from MS.

– Originating call: The supplementary service "barring of all outgoing calls" is checked and invoked if necessary.

– Originating call: 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.

– Originating call: CUG checks done in the originating MSC/VLR are performed.

– Information being analysed e.g., O-CSI is analysed.

Exit events:

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

7.2.1.1.2 Analyse, Routing & Alerting

Entry events:

– Originating CSI is analysed. (DP2 – Collected Info).

– Busy event, Route Select Failure event event or No Answer event is reported from Analyse Routing and Alerting PIC.

– Disconnect event is reported from O_Active PIC.

Functions:

– Information being analysed and/or translated according to dialling plan to determine routeing address.

– Routeing address being interpreted.

– Originating call: Outgoing barring services and ODB categories not already applied are checked and invoked if necessary.

– Call is being processed by the terminating half BCSM. Continued processing of call setup (e.g., ringing) is taking place. Waiting for indication from terminating half BCSM that the call has been answered by terminating party.

Exit events:

– Indication from the terminating half BCSM that the call is accepted and answered by terminating party. (DP7 – O_Answer)

– An exception condition is encountered – this leads to the O_Exception PIC.

– Calling party abandons the call- this leads to the O_Abandon 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.

– Attempt to select the route for the call fails – this leads to the Route_Select_Failure DP.

– If the no reply timer expires and DP O_No_Answer is armed – this leads to the O_No_Answer DP.

7.2.1.1.3 O_Active

Entry events:

– Indication from the terminating half BCSM that the call is accepted and answered by the terminating party. (DP7 – O_Answer)

Functions:

– Connection established between originating party and terminating party. Call supervision is provided.

– Call release is awaited.

Exit events:

– A disconnection indication is received from the originating party, or received from the terminating party via the terminating half BCSM. (DP9 – O_Disconnect)

– An exception condition is encountered.

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

Functions:

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

7.3 Terminating Basic Call State Model (T-BCSM)

7.3.1 Description of T-BCSM

The T-BCSM is used to describe the actions in a GMSC during terminating calls.

When encountering a DP the T-BCSM processing is suspended at the DP and the GMSC indicates this to the gsmSSF which determines what action, if any, shall be taken in case the DP is armed.

Figure 4: T-BCSM in the GMSC

In the following table the different DPs (in the T-BCSM) are described.

Table 2: Description of T-BCSM DPs in the GMSC

CAMEL Detection Point:

DP Type

Description:

DP12 Terminating_Attempt_Authorised

TDP-R

Indication that the T-CSI is analysed.

DP 13 T_Busy

EDP-N, EDP-R

Indication that:

– a busy indication is received from the destination exchange,

– Not reachable or call establishment failure event is determined from the HLR response or upon a cause IE in the ISUP release message.

DP 14 T_No_Answer

EDP-N, EDP-R

Indication that an application timer associated with the T_No_Answer DP expires

DP15 T_Answer

EDP-N, EDP-R

Call is accepted and answered by terminating party

DP17 T_Disconnect

EDP-N, EDP-R

A disconnect indication is received from the terminating party or from the originating party.

DP 18 T_Abandon

EDP-N

A disconnect indication is received from the originating party during the call establishment procedure

NOTE: The DPs 12, 13, 14, 15, 17, 18 are defined in ITU-T Q.1214 ([6]).

7.3.1.1 Description of the call model (PICs)

This subclause describes the call model for terminating calls in the GMSC. 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 Q.1214 [6] the specific descriptions differ.

7.3.1.1.1 T_Null

Entry events:

– Disconnection and clearing of a previous call (DP 17) or default handling of exceptions by gsmSSF/GMSC completed.

– Abandon event is reported from Terminating Call Handling PIC ;

– Exception event is reported.

Functions:

– Interface is idled.

– ISUP_IAM is received, the appropriate information is analysed.

– Send_Routeing_Info information flow is sent to HLR.

– The supplementary services "barring of all incoming calls" and "barring of incoming calls when roaming" are checked and invoked if necessary.

– The ODB categories "barring of all incoming calls" and "barring of incoming calls when roaming" are checked and ODB is invoked if necessary.

– The supplementary service "CUG" is checked and invoked if necessary.

– T-CSI is received and analysed.

Exit events:

– Response is received from HLR 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:

– Calling party abandons call.

7.3.1.1.2 Terminating Call Handling

Entry events:

– Response is received from HLR and terminating CSI (if available) is analysed. (DP 12 Terminating_Attempt_Authorised),

– Busy event or No Answer event is reported from Terminating Call Handling PIC,

– Disconnect event is reported from T_Active PIC.

– The terminating party is not reachable.

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.

Functions:

– The response from HLR is analysed.

– Routeing address and call type being interpreted. The next route is being selected.

– The terminating party is being alerted. Waiting for the call to be answered by terminating party.

– The GSM supplementary service call forwarding is invoked if necessary.

Exit events:

– Call is accepted and answered by terminating party.

– An exception condition is encountered – this leads to the T_Exception PIC. Example exception conditions: the call setup to the MSC/GMSC was not successful.

– Calling party abandons the call – this leads to the T_Abandon DP.

– A busy indication is received from the destination exchange – this leads to the T_Busy DP.

– Not reachable event detected or failure of attempt to select the route for the terminating leg – this leads to the T_Busy DP.

– If no reply timer expires and DP T_No_Answer is armed – this leads to the T_No_Answer DP.

7.3.1.1.3 T_Active

Entry events:

– Indication that the call is accepted and answered by the terminating party. (DP15 – T_Answer)

Functions:

– Connection established between originating party and terminating party. Call supervision is being provided.

– Call release is awaited.

Exit events:

– A disconnection indication is received from the terminating party, or received from the originating party via the originating half BCSM. (DP17 – T_Disconnect)

– An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure that means that the normal exit events for a PIC can not be met.

7.3.1.1.4 T_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 PIC cannot be met.

Functions:

– 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 send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion

– The GMSC/gsmSSF should make use of vendor-specific procedures to ensure release of resources within the GMSC/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 completed.

7.4 Rules for Implicit Disarming of Detection Points

The following tables give the rules for implicit disarming of event detection points.

The table entry ‘X’ means that if one DP occurs (independently of arming and reporting to the gsmSCF) the marked one is implicitly disarmed.

It shall be possible to rearm explicitly an implicitly disarmed DP, e.g. for follow on call.

Table 3: Implicit disarmed DPs in the O-BCSM

Encountered DP

Implicit disarmed DPs

DP4

DP 5

DP 6

DP 7

DP 9
leg 1

DP 9
leg 2

DP 10

DP4 Route_Select_Failure

X

X

X

X

X

DP5 O_Busy

X

X

X

X

X

DP6 O_No_Answer

X

X

X

X

X

DP7 O_Answer

X

X

X

X

X

DP9 O_Disconnect leg 1

X

X

DP9 O_Disconnect leg 2

X

X

X

X

X

DP10 O_Abandon

X

X

Table 4: Implicit disarmed DPs in the T-BCSM

Encountered DP

Implicit disarmed DPs

DP 13

DP 14

DP 15

DP 17
leg 1

DP 17
leg 2

DP 18

DP13 T_Busy

X

X

X

X

DP14 T_No_Answer

X

X

X

X

DP 15 T_Answer

X

X

X

X

DP 17 T_Disconnect leg 1

X

X

DP 17 T_Disconnect leg 2

X

X

X

X

DP18 T_Abandon

X

X

7.5 BCSM Modelling of Call Scenarios

This subclause describes how the BCSMs defined above are used to model GSM 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 logic functions shown shall not impact the modelling. This subclause describes the call scenarios without optimal routeing. If optimal routeing is invoked the physical configurations may be different from those shown, but the modelling is not changed.

CAMEL may be applied simultaneously and independently for each GSM 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 GSM subscribers or any other addressable subscriber.

7.5.1 Mobile Originated Call

The O-BCSM for the call from A to B (labelled "O(A-B)") is invoked if the A-party has an active O-CSI. A control relationship with gsmSCF (1) will be created.

Figure 5: BCSM Scenario for Mobile Originated Call

7.5.2 Mobile Terminated Call

The T-BCSM for the call from A to B (labelled "T(A-B)") is invoked if the B-party has an active T-CSI. A control relationship with gsmSCF (1) will be created.

Figure 6: BCSM Scenario for Mobile Terminated Calls

7.5.3 Call Forwarding at the GMSC

The T-BCSM for the call from A to B (labelled "T(A-B)") is invoked if the B-party has an active T-CSI. A control relationship with gsmSCF (1) will be created.

A new call leg to a "C" party is created if:

– a GSM call forwarding supplementary service forwards the call to C. In this case O-BCSM O(B-C) is always invoked for the forwarding party if an O-CSI has been received by the GMSC from the HLR; or

– a CAMEL service in a control relationship with T(A-B) performs a CAMEL-based call forwarding by using a Connect information flow containing the forwarding information. In this case O-BCSM O(B-C) is only invoked for the forwarding party if an O-CSI has been received by the GMSC from the HLR and " O-CSI Applicable" flag is contained in the Connect information flow.

A control relationship with gsmSCF (2) will be created.

The relationships with gsmSCF (1) and gsmSCF(2) may exist simultaneously. The two relationships are treated independently at the GMSC. The BCSM T(A-B) and 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 7: BCSM Scenario for Call Forwarding at the GMSC

7.5.4 Call Forwarding at the MSC

The T-BCSM for the call from A to B (labelled "T(A-B)") is invoked if the B-party has an active T-CSI. A control relationship with gsmSCF (1) will be created. Following processing at the GMSC the call will be extended to the MSC serving the B-party. This MSC may be physically integrated with the GMSC, but it is shown as being separate in the diagram below.

If a GSM call forwarding supplementary service acting at the MSC forwards the call to C, a new call leg to C is established. If the B-party has an active O-CSI, the BCSM O(B-C) is invoked. A control relationship with gsmSCF (2) will be created.

The relationships with gsmSCF (1) and gsmSCF(2) may exist simultaneously.

The nodes gsmSCF (1) and gsmSCF (2) may be the same or different physical entities.

Figure 8: BCSM Scenario for Call Forwarding at the MSC