Subject: RE: [nemo] Usage Requirement - Personal Mobile Router

From: "BINET David RD-CORE-CAE" <[email-masked]>
Date: Wed, 29 Nov 2006 11:42:50 +0100

Hello,

I think it is a topic we have to investigate in Nemo working group since it can provide some opportunities for vendors and operators. With the deployment of portable devices and the rise in available bandwidth on air interfaces there is no doubt that such "personal mobile router" concept is a good one for next IP services and future terminal capabilities. 
I support this proposition to add this item in Nemo charter.

David Binet   

> -----Message d'origine-----
> De : Thierry Ernst [mailto:[email-masked]] 
> Envoyé : vendredi 24 novembre 2006 23:31
> À : ml-nemo
> Objet : [nemo] Usage Requirement - Personal Mobile Router
> 
> 
> Dear all,
> 
> Chair's hat on:
> 
> First, I would like to thank Vijay for bringing the Personal 
> Router usage up on this mailing list.  The reason why in the 
> charter we only mentioned about the aviation use case and the 
> automotive use case is simply that no one brought the PAN use 
> case on the list.
> 
> So,  the number of comments we got from folks in various kind 
> of industry tend to demonstrate the tremendous interest this 
> topic could have and also the impact on consumer electronic 
> business (I suspect that the aviation and the automotive use 
> cases wouldn't be deployed as quickly as PANs for medecine, 
> emergency units, families, wheelchair, sports, etc.).
> 
> And, yes, the questions for which we need an answer is:
> - what kind of RO must be supported,
> - what kind of multihoming configuration,
> - what kind of NEMO BU registration (explicit / implicit)
> - what kind of Prefix Delegation
> - what kind of AAA
> - etc
> 
> My proposition would be to add it explictly in the charter 
> together with the aviation industry and the automotive 
> industry requirements.
> 
> Thierry.
> 
> 
> 
> 
> On Fri, 17 Nov 2006 17:37:01 +0100
> Carlos Jess Bernardos Cano <[email-masked]> wrote:
> 
> >Hi Pascal:
> >
> >	I also agree that both options (proxy-RO and MR-to-MR) 
> should be 
> >carefully studied. However, my point was that I think that also in 
> >operator-driven scenarios it should be studied how to apply 
> MR-to-MR RO 
> >schemes, in addition of the approach of using RO proxies deployed in 
> >the Internet. The reasoning behind this is that the best 
> path between 
> >two NEMOs would always be the direct one between MRs. By 
> using proxy RO 
> >entities on the infrastructure, there will always be a trade-off 
> >between number of proxy RO entities and the level of 
> optimisation that 
> >is required.
> >
> >	In summary, I'm not against of studying proxy-RO 
> schemes, but I think 
> >that we should not limit the applicability of MR-to-MR approaches to 
> >emergency scenarios.
> >
> >	Kind Regards,
> >
> >	Carlos J.
> >
> >El vie, 17-11-2006 a las 16:20 +0100, Pascal Thubert (pthubert)
> >escribi:
> >> Hi Carlos:
> >> 
> >> Now I'm confused. I do agree that 2.5G/3G introduces 
> latency. But the infrastructure we talk about is the Internet 
> as opposed to an ISP xG network, so this was not my discussion. 
> >> 
> >> Infrastructure-based RO means that the RO end points (e.g. 
> the proxies) are operated by ISPs, so some trust can be 
> elaborated between proxies and between proxies and HA. P2P 
> expects nothing from the ISPs but fat pipes.
> >> 
> >> I certainly agree that P2P RO has benefits, and we must 
> study it for sure, for the exact reasons you give. I would 
> not want to pay when I use my phone as intercom at home. In 
> an emergency situation P2P RO is all you might get, and you 
> will certainly care less about billing, privacy and trust. 
> >> 
> >> OTOH, a solid world wide 4G solution requires the services 
> I mentioned...
> >> 
> >> Hopefully it is not one XOR the other, right? 
> >> 
> >> Pascal
> >> 
> >> >-----Original Message-----
> >> >From: Carlos Jess Bernardos Cano [mailto:[email-masked]]
> >> >Sent: Friday, November 17, 2006 12:20 PM
> >> >To: Pascal Thubert (pthubert)
> >> >Cc: RYUJI WAKIKAWA; Vijay Devarapalli; [email-masked]; 
> >> >[email-masked]
> >> >Subject: RE: [nemo] RE: [IETF - Nemo] Personal Mobile 
> Router: Next Step?
> >> >
> >> >Hi Pascal,
> >> >
> >> >El vie, 17-11-2006 a las 11:55 +0100, Pascal Thubert (pthubert)
> >> >escribi:
> >> >> Hi Carlos :)
> >> >>
> >> >> I do not believe that the performance is the issue:
> >> >>
> >> >> If proxy Home Agents are deployed the way SGSNs are today, they 
> >> >> will be on the way and will not
> >> >cause a visible latency increase. But a proxy HA enables AAA, HA 
> >> >selection, billing, policy enforcement, trust, and 
> end-point privacy, which are strong ISP requirements.
> >> >
> >> >	Even if Home Agents are deployed in that way, there 
> will be a high 
> >> >latency component introduced by the celular network 
> itself (we have 
> >> >performed many real experiments and that delay is always no less 
> >> >than 100-150ms one-way). As far as I know, operators are 
> working to 
> >> >improve the performance (several years ago, the latency 
> introduced 
> >> >by 2.5/3G networks was even worse, about almost half a second).
> >> >
> >> >>
> >> >> OTOH, P2P might not require any of these features and 
> thus, and a 
> >> >> direct MR-to-MR RO would seem to
> >> >be the right approach for such applications.
> >> >>
> >> >> Since both scenarii are relevant, I believe there is 
> room for both 
> >> >> direct and infrastructure-based
> >> >RO mechanisms, depending on whether you are considering 
> an ISP service or a P2P.
> >> >
> >> >	I agree that both scenarios are relevant. But I also 
> think that it 
> >> >is also interesting to look at the issues you mentioned regarding 
> >> >ISPs and operators when a RO scheme that do not make use of the 
> >> >infrastructure is used, and seek for alternative solutions when a 
> >> >MR-to-MR approach is used instead. Don't you agree that 
> it would be 
> >> >better to always avoid traversing the infrastructure if an 
> >> >alternative path which is shorter, cheaper and provides a 
> better performance is available?
> >> >
> >> >>
> >> >> Seems fair?
> >> >>
> >> >> Pascal
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: Carlos Jess Bernardos Cano [mailto:[email-masked]]
> >> >> >Sent: Friday, November 17, 2006 11:17 AM
> >> >> >To: Pascal Thubert (pthubert)
> >> >> >Cc: RYUJI WAKIKAWA; Vijay Devarapalli; [email-masked]; 
> >> >> >[email-masked]
> >> >> >Subject: RE: [nemo] RE: [IETF - Nemo] Personal Mobile 
> Router: Next Step?
> >> >> >
> >> >> >Dear Pascal and all,
> >> >> >
> >> >> >	I also agree that personal router scenario is 
> of interest. 
> >> >> >However I think that for many of these scenarios, as 
> other people 
> >> >> >has already mentioned, in order to benefit from low delay and 
> >> >> >high bandwidth, it use of celular network interfaces should be 
> >> >> >avoided. Therefore, I think that for these scenarios, 
> MR-to-MR RO 
> >> >> >optimisation schemes are the most suitable ones. Doing 
> RO in the 
> >> >> >infrastructure does not help so much in reducing the 
> delay if you 
> >> >> >already have ~150ms of one-way delay using UMTS (if 
> two NEMOs are 
> >> >> >talking each other and both are connected using, for example, 
> >> >> >UMTS, then you'll end up having 150x2=~300 ms of one 
> way delay!).
> >> >> >
> >> >> >	Regards,
> >> >> >
> >> >> >	Carlos J.
> >> >> >
> >> >> >El vie, 17-11-2006 a las 10:34 +0100, Pascal Thubert (pthubert)
> >> >> >escribi:
> >> >> >> Hi Ryuji and Vijay.
> >> >> >>
> >> >> >> I strongly agree that the personal router should be an item 
> >> >> >> together within the charter.
> >> >> >>
> >> >> >> Talking in various forum, we found interest in a 
> Personal Area 
> >> >> >> NEMO
> >> >> >> that:
> >> >> >>
> >> >> >> - Connects voice devices for VoIP (the main application)
> >> >> >> - Connects body sensors (medical devices, sportsmen, 
> firemen, 
> >> >> >> location
> >> >> >> monitoring)
> >> >> >> - Connects Personal productivity devices (handheld)
> >> >> >>
> >> >> >> The type of requirements we found in this space:
> >> >> >>
> >> >> >> - for voice:
> >> >> >> a) Privacy: the device should not see the remote CoA
> >> >> >> b) Jitter/Latency: as usual... for instance the one 
> way latency 
> >> >> >> should stay below 150ms
> >> >> >> c) Access: Compatibility/awareness with emerging 
> access such as 
> >> >> >> mesh networks.
> >> >> >> d) Service: A stable anchor point for AAA, policy 
> and SLA enforcement.
> >> >> >>
> >> >> >> - for sensors:
> >> >> >> e) Layer 7 triggers: access network awareness 
> (emergency dial, 
> >> >> >> bandwidth availability indication...)
> >> >> >>
> >> >> >> - for personal productivity devices
> >> >> >> f) VPN access
> >> >> >> g) Community of interest (user centric overlays, route 
> >> >> >> projection)
> >> >> >>
> >> >> >> In particular, to answer Ryuji's question about RO, 
> we can note 
> >> >> >> that
> >> >> >> PANEMO:
> >> >> >>
> >> >> >> - demands a route optimization for NEMO for point b)
> >> >> >> - requires that the RO happens in the Infrastructure 
> for point 
> >> >> >> a) whereas g) is more P2P
> >> >> >> - pleads for regional proxy Home Agents for point d) (note, 
> >> >> >> THIS NOT
> >> >> >> PMIP!!)
> >> >> >>
> >> >> >> Pascal
> >> >> >>
> >> >> >> >-----Original Message-----
> >> >> >> >From: RYUJI WAKIKAWA [mailto:[email-masked]]
> >> >> >> >Sent: Thursday, November 16, 2006 5:51 AM
> >> >> >> >To: Vijay Devarapalli
> >> >> >> >Cc: [email-masked]; [email-masked]
> >> >> >> >Subject: Re: [nemo] RE: [IETF - Nemo] Personal 
> Mobile Router: 
> >> >> >> >Next
> >> >> >> Step?
> >> >> >> >
> >> >> >> >Hi Vijay
> >> >> >> >
> >> >> >> >Interesting, but I want you to make clarification a 
> bit more.
> >> >> >> >
> >> >> >> >When you said route optimization, what level of 
> optimization 
> >> >> >> >is required?
> >> >> >> >
> >> >> >> >Do you consider like MR-MR direct connection, two HA bypass?
> >> >> >> >I believe you image cellular egress interface and not WiFi.
> >> >> >> >So, your problem must be not here.
> >> >> >> >
> >> >> >> >In general, when two MRs talks, two HAs are involved.
> >> >> >> >However, if two MRs are in the same operator, one HA can be 
> >> >> >> >skipped (i.e. same HA for two MRs).
> >> >> >> >In addition, if the egress is cellular, the HA should be 
> >> >> >> >located in the cellular network.
> >> >> >> >The latency must be not so big (my guess).
> >> >> >> >
> >> >> >> >I want to know where you want to optimize the path 
> between two 
> >> >> >> >personal MRs?!
> >> >> >> >
> >> >> >> >regards,
> >> >> >> >ryuji
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >On 2006/11/16, at 0:29, Vijay Devarapalli wrote:
> >> >> >> >
> >> >> >> >> Hi Jean-Michel,
> >> >> >> >>
> >> >> >> >> if there is more interest, I can write something 
> up in the 
> >> >> >> >> form of requirements. I was hoping more people would have 
> >> >> >> >> gone to the mike and said something. the only person who 
> >> >> >> >> went to the mike was Hesham who asked a "not so relevant" 
> >> >> >> >> question. :)
> >> >> >> >>
> >> >> >> >> Vijay
> >> >> >> >>
> >> >> >> >>> -----Original Message-----
> >> >> >> >>> From: Jean-Michel Combes 
> >> >> >> >>> [mailto:[email-masked]]
> >> >> >> >>> Sent: Wednesday, November 15, 2006 7:05 AM
> >> >> >> >>> To: Vijay Devarapalli
> >> >> >> >>> Cc: [email-masked]
> >> >> >> >>> Subject: [IETF - Nemo] Personal Mobile Router: Next Step?
> >> >> >> >>>
> >> >> >> >>> Hi Vijay,
> >> >> >> >>>
> >> >> >> >>> Further to your (too) short presentation in the Nemo 
> >> >> >> >>> session at San Diego, I would like to know what is your 
> >> >> >> >>> goal regarding the Personal Mobile Router. Do 
> you expect to 
> >> >> >> >>> submit a draft in the Nemo WG on the 
> requirements for such a use case?
> >> >> >> >>>
> >> >> >> >>> Thanks for the information.
> >> >> >> >>>
> >> >> >> >>> Best regards.
> >> >> >> >>>
> >> >> >> >>> JMC.
> >> >> >> >>>
> >> >> >> >>
> >> >> >>
> >> >> >--
> >> >> >ASCIATE! Gratis para estudiantes  http://www.telematica.ws
> >> >> > Carlos Jess Bernardos Cano     http://www.netcoms.net
> >> >> > GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974
> >> >--
> >> >ASCIATE! Gratis para estudiantes  http://www.telematica.ws
> >> > Carlos Jess Bernardos Cano     http://www.netcoms.net
> >> > GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974
> >--
> >ASCIATE! Gratis para estudiantes  http://www.telematica.ws
> > Carlos Jess Bernardos Cano     http://www.netcoms.net
> > GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974
> >
> >
> 
>