AZQ voice-call state and event determination

Each point is for an input, each [Event] tells our determined output state/event.

Outgoing Calls

(1) Call setup/origination state from idle

  • New Chipset CALL_EVENT_ORIG (voice) while call_idle
      • [Event] “Call Initiation”
      • 1.1 L3 CC Alerting
        • [Event] “Call Setup [duration]” (call setup success)
        • Go to state 2
      • 1.2 Chipset CALL_EVENT_CONNECT (normally comes at L3 CC Connect Acknowledge and this sometimes come before/without L3 CC Alerting if the other side picks-up very quickly like some IVRs)
        • [Event] “Call Established”
        • Go to state 2
      • 1.3 Chipset CALL_EVENT_END
        • Determine call end cause in (3) (“Call End: User Ended” or Call Block)
        • END
      • 1.4 Call setup timed-out
        • Hangup call
        • [Event] Call Setup timed-out
        • END

(2) Post-Alerting state

  • 2.1 Chipset CALL_EVENT_CONNECT (normally comes at L3 CC Connect Acknowledge)
    • [Event] “Call Established”
  • Chipset CALL_EVENT_END
    • Determine call end cause in (3) (“Call End: User Ended” or Call Drop)
    • END
  • 2.3 Call duration completed successfully
    • Hangup call
    • [Event] “Call End”

(3) Determine call-end cause

  • 3.1 If chipset event tells that this was commanded by the local user - then [Event] “Call End: User ended” call
  • 3.2 If we DID NOT received a L3 CC Disconnect - then this would result in a FAILURE (“Call Drop” - if we already got a L3 CC Alerting OR “Call Block” otherwise) - comes from the 2 cases below:
    • 3.2.1 The Access Stratum (RR or RRC) commanded us to release the channel (RR Channel Release or RRC_Connection_Release) from some internal communication/settings problem OR that the base station did not receive our communication for a while/timeout (like Measurement reports did not reach it) - for example 3GPP TS 44.018: 3.4.13.2.2 - or various other cases.
    • 3.2.2 We encounterd a RADIO_LINK_FAILURE or the like that the chip lost the radio connection to the network.
  • 3.3 If we received a L3 CC Diconnect message - check if its cause tells an error/problem or if it’s a normal release, or from the user on the other side.
    • If the disconnect cause tells an error/problem then signal a “Call Block” - if no L3 CC Alerting was received yet - or “Call Drop” otherwise - and include the L3 CC “cause” and “location” parts of the L3 message.
    • For a full list of CC Disconnect Causes - please refer to 3GPP TS 24.008 table 10.5.123 and also Annex H that explains the “UMTS specific cause values for call control”.

(4) Voice Call KPI Comparision

Below is Google Sheets listing voice call events with the corresponding L3 Message and common voice KPIs calculation

Voice Call KPI