EventReportBCSM Received After ApplyChargingReport

The following example scenario describes the message sequence used when a subscriber hangs up and the Mobile Switching Center (MSC) sends the EventReportBCSM operation to disconnect the call after the ApplyChargingReport operation.

The CAP2 rules for sending ApplyChargingReport and EventReportBCSM(oDisconnect) operations are:

  • If oDisconnect is armed as notify, send EventReportBCSM first.
  • If oDisconnect is armed as interrupted, send ApplyChargingReport first.

However, CCF supports the following scenario in which the Mobile Switching Center sends the ApplyChargingReport operation first even though oDisconnect is armed as notify on both legs.

Figure 1 shows the message sequence used from when the caller hangs up. See actions 1 to 18 of Caller Disconnects for a description of the messages from initial call set up to when the caller hangs up.

Figure 1. EventReportBCSM Received After ApplyChargingReport Message Flow
The following actions are taken when a caller hangs up after 12.5 minutes of call-time and the MSC sends the ApplyChargingReport operation and then sends an EventReportBCSM operation to disconnect the call:
  1. The caller hangs up after a total talk time of 12.5 minutes (7500 deciseconds) and the MSC sends a TCAP CONTINUE(ApplyChargingReport(7500 ds, not active)) message to MATRIXX Engine. The end-of-transaction timer starts.
  2. The MSC sends a TCAP CONTINUE(EventReportBCSM(oDisconnect(1,N)) message to MATRIXX Engine to disconnect the caller:
    • The end-of-transaction timer restarts.
    • MATRIXX Engine notes that the caller has disconnected and commits the remaining cost of 180 seconds call time.
    • When the end-of-transaction timer expires, the session is released and a pre-arranged end is assumed on MATRIXX Engine.