Summary

  • RFC 3753 treated “handover” as a family of events, not one self-explanatory operation. It described five mostly independent ways to classify control and timing, then separately defined the scope of a move.
  • “Fast,” “smooth” and “seamless” did not promise the same result. The first emphasized latency, the second packet loss, and the third a service change that a particular application or user would notice.

A handover needed more than one adjective

A phone moves from one access point to another. The radio link changes. A router may or may not change. The network may prepare a route before the move, or react after it. The mobile may choose the moment, supply measurements, or simply follow a network decision. Packets can pause, disappear, or arrive through a path whose security properties differ from the old one.

Calling all of this “a handover” is convenient until two designs are compared. One engineer may mean a Layer 2 switch between access points; another may mean a new IP attachment. A product team may call a transition “fast” because traffic resumes quickly, while an application loses packets. A dashboard may mark it “seamless” even though a security downgrade would matter to the user.

RFC 3753, Mobility Related Terminology, tried to make those conversations more exact. Published as an Informational RFC in June 2004, it grew out of the IETF Seamoby Working Group—whose remit joined context transfer, handoff candidate discovery and dormant-mode host alerting. Its authors hoped other mobility groups could use the vocabulary too. They also said plainly that the document did not intend to invent terminology or settle every definition. It was a collaborative first step, open to correction. RFC 3753, abstract and §1

That modest status is part of the history. The RFC offered a shared coordinate system; it did not standardize a handoff procedure, require an implementation to use every label, or prove that working groups adopted the glossary consistently.

Five control questions, not one “handover type”

RFC 3753 said that five handover classifications were “mostly independent” and that each handover should be classifiable along each. The phrase matters: these were dimensions to describe a case, not five competing protocol designs.

Question RFC 3753’s distinction
Who makes the first decision? Mobile-initiated or network-initiated
Who has primary control? Mobile-controlled or network-controlled
Who supplies useful measurements? Mobile-assisted, network-assisted or unassisted
From which side does preparation or initiation come? Push via the previous access router, or pull via the new one
Was advance signaling possible? Planned or unplanned

The first two questions are easy to collapse and important not to. A mobile can make the initial decision while the network retains primary control over execution. The RFC’s third distinction concerns assistance: measurements from the mobile may inform an access router’s decision; the access network may instead collect information for the mobile; or neither side may assist the other. The text even allows both mobile and router to measure and decide.

Push and pull describe another relationship: whether preparation is initiated by, or routed through, the previous access router (PAR) or the new access router (NAR). Planned and unplanned describe whether signaling can happen before the mobile connects to the new router. A planned move may permit an early temporary tunnel; an unexpected one has no such advance exchange.

These labels answer different questions. “Network-initiated” does not tell us whether the mobile or network controls the process. “Mobile-assisted” does not tell us which router starts preparation. “Planned” does not say that the move succeeds. The five-part description resists the temptation to compress decision-maker, controller, information source, signaling direction and timing into one word. RFC 3753, §4.2

The RFC separately classified the scope of a move: Layer 2, within one access router, within an access network, across access networks, or across technologies. It also distinguished horizontal from vertical handovers, but warned that this boundary could be vague. A change between two WLAN types might look horizontal or vertical depending on the observer’s perspective; a single router could manage different access technologies without changing the IP address or interface. The taxonomy did not force the radio map and IP map to share borders. RFC 3753, §4.1

Fast, smooth and seamless answer different questions

The most durable distinction appears in the performance vocabulary. RFC 3753 defined handover latency as an interval: from the mobile’s last ability to send or receive an IP packet through the previous access router to its first ability through the new router. That is a network-layer timing boundary, not a full measure of application experience.

“Smooth” handover aimed primarily to minimize packet loss, without explicit concern for additional forwarding delay. “Fast” handover aimed primarily to minimize latency, without explicit interest in packet loss. Those definitions do not mean a fast handover must lose packets, or a smooth one must be slow. They mean the words name different primary objectives; a measurement must still report both delay and loss before a reader can compare outcomes.

“Seamless” reached further but became more context-dependent. The RFC described it as no change in service capability, security or quality. For a practical judgment, it proposed asking whether other protocols, applications or end users would detect a change relevant to normal operation. A handoff transparent to an email client might not be seamless for a latency-sensitive call. A session that stays alive while security degrades would not satisfy the RFC’s whole description merely because packets continue to flow.

The document also separated make-before-break from break-before-make: could the mobile communicate with old and new access routers at the same time, or did the old connection end first? It warned not to confuse make-before-break with “soft handover,” which relies on macro-diversity. Overlap, loss, delay and user-visible continuity are related, but they are not interchangeable measurements. RFC 3753, §§4.3–4.5

A glossary is not a performance certificate

RFC 3753 appeared beside practical mobility work. Its references included Mobile IPv4 and the then-current Mobile IPv6 specification, plus working documents on fast handover and candidate access-router discovery. A later standards-track document, RFC 5568, specified Mobile IPv6 fast handovers. RFC 6275 later replaced RFC 3775 and cited RFC 3753 as an informative reference. Those links show a continuing documentary conversation; they do not establish that a later protocol adopted the glossary as a conformance test or that any operator deployed it. RFC 5568 · RFC 6275

The boundary is especially important because RFC 3753 says it presents terminology only and identifies no security issue in the document. That is not a security assessment of mobility systems. Nor is the RFC evidence that a particular handover was fast, smooth, secure or seamless. It supplies distinctions an analyst can use to ask better questions; evidence must come from the implementation, measurements and affected service.

The 2004 contribution was therefore less a new protocol than an attempt to stop several layers of meaning from being mistaken for one another. A handover could be classified by its scope, who initiated it, who controlled it, whose measurements shaped it, which router prepared it, and whether advance signaling was possible. Its performance could then be described by latency and loss, while its practical seamlessness remained relative to service and user.

That is a useful historical lesson in standards work: common words can make collaboration easier, but they do not erase differences in control, measurement or consequence. A green “handover complete” label is only as informative as the questions it keeps visible.

Sources

Primary record and chronology: RFC 3753 text, RFC Editor record, and IETF Datatracker record.

Adjacent and later specifications consulted for scope and comparison: RFC 3132, RFC 3154, RFC 3374, RFC 3344, RFC 3775, RFC 5568, RFC 5213, RFC 5944, and RFC 6275. These references provide context; they do not establish adoption of RFC 3753 terminology.