Destination B (Busy Called Party in Completion of Calls to Busy Subscriber)

Description

Destination B is a role-based identifier used in 3GPP supplementary-service specifications to denote the called party of a call attempt that fails because that party is busy. The term is defined in the vocabulary of the Completion of Calls to Busy Subscriber (CCBS) service, whose stage 1 requirements are in TS 22.093, stage 2 procedures in TS 23.093, stage 3 mobile-station and network protocols in TS 24.093, and the IMS variant in TS 24.642. Destination B is not a network node: it is the logical endpoint of the original call set-up, and the phrase 'MSC B, VLR B and HLR B' denotes the visited and home network entities that serve that endpoint when it is a GSM mobile subscriber. The naming convention mirrors subscriber A (the calling party) and its serving entities MSC A, VLR A and HLR A.

The concept exists because CCBS requires the network to remember a failed call attempt and to complete it later without the calling subscriber having to redial. When subscriber A dials Destination B, the call is routed towards the B-party's serving MSC. If Destination B is already engaged in another call, MSC B/VLR B returns a busy indication rather than a normal alerting or answer event. If subscriber A has subscribed to CCBS and the busy condition is detected, MSC A/VLR A offers the CCBS option to A's terminal. On acceptance, a CCBS request is sent towards HLR B, which stores it in a CCBS queue associated with Destination B. From that moment the network, not the user, is responsible for monitoring Destination B.

When Destination B becomes idle again — for example when the ongoing call is released — MSC B/VLR B detects the transition to the idle state and informs HLR B. HLR B then checks its CCBS queue and, if a request from subscriber A is pending, notifies MSC A/VLR A. MSC A alerts subscriber A with a CCBS recall indication and starts a retention timer. If subscriber A accepts the recall within the timer, a new call set-up towards Destination B is initiated automatically; if A does not respond, the CCBS request is cancelled and the entry is removed from the queue. The whole procedure is defined as a state model in TS 23.093, with states such as request, monitoring, recall and completion, and with timers that bound each phase so that stale requests do not accumulate indefinitely.

Because Destination B is a role rather than an element, the same term is reused across access technologies. In a GSM/UMTS circuit-switched network, Destination B is served by an MSC/VLR and registered in an HLR, and the CCBS signalling uses MAP operations between HLR B and MSC A. In an IMS or NGN environment, TS 24.642 specifies how CCBS and CCNR (Completion of Communications by No Reply) are realised using SIP and the IM CN subsystem, where the equivalent of HLR B is the home subscriber server and the equivalent of MSC B is the serving CSCF. The abstract notion of Destination B therefore survives the migration from SS7-based circuit switching to all-IP session control.

For engineers, Destination B matters because it is the anchor for a family of 'completion of communications' services — CCBS, CCNR and their IMS counterparts — and because it illustrates how 3GPP separates logical roles from physical entities. Understanding which node holds the queue (HLR B), which node detects the free condition (MSC B/VLR B) and which node performs the recall (MSC A/VLR A) is essential when troubleshooting why a CCBS request was never completed, why a recall timer expired, or why a subscriber received a recall for a destination that had already become reachable by other means.

Purpose & Motivation

Destination B exists as a defined term because the CCBS service needs an unambiguous way to refer to the party whose busy state triggers the whole procedure. Before CCBS, a calling subscriber who reached a busy destination had only one option: hang up and redial manually, repeatedly, until the destination became free. This wasted user effort, generated redundant signalling traffic, and gave no guarantee that the retry would succeed. CCBS was created so that the network could take over the retry responsibility: the caller requests completion once, and the network monitors Destination B until it becomes idle.

Defining Destination B as a role, rather than naming a specific node, was a deliberate architectural choice. The busy condition is detected in the B-party's serving network, the queue is held in the B-party's home register, and the recall is delivered in the A-party's serving network. A single term that abstracts the called party allows the stage 1, stage 2 and stage 3 specifications to describe the service independently of whether the destination is a GSM mobile, a fixed-line subscriber reached through an interworking unit, or an IMS user. It also allows the same service logic to be reused when the underlying transport changes from ISUP/MAP to SIP.

The term also solves a documentation problem. CCBS procedures involve several distinct network elements that all relate to the same called party, and without a collective label the specifications would have to enumerate 'the MSC serving the called party, the VLR serving the called party and the HLR of the called party' at every occurrence. The Destination B notation, together with the derived labels MSC B, VLR B and HLR B, makes the procedures readable and makes the symmetry with subscriber A explicit. This convention has been carried forward unchanged through every release from Rel-4 to Rel-19, which is itself evidence that the abstraction remains valid even as the underlying networks evolve towards IMS and 5G.