Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance

>>
>>
>>
>>> 
>>> After all the standardization around MCoA/IFOM, building all the
>>> hype/coolness around driving one flow on path and another the other
>>>path,
>>> its sad to note that we simply don't have the devices/or the battery
>>> technology that can keep multiple radios up at the same time for a
>>> reasonable length of time (except few exceptions).
>> 
>> 
>> => This is not about MCoA or flow mobility. Of course we have the
>>ability
>> to have multiple interfaces up and many of us use it everyday. I assumed
>> Charlie's question was not about this trivial case, which we all know
>> exists, but rather about a single technology doing make before break
>> handovers. I know of only one radio technology that did that in real
>> deployments (OFDM).
>> 
>> Hesham
>
>Yes, we slightly digressed from Charlie's original point. But, on keeping
>multiple radios up, the point that Raj touched on, sure, we can keep all
>the
>radios up, but with the charger wired on, in practical terms. All I know
>is,
>if I keep my WLAN interface up on my Droid X, I need a much sooner
>recharge.
>I also know, most terminals are configured to USE only one radio up for
>whatever reasons. 

=> Yes they use one radio because they don't have sophisticated enough src
address selection mechanisms (probably because the current services don't
need it) to split the traffic. They make the calls on 3G not WLAN :) so
think about when VoIP is really deployed over 3G (LTE), they will have to
distinguish between those two interfaces and split traffic.

On the battery issue, yes of course but a few years ago those smart phones
needed to be charged every few hours, now they improved. My laptop battery
lasts 5-6 hours, which is an improvement. So these things change over
time. 

>But, I Ack, there may be some terminals which may be using
>both the interfaces, ignoring their SAS awareness ..etc...
>
>Any case, glad to hear your comments/disagreements. We need some life into
>these all dead IETF mailing lists :) ...

=> :). Happy to contribute.

Hesham



>
>
>
>
>Sri
>