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

From: James Kempf <[email-masked]>
Date: Tue, 13 Feb 2001 09:28:14 -0800 (PST)

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: Michael Thomas <[email-masked]>
Date: Tue, 13 Feb 2001 09:49:31 -0800 (PST)

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