RFC 3132

Dormant Mode Host Alerting ("IP Paging") Problem Statement

📅 published June 2001, from ietf

Dormant Mode Host Alerting ("IP Paging") Problem Statement 🎀

okay bestie, this one is RFC 3132 💖 written by J. Kempf from Sun Microsystems and dated June 2001. It's marked as Informational, so it's giving "here's some info" rather than "here's a standard you must follow" 🧚. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Status of this Memo

this memo is here to provide information for the Internet community 💅. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌸.

Copyright (C) The Internet Society (2001). All Rights Reserved. ✨

Abstract

this memo describes paging, figures out whether IP paging is actually needed, and lists some recommendations for Seamoby charter items about paging 🦋. The results are aimed at the task the design team was given. They are not meant to be the final word on paging forever 💀, and they don't bind Seamoby or any other working group, in case the situation with IP mobility protocols or radio link support changes a lot 🌈.

1.0 Introduction ✨

so the IESG asked the Seamoby Working Group to write a problem statement 📝. The question is whether we need more protocol work to alert dormant mode mobile hosts (commonly called IP paging) so IP mobility can be seamless 🫶. The paging design team read this as a job to check whether Mobile IPv4 and Mobile IPv6, combined with existing radio link protocols, can already find a mobile node that's in power saving mode.

Lots of existing radio link protocols and mobile systems can still find and set up a radio link with mobiles that are in power saving mode 🔋. These mobiles aren't actively listening for IP packets all the time, or they aren't on the radio channels that usually carry IP traffic to mobiles. This alerting lets mobiles cut their power use and lowers the signaling load on the network for tracking mobiles that aren't actively sending or receiving IP packets 😭.

When a mobile is in low power mode, the network has to do some special steps to find it and alert it 🕵️. Those steps depend on the radio link, but the general name for the whole process is paging, which is a term people use a lot in cellular telephony 📞.

In this document, we first go over some definitions and explain what paging is. Then we look at whether existing IP mobility protocols (namely Mobile IP [1] [2]) need paging. After that we build a list of Seamoby work items for that need 💜. Keep in mind that the discussion and the work item conclusions are about existing IP mobility protocols and existing radio link protocols. If something big changes in radio link support or in the IP mobility protocols, such as a micromobility protocol for IP showing up, the issues in this document may need another look 🔥.

2.0 Definitions ✨

here are the definitions that matter for understanding the paging functionality 📚:

Dormant Mode - A state where the mobile limits its ability to receive normal IP traffic by monitoring radio channels less. This lets the mobile save power and reduces the signaling load on the network 🔋.

Time-slotted Dormant Mode - A dormant mode setup where the mobile switches between periods of not listening to any radio traffic and periods of listening for traffic ⏰. Time-slotted dormant mode is usually synchronized with the network, so the network can deliver traffic to the mobile during its listening periods. The mobile may also be limited to listening on specific signaling channels that, according to current practice, don't normally carry IP traffic 🎀.

Paging - When a packet heading to a mobile that's currently in dormant mode arrives, the network signals through radio access points to find the mobile and alert it so it can set up a last hop connection 📡. This messaging is in addition to just delivering the packet to the mobile. In other words, last hop routing of packets is NOT considered to be paging 🙅‍♀️.

Paging Area - A group of radio access points that get signaled to find a dormant mode mobile node 🗺️. A paging area doesn't have to match an IP subnet. A dormant mode mobile node may be required to signal the network when it crosses a paging area boundary, so the network can keep a rough idea of where the mobile is 🧭.

Paging Channel - A radio channel set aside for signaling dormant mode mobiles for paging 📻. By current practice, the protocol on a paging channel is usually decided by the radio link protocol. Some paging protocols do have room for carrying arbitrary traffic, though, so they could potentially be used to carry IP 🤯.

Traffic Channel - The radio channel that IP traffic to an active mobile is usually sent on 🚗. A mobile uses it while it's actively sending and receiving IP traffic, and it isn't continuously active in dormant mode. For some radio link protocols, this may be the only channel available 🫠.

Paging Area Registrations - The signaling a dormant mode mobile node sends to the network when it crosses a paging area boundary, so the network knows the mobile is now in the new paging area 📍.

3.0 Discussion of Paging 💅

dormant mode is good for both the mobile and the network, for these reasons 👑:

  • Power savings. When the mobile has to listen to the radio interface less, its battery drains less 🔋.
  • Reduced signaling for location tracking. The mobile only has to signal when it crosses a paging area boundary, not every time it switches between radio access points. Paging areas usually contain lots of radio access points, so the tracking signaling goes down a lot 📉.

In existing radio link protocols, there's a clear split between protocols that only support dormant mode and protocols that support dormant mode with paging 🍓. Protocols without paging have no paging areas, no dedicated paging channel, and no radio link protocol aimed at finding a dormant mode mobile. Protocols that do support paging have all of those things. Generalizations always risk being contradicted by specific exceptions, but comparing how existing radio link protocols handle these two cases is still pretty useful 🤓.

3.1 Dormant Mode Support Only

In radio link protocols that only support dormant mode, the dormant mode mobile node usually works in time-slotted mode, and there's just one radio channel available: the traffic channel 📶. The mobile node wakes up periodically, and at the same time the radio access point it's associated with delivers any IP packets that came in while it was asleep 🌙. Radio access points have to buffer incoming packets for dormant mode mobiles. How many packets get buffered and for how long is up to the implementation 🧺.

If the mobile moves out of range of its access point while it's in dormant mode, it finds out when it wakes up and reassociates with a new access point 🏃‍♀️. The new access point then talks to the old access point over the wired backbone, the old one sends its buffered packets, and the new one delivers them to the mobile 🦋.

Radio link protocols that only support dormant mode are usually wireless LAN protocols running in unlicensed spectrum. The mobile node isn't charged for using a traffic channel there, so there's no real need to conserve spectrum usage 🆓.

3.2 Dormant Mode with Paging Support

In radio link protocols that support paging, the radio link usually has more than one channel 📡. A dormant mode mobile node may work in time-slotted mode, waking up periodically to listen to the paging channel, or it may just listen to the paging channel all the time 👂. The key point is that the mobile doesn't listen to or transmit on a traffic channel while it's in dormant mode 🙌.

The radio access points are grouped into paging areas. The radio link protocol only has the mobile and the network do periodic signaling when the mobile crosses a paging area boundary, to give the network a rough idea of where the mobile is (paging area registrations) 🗺️. Some paging deployments don't even use paging area registrations. Instead, they use heuristics to figure out where the mobile is when a packet arrives. In that case, no signaling is needed while the mobile is in dormant mode 🧠.

An incoming packet goes to the paging area where the mobile last reported in, or the paging area is picked by heuristics 🎯. The network does a radio link page by sending out a signal on the paging channel. The signal may get repeated until the mobile answers or a timeout happens 🔁. If the mobile answers, the packet gets delivered. If the timeout hits, the mobile is assumed to be unreachable 😬.

Radio link protocols with paging support tend to live in licensed spectrum, where the network operator wants to cut down on signaling over traffic channels 💸. That reduction frees up traffic channel spectrum for revenue-producing use, and it means the customer isn't charged for signaling overhead 💜.

4.0 Is IP Paging Necessary? 🔮

in this section, we ask whether IP paging support is necessary 🤔. We start with radio link protocols that don't support paging at all. Then we look at radio link protocols that do have paging support. As the introduction said, the focus is on whether the existing IETF mobility protocol, Mobile IP, needs enhancement 🫶. We also briefly talk about how paging relates to a possible future micromobility protocol 🦋.

okay so, one possible reason people want IP paging is for radio links that don't support paging at all 🦋 The idea is that an IP paging protocol could help find a dormant mode mobile on radio networks that don't have paging in the radio protocol. main character energy 💅

But here's the tea 🫖 when radio links DO support paging, paging is usually used to find mobiles that the network already has a rough idea about. The mobile saves signaling and battery by only telling the network where it is when it crosses a paging area boundary (if even then 🙈), and that happens way less often than crossing a radio access point boundary. So if IP paging is going to be useful for radio link protocols that don't support paging, it also has to let the network keep a rough idea of where the mobile is. Otherwise the signaling for tracking the mobile and the drain on its battery don't go down at all 😭

Now, as the previous section explained, for radio links without paging support, the network always knows exactly where the mobile is 🎯 When the mobile moves into range of a new radio access point, it re-registers with that access point in its cell, and the new access point can contact the old one and pick up any buffered traffic. The new access point may also send a foreign agent advertisement (for Mobile IPv4) or a router advertisement (for Mobile IPv6) to the mobile if the mobile has changed subnets, so the mobile can do Mobile IP re-registration and keep its IP routing up to date ✨ There is absolutely no ambiguity about the mobile's location from the network's point of view, so the network can keep routing packets to the mobile node while it's in dormant mode, and it can be confident (modulo buffer overflows and timeouts at the radio access point 💀) that the packets will get delivered the next time the mobile wakes up from dormant mode.

So, bestie, IP paging gives no advantages to radio link protocols that don't have paging support 🫶

For radio links that DO support paging, there are two cases to look at: networks of radio links that all use the same radio technology (homogeneous), and networks that mix different radio technologies (heterogeneous) 🌈 We check whether Mobile IP can support dormant mode location in both of these cases.

4.2.1 Homogeneous Technology Networks 💜

For homogeneous technology networks, the big question is whether the signaling Mobile IP already does is enough to help locate dormant mode mobile nodes. Subnets are the unit of signaling for presence in IP. When a mobile node moves from one subnet to another, Mobile IP signaling is needed to change the mobile's care-of address, and that signaling is what establishes the mobile's presence in the new subnet. Paging areas are the unit of signaling for dormant mode mobile presence at the radio level, and paging area registrations or heuristics are used to establish a dormant mode mobile's presence in a particular paging area ✨

Here's the thing 👀 If paging area registrations can always trigger Mobile IP registrations, then there's no need for an IP paging protocol, because the network (specifically the home or hierarchical agent) will always have an up-to-date picture of where the mobile is and can always route packets to it. The key factor is how subnets get mapped into paging areas. If it's always possible to map them so that a paging area registration can carry a Mobile IP registration, or some other technique (such as network assisted handoff [3] [4]) can transfer the Mobile IP registration, then no IP paging protocol is needed 🔥

In general, the mapping between paging areas and subnets can be arbitrary, but we start with a smooth subset relationship, where paging areas are subsets of subnets or vice versa. That means network topologies where one subnet is split between two or more paging areas get ruled out 🙅‍♀️ The restriction is arbitrary, but starting here lets us find out whether additional work is needed. We also assume that paging area registrations are always done in the radio layer protocol. This is also optimistic 🌷

There are three cases:

  1. The topological boundaries of the paging area and subnet are identical.
  2. Multiple paging areas are part of the same subnet.
  3. Multiple subnets are part of the same paging area.

Each case gets its own subsection, so let's go through them 🧚

4.2.1.1 Subnet and Paging Area Boundaries Identical 🍓

In the case where radio paging areas map one to one onto IP subnets (and therefore onto Mobile IPv4 foreign agents or IPv6 access routers), it's possible to use radio link paging together with Mobile IP handoff techniques so the network can track the mobile's location 🦋 If the paging area update protocol can send arbitrary packet data over the paging channel, the access router or foreign agent can send a router advertisement or foreign agent advertisement to the mobile as part of the signal that the mobile has entered the new paging area, and the mobile can send a Mobile IP registration as part of the paging area update. For other cases, enhancements to Mobile IP network-assisted handoff techniques can let the network track the mobile as it moves from paging area ((== subnet)) to paging area. Other uses of the Mobile IP registration protocol are also possible, depending on how much paging support there is for packet data. As a result, the home or hierarchical agent has complete knowledge of routes to the mobile and can route packets to the foreign agent or access router. Radio layer paging may be needed at the foreign agent or access router to re-establish a traffic channel with the mobile, but no IP paging is required 💖

4.2.1.2 Multiple Paging Areas Map into One Subnet 🌈

This is the same as the case above, with one exception: the last hop Mobile IPv4 foreign agent or IPv6 access router for the subnet does the paging in multiple paging areas to find the mobile 🔍

4.2.1.3 Multiple Subnets Map into One Paging Area 🌀

Okay, this is the messy one 😭 When a single radio paging area maps onto multiple IP subnets, you can't just use Mobile IP handoff between last hop access routers or foreign agents to track the mobile as it moves, because the mobile doesn't signal its location when it changes subnets. Inside the set of subnets spanning the paging area, the mobile's movement is invisible to the L2 paging system, so a packet sent to the mobile's last known location might get answered by a page in a totally different subnet 🙈

Let's walk through an example, because this is where it gets iconic 🎬

Say we have a network with two paging areas, PA(1) and PA(2), and each one has lots of subnets inside it. A mobile moves from PA(1) into PA(2) and enters PA(2) at subnet X. It uses the paging area registration to tell the network it has moved, and suppose that paging area registration includes a Mobile IP registration. The agent handling the L2 paging protocol sends that registration to the home/hierarchical agent (or maybe it just gets routed there). Now the home/hierarchical agent knows the mobile has a CoA in subnet X, and so does the mobile. Once the mobile finishes the paging area registration/Mobile IP registration, it goes back to sleep 😴

But the mobile doesn't stop in subnet X! It keeps moving while in dormant mode, and while it's dormant it isn't sending any signaling (L2, Mobile IP, or anything else) to the network 🏃‍♀️ It travels from subnet X, where it first entered the paging area, all the way to the other side of the paging area, into a completely different subnet, subnet Y.

Now suppose a packet arrives at the home/hierarchical agent for this mobile. Because the home/hierarchical agent believes the mobile is in subnet X, it sends the packet to the access router or foreign agent for subnet X. That access router or foreign agent performs a radio page for the mobile in subnet X. But the mobile isn't in subnet X anymore, so it wakes up in subnet Y, since the radio page propagates throughout the paging area. It does a Mobile IP re-registration because it sees that it's in a new subnet, but the packet at the access router or foreign agent in subnet X can't reach the mobile 💀

Without any further support, the access router or foreign agent in subnet X drops the packet. The only way to get the packet to the mobile node from there is for the mobile node to send a binding update to the access router or foreign agent when it wakes up in the new subnet. Once that access router or foreign agent has the new binding, it can forward the packet. Some smooth handoff techniques already depend on sending binding updates to foreign agents [5], so arranging for the mobile node to send a binding update would be possible. In IPv6 it becomes less attractive because of the need for security on the binding update. Either way, the result is even more Mobile IP signaling before the packet can be delivered, which adds latency for the mobile 😤

While it may be possible to handle this case with enhancements to Mobile IP, those enhancements would probably add more latency and signaling to the initial connection between the mobile and the network when the mobile wakes up from dormant mode. An IP paging protocol between the home or hierarchical agent and a paging agent in the paging area would cut down on the latency of delivering that first packet 🚀

Here's how it works with IP paging ✨ The packet arrives at the home/hierarchical agent, which sends an IP page to a paging agent in the last reported paging area. The paging agent performs an L2 page to the mobile. The mobile answers the page with a Mobile IP registration to the home/hierarchical agent, and then the home/hierarchical agent sends the packet. The home/hierarchical agent and the mobile already have a security association, so there's no need to negotiate one. Buffering of the first packet, and of any further incoming packets before the Mobile IP registration, is handled by the home/hierarchical agent instead of a router at the edge, so the edge routers can be simpler 🥰 Finally, the home/hierarchical agent can start routing to the mobile as soon as the registration comes in 🎉

4.1.2.4 More Complex Homogeneous Network Cases

okay so up until now, we haven't found a single case where locating and delivering the first packet to a dormant mode mobile couldn't be handled by Mobile IP with enhancements 💅. IP paging is a promising optimization in the multiple subnets to single paging area case ✨, but in theory extra Mobile IP signaling could handle the problem too (potentially lots of it with IPv6 if a security association is needed 🙈). BUT the examples we looked at are really best-case scenarios 😭. In practice, mapping subnets to paging areas is probably way less clear cut, and paging area registrations are way less common than we've been assuming.

Requiring network operators to make paging areas and subnets follow a subset relationship, so Mobile IP signaling can do double duty as paging area updates, is unrealistic 💀. In real life, paging areas overlap, and there's often not even a clear subset relationship between paging areas themselves. Some radio protocols, like wCDMA [6], let different mobile terminals in the same geographical area have different paging area identifiers. Going case by case to figure out whether Mobile IP needs enhancements would probably end up way more complicated than just having a simple IP paging protocol 🧚 that lets a home/hierarchical agent notify an L2 agent in the paging area when a new packet comes in.

Finally, requiring operators to always turn on paging area registrations is unacceptable, and using Mobile IP registrations won't work if paging area registrations aren't done. The description above is ideal when it comes to signaling between the mobile node in dormant mode and the network. Anecdotal evidence says most operators don't turn on paging area registrations, and they use heuristics to figure out where to page for the mobile. If the operator doesn't turn on paging area registrations, there's no way for the mobile to report its position when it changes paging area, so there's no L2 vehicle for potential dormant mode use of Mobile IP 😩.

4.2.2 Heterogeneous Technology Networks

In a network made of links with multiple technologies, the problems from before get multiplied 🌀. Using Mobile IP becomes even more cumbersome, because the subnet the initial packet is delivered to isn't the same subnet the dormant mode mobile is on. On top of that, it might be on a radio network the user wouldn't actually prefer in their current location. This could happen, for example, if the mobile moved inside a building and radio coverage on one interface got weak or nonexistent, or if the user had a choice between a cheaper connection and a higher bandwidth one. The mobile may no longer be listening or reachable on the paging channel of the old network. So when the old access router or foreign agent pages on the old radio network, the mobile (which is now only listening for pages on the new network) may not answer, even though it's reachable on the new network. Arranging for pages in multiple radio networks is a possibility, but without an L3 paging protocol to abstract away the L2 details, each L2 protocol's details have to be handled separately 😮‍💨.

A paging protocol that unifies paging across multiple radio technologies therefore looks super attractive ✨. There may be commonalities in the corresponding radio paging protocols that allow a mapping to be set up between the radio protocols and an abstract IP paging protocol. For example, say we have a common paging area identifier defined at the IP layer, which the access points map to each radio paging protocol. An IP paging message containing the identifier is sent to multiple access points, and each one sends the appropriate radio paging message based on the particular technology it implements. The results then come back as radio paging responses, get mapped back into IP by the access points, and are delivered back to the origin of the page 🦋.

An additional case to think about is when a single subnet is made up of multiple radio access technologies. A wireless access point usually provides L2 bridge behavior to the wired link it's connected to. If two access points with incompatible technologies and non-overlapping cells are connected to the same subnet, a mobile node with interfaces to both technologies would need paging from both technologies. If reachability can be established simply by ARP or neighbor discovery, no IP paging is needed. BUT note that ARP or neighbor discovery requires a functional traffic channel to be available to the mobile, since these protocols are typically implemented for wired networks, where a single channel exists on which all IP traffic is delivered. If the mobile is in the sleep phase of a time-slotted dormant mode, or it's listening to a paging channel, it'll fail to respond to these requests 💔. In this case, some means of triggering a radio page from IP is necessary to find the mobile. Modifying ARP or neighbor discovery to utilize a paging channel, if one is available, is a possible (if somewhat messy 🙈) alternative, but a dedicated location protocol may be somewhat cleaner 🧼.

4.3 Paging and Micromobility

If the Seamoby Working Group decides that an IP micromobility protocol is necessary, then the analysis above is no longer complete. A micromobility protocol may require some type of paging support. The design team doesn't want to include any further discussion of paging and micromobility at this point, because it's not clear whether micromobility will be pursued by Seamoby, and that discussion would be premature 🌸.

5.0 What Exactly is the Problem?

Even though the analysis above found situations where locating a mobile in dormant mode may need some action at the IP layer, it's important to keep in mind what the problem actually is 🧠. The problem to be solved is locating a mobile node because it has moved while in dormant mode. IP paging is one solution to that problem, but there may be others 👑.

6.0 Recommendations

The design group recommends the following charter items for Seamboy 📋:

  1. Since the design group has identified several network deployment scenarios where existing Mobile IP technology cannot find a mobile in dormant mode, protocol work is necessary to define a way for the network to find a mobile that is currently in dormant mode 🔍.
  2. The work defined above should be pursued in a way that is maximally consistent with Mobile IP and other existing IETF protocols. The work should also generate recommendations about how to achieve the best match between existing radio paging protocols and IP 🤝.
  3. If the Seamoby working group decides to pursue a micromobility protocol that requires paging, the Seamoby group should undertake the design of a new paging protocol within the context of that work 🛠️.
  4. There is some evidence that cellular operators' deployments of paging are highly variable, and may, in fact, be suboptimal in many cases with respect to supporting IP. The Seamoby working group should write a BCP which explains how to perform IP subnet to paging area mapping and which techniques to use when, so network designers in wireless networks have a guide when they are setting up their networks 🗺️.

7.0 Acknowledgements

The editor would like to thank the Seamoby paging design team for helping formulate the first draft of the document. Jari Malinen contributed text to Section 4.2. Hesham Soliman, Karim El-Malki, and Behcet Sarikaya contributed critical commentary on the first draft, which was super important in sharpening the reasoning about what can and can't be expected in the absence of radio layer paging support, and how Mobile IP might be used to support dormant mode location 🫶💜.

8.0 References

[1] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October 1996.

[2] Johnson, D., and C. Perkins, "Mobility Support in IPv6", Work in Progress.

[3] El Malki, K. et. al., "Low Latency Handoff in Mobile IPv4", Work in Progress.

[4] Tsirtsis, G., Editor, "Fast Handovers for Mobile IPv6", Work in Progress.

[5] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.

[6] Holma, H. and A. Toskala, "WCDMA for UMTS: Radio Access for Third Generation Mobile Communication", John Wiley and Sons, New York, 2000.

9.0 Editor's Address

James Kempf
Sun Labs California
Sun Microsystems, Inc.
901 San Antonio Rd., UMPK15-214
Palo Alto, CA, 94303
USA

Phone: +1 650 786 5890
Fax:   +1 650 786 6445
EMail: james.kempf@sun.com

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society 💖.

📦 where this page comes from