Subject: RE: [seamoby] WG Requirement for L2 Paging Support: Is it needed?

From: James Kempf <[email-masked]>
Date: Tue, 13 Feb 2001 10:24:54 -0800 (PST)

Mike,

I've got no objection to including some material in the report that states
that if L2 paging protocols are properly designed, L3 paging to the mobile 
becomes possible. This would serve as a notice to IEEE, 3GPP and others
involved in L2 design that they should do a better job in the future
if they want to support IP.

However, I think the primary purpose of the problem statement was to
inform the IESG if any protocol work is necessary right now. The design
team identified a definite need for L3 paging support within the network,
because existing protocols do not cover all the cases. But there is
a limited role for paging to the mobile because of the lack of L2
support in existing paging protocols for L3 messages.

		jak

>From: Michael Thomas <[email-masked]>
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Date: Tue, 13 Feb 2001 09:49:31 -0800 (PST)
>To: James Kempf <[email-masked]>
>Cc: [email-masked], [email-masked]
>Subject: RE: [seamoby] WG Requirement for L2 Paging Support: Is it needed?
>X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk 
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd 
bUcI'1!
>
>
>I believe that Hesham's larger point is that we
>ought not design around the possibility that
>future paging channels could transport IP, even if
>the current crop are limited. I think that's a
>reasonable stance -- we shouldn't be so cowed by
>existing standards that we give them no motivation
>to design better L2's for IP which is surely
>possible.
>
>			Mike
>
>James Kempf writes:
> > Hesham,
> > 
> > I just had a quick look at the IS-2000 paging message format, and there
> > is no room for any IP information in it. A broadcast page has 0 bits
> > and a mobile station addressed page has at most 17 bits. So in cdma2000,
> > there is basically no room to send IP paging information (note I am not
> > saying L3 here because cdma2000 has its own L3).
> > 
> > I don't have any detailed PDU info on wCDMA, so I can't say for sure, but
> > I suspect the case is similar. 
> > 
> > 		jak
> >  
> > >X-Authentication-Warning: charizard.diameter.org: majordomo set sender to 
> > [email-masked] using -f
> > >From: "Hesham Soliman  (ERA)" <[email-masked]>
> > >To: [email-masked]
> > >Subject: RE: [seamoby] WG Last Call: I-D ACTION:draft-seamoby-paging-probl 
> > em-statement-00.txt (Fwd)
> > >Date: Tue, 13 Feb 2001 00:13:29 +0100
> > >MIME-Version: 1.0
> > >
> > >	James, 
> > >
> > >> As Ram indicated in his response to your email, we were focussed on
> > >> existing systems, in which transmission of IP information over signalling
> > >> channels is basically not possible.
> > >> 
> > >	=> Not possible or not done ? I'm sure you'd agree that there is 
> > >	a difference. Transmission of IP information on signalling channels
> > >	is not done in all cellular systems, but is possible.
> > >
> > >> One possibility is that we can add a section to the recommendations that 
> > >> states that addition of the capability to transmit L3 messages over
> > >> signalling channels would open up the possibility of more comprehensive
> > >> L3 paging support to the mobile. 
> > >> 
> > >	=> Or you can just clearly limit the scope of the draft to what it
> > >	is trying to solve. But I think if you do that, I would find that
> > >the only 
> > >	strong motivation for paging on L3 is the multi-access case.
> > >
> > >> Let me point out, however, that it is not the job of the IETF to come
> > >> up with new L2 protocols. The CRAPS working group last summer explicitly
> > >> rejected working on a common radio control protocol, and I do not think
> > >> that the Seamoby working group wants to get involved in defining new
> > >> L2 signalling for paging either. The best we can do is point out to
> > >> those who do L2 design (such as IEEE, 3GPP, etc.) that L3 paging to
> > >> the mobile becomes possible if L3 messages can be sent over the 
> > >> signalling channel.
> > >> 
> > >	=> Yes I know (and agree) that the IETF doesn't deal with L2. 
> > >	Which makes an even stronger reason for not making 
> > >	assumptions on what channels are used for what packets. 
> > >	We're just designing protocols, which channels they get mapped 
> > >	onto is out of scope. And basing solutions on assumptions 
> > >	like that is limiting. 
> > >
> > >> >General comment: The assumption that L3 packets can only
> > >> >be sent on certain channels is not correct. The whole draft
> > >> >seems to be based on that assumption. I disagree with that
> > >> >unless one of the team members can explain it better to me. 
> > >> >I'm sure this would have been discussed in detail. 
> > >> >
> > >> 
> > >> I don't claim to be an expert on all radio protocols, but to my 
knowledge,
> > >> the existing protocols do not allow extensive L3 signalling on anything
> > >> but the traffic channel. I believe they may allow transmission of 
> > >> some specific L3-related information, but that is not sufficient to
> > >> allow full L3 paging to the mobile.
> > >> 
> > >	=> As I said above, they don't do it, yes, but it doesn't mean
> > >	it can't be done. They also don't do L3 paging at all. That 
> > >	doesn't mean it can't be done. 
> > >
> > >> >"Dormant Mode -  A state in which a mobile can not receive IP
> > >> >      packets, but may still be able to receive L2 signalling related to
> > >> >      tracking the mobile's location. A mobile may transition out of
> > >> >      dormant mode due to a lower layer interface message (possibly
> > >> >      triggered by receipt of an IP packet) or a timer expiration. A
> > >> >      dormant terminal may signal to the network when it changes paging
> > >> >      area, but may delay the signal until the next time it wakes up
> > >> >      (if, for example, the mobile is using a time-slotted dormant mode
> > >> >      algorithm). Note that a terminal which is continuously listening
> > >> >      to L2 for receipt of L3 packets is not in dormant mode. "
> > >> >
> > >> >=> This definition of dormant mode is not correct. A dormant mobile
> > >> >is a mobile that can only receive information on certain channels 
> > >> >and not others. This has absolutely nothing to do with the nature
> > >> >of this information or which layer it is adressing (L2 or L3). 
> > >> >For example in the cellular networks I'm half familiar with, a dormant
> > >> >mobile can receive/send signalling messages on common channels. 
> > >> >A dormant mobile is a mobile that does not have a traffic channel 
> > >> >setup. Therfore saying that it can not receive L3 packets is not 
> > >> >true. Maybe in today's cellular networks the system designers 
> > >> >chose to send L3 signalling on traffic channels. But of course 
> > >> >that should NOT imply that this is the definition of dormancy. 
> > >> >After all there is no L3 paging in today's cellular networks. 
> > >> 
> > >> This definition was crafted based on existing cellular and other
> > >> radio protocols, which, as you point out, do not allow L3 signalling
> > >> on anything but the traffic channel. It is not meant to be universally
> > >> true for all time. 
> > >> 
> > >	=> How does a reader deduce that ?
> > >
> > >> I will change the wording to say "specific channels and not others". I 
> > >> will also add some wording that states that existing cellular protocols
> > >> do not allow L3 signalling on anything but the traffic channel, so the
> > >> scope of the definition is clear.
> > >> 
> > >	=> Well if you decide that this is the scope of the document, 
> > >	then I guess these modifications would make sense. However,
> > >	I'm not sure that such scope is appropriate. I guess 
> > >	others can comment on that. 
> > >	BTW, if you decide on this scope then the entire document 
> > >	should reflect that (including the title) IMO.
> > >
> > >> >In chapter 3:
> > >> >
> > >> >"An L3 paging protocol is sensible only if L2 supports paging. In the
> > >> >   absence of L2 paging, L3 paging achieves no reduction in power drain
> > >> >   because the mobile is forced to monitor L2 for L3 paging messages."
> > >> >
> > >> >=> I dont see how this can be right ? This is a statement that simply
> > >> >removes the need of L3 paging altogether. If you need L2 paging
> > >> >then what's L3 paging needed for ??
> > >> >
> > >> 
> > >> No, it doesn't. If you read through the draft, you will find that the
> > >> design team found specific instances in which L3 paging is necessary.
> > >> What it removes is the need for is L3 paging *to the mobile*. 
> > >> 
> > >> The situation is similar to basic delivery of packets. If you do not
> > >> have an L2 connection, you cannot get packets. L3 bridges different
> > >> L2 technologies. Similarly, the design team felt that an L3 paging
> > >> protocol could do the same for paging, and, in addition, cover the
> > >> cases where the mapping between L2 paging areas and L3 subnets was
> > >> not smooth.
> > >> 
> > >	=> Ok let me reword it. It makes the case for L3 paging weak IMO.
> > >
> > >> >   "Having the mobile constantly listen to L2 for L3 packets is NOT
> > >> >   considered to be adequate L2 support, because it does not achieve
> > >> >   enough power savings to be meaningful. "
> > >> >
> > >> >=> The mobile has to listen to L2 all the time. Again there is
> > >> >an underlying assumption here that L3 packets are only sent 
> > >> >on certain bearers. That's a bad assuption IMO. If someone disagrees
> > >> >with that then please explain why this is the case. I don't think 
> > >> >that sending L3 packets on other channels breaks any laws of 
> > >> >physics. Or maybe I missed something ?
> > >> >
> > >> >
> > >> 
> > >> In time slotted dormant mode, the mobile is sometimes listening and
> > >> sometimes 
> > >> not. Also, in the case where a specific signalling channel is used, 
> > >> having the mobile listen to that channel must have power savings over
> > >> having it listen to a traffic channel, otherwise why bother to do it?
> > >> 
> > >	=> Yes but I didn't say anything about traffic channels. In the 
> > >	extract from the draft, you mention "L2", that doesn't mean 
> > >	traffic channels. L2 is a BIG stack. And that's the problem 
> > >	with making these assumptions. If you want to correct that
> > >	you would have to say that "Having the mobile listen to the 
> > >	traffic bearers on L2 is not ..... " as you said below. But if you
> > >do 
> > >	say that, you're outside IETF boundaries. Therefore, I believe 
> > >	these assumptions should not be made as they limit the solution 
> > >	(if there is a need for one) severely. 
> > >
> > >	Hesham
> > >
> > >
> >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 13 Feb 2001 19:58:13 +0100

James, 

Please see comments below.

> if they want to support IP.
	=> That's fine. I really think that we ought to do a general problem
	statement without restricting ourselves to what's in one standard
	"today". IF we need L3 paging it'll be a long time before we have a 
	protocol and get that protocol deployed. 
	I think Mike captured my points pretty much so I won't add to that.

> inform the IESG if any protocol work is necessary right now. 
> 
	=> Yes but remember that the IETF process is much slower 
	than other standards bodies. So _now_ is probably somewhere
	in future. 

	I'm not against the "now" approach as long as you clearly mention
	that. Right now, the draft looks like a generic draft on L3 paging
	but it really isn't. "Now" is only a small subset of the bigger 
	problem. In fact as I said earlier, I see very little motivation 
	for L3 paging if we take the "now" approach.

	Hesham