Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.21] Discussion on transport protocol selection for MIH!



Seems like a protocol like CARD tends to add extra capabilities beyond those identified in 802.21 which may result in further enhancement of MIH protocol or creation of some other new protocol. 
We may need to clarify this more. Would also help if we specify clearly extra functionality currently being proposed as part of L3 transport (CARD etc.) above and extra functionality beyond what's being currently provided by 802.21.

Ajoy-> I am not sure if CARD adds too many extra functionality beyond what is needed by MIH protocol. CARD defines a mechanism for L2->L3 mapping as well as capability discovery mechanism. CARD assumes that MIH function is located at AR and Mobile Node whereas the current 802.21 spec does NOT mandate the location of network MIH component. But I would go though the suggested section of latest MIH spec and then continue further discussion. In case I notice that CARD provides additional functions beyond what is needed by 802.21, I will flag those as well.  

BR,
-Vivek


> -----Original Message-----
> From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com]
> Sent: Tuesday, July 19, 2005 8:54 AM
> To: Gupta, Vivek G; 'Koora Kalyan Com Bocholt'; 'STDS-802-
> 21@listserv.ieee.org'
> Cc: 'mihep@eng.monash.edu.au'
> Subject: RE: [802.21] Discussion on transport protocol selection for MIH!
> 
> Hi Vivek,
> 
> Please find my inline replies. I am also attaching herewith a presentation
> slides about CARD. I guess the overview of CARD will be useful for 802.21
> folks to better understand the background of CARD protocol and how it is
> useful for MIH transport.
> 
> Regards,
> Ajoy
> 
> -----Original Message-----
> From: Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
> Sent: Tuesday, July 19, 2005 4:10 AM
> To: Koora Kalyan Com Bocholt; Singh Ajoy-ASINGH1; STDS-802-
> 21@listserv.ieee.org
> Cc: mihep@eng.monash.edu.au
> Subject: RE: [802.21] Discussion on transport protocol selection for MIH!
> 
> 
> Given the wide coverage of cellular and wimax networks the issue/problem
> often turns out to be, how to detect the presence of wifi and how to
> decide to switch over to wifi?  In the below case seems like the
> Information Service may not be very helpful in detecting the presence of
> wifi anyway. Seems like you may have to detect presence of wifi by
> traditional (beacon scan/probe) means anyway, unless the cellular network
> can give you some hint about presence of a wifi hotspot. And again after
> detecting the presence of wifi you may have to resort to L2 to pull up
> information pertaining to appropriate network selection.
> 
> In general during discussions in 802.21, some of the requirements that
> emerged are as follows:
> 1] Need to enable both L2 and L3 transports
> L3 may be primarily used for 3G networks (where it is more difficult to
> modify L2 in a timely manner). L2 enabling in case of 802 networks is
> relatively less difficult and needed in certain cases.
> 
> Ajoy-> I am ok with defining extensions to L2 if it is doable in some
> cases as you pointed out.
> 
> 2] 802.21 defines the payload in both cases (both for L2 and L3
> transports) for MIH services. This should work for different MIH users
> including different L3 and above mobility protocols as well.
> 
> Ajoy-> Do you mean infoElements? I guess MIH should define various
> infoElements and higher layer should be able to use appropriate transport
> mechanism and encoding to transport the infoElements.
> 
> 3] Other requirements for L3 transport:
> a] How do you discover the presence of MIH services (IS, CS, ES etc.) and
> capability at L3?
> 
> Ajoy-> This can be done both at L2 as well as L3. There are several ways
> to do this:
> a. Extend l2 beacon
> b. Allow un-solicited L3 message from MIH server to MN for MIH discovery.
> 
> c. Let mobile node send query and if it does not get any reply then it can
> assume that MIH function is not supported by network.
> 
> b] Any security considerations
> 
> Ajoy-> We need to have security association between MN<-> MIH Server and
> between Network MIH Servers.
> 
> c] If an IP based transport is used we may need to select appropriate port
> numbers if we end up selecting different protocols for carrying (IS,CS,ES)
> payloads.
> 
> Ajoy-> I do not think just selecting appropriate port number is enough. I
> guess we need a protocol between MN<->MIH Server and MIH Server<-> MIH
> Server. I would suggest please go through CARD (RFC 4066) as well as
> attached presentation slides.
> 
>  Not sure if we need much else beyond this:
> 
> BR,
> -Vivek
> 
> > -----Original Message-----
> > From: Koora Kalyan Com Bocholt [mailto:kalyan.koora@siemens.com]
> > Sent: Tuesday, July 19, 2005 12:11 AM
> > To: Singh Ajoy-ASINGH1; Gupta, Vivek G; 'STDS-802-21@listserv.ieee.org'
> > Cc: mihep@eng.monash.edu.au
> > Subject: AW: [802.21] Discussion on transport protocol selection for
> MIH!
> >
> > Hi Ajoy,
> >
> > let me put up an other scenario where it is also not possible to get
> > information over higher layer.
> > Let us assume you have an IP connection over a cellular interface like
> > 3GPP and your in a foreign country. You come up to a hotspot where you
> > don't have any knowledge of the ISPs over there. Further, it is possible
> > that some come up and some go down time to time. In this case how does
> > the cellular provider knows about the hotspot? Or do you assume that all
> > the ISPs at hotspots do have some agreements with the cellular ISP? Some
> > of them could be just 'local' ISPs using firewall/NAT/masquerading
> > techniques and are not interested in cellular providers.
> > In this case too, you may have the possiblity to handover to the hotspot
> > ISP if you find any suitable provider.
> >
> > Regards,
> > Kalyan
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com]
> > Gesendet: Montag, 18. Juli 2005 17:07
> > An: 'Gupta, Vivek G'; Koora Kalyan Com Bocholt;
> > 'STDS-802-21@listserv.ieee.org'
> > Betreff: RE: [802.21] Discussion on transport protocol selection for
> MIH!
> >
> >
> > [Gupta, Vivek G]
> > Actually the difficulty is for the first time, when you are powering up
> or
> > in an un-initialized state or don't have any of the links connected. At
> > that
> > time which initial link to select may be an issue. But then you could
> > always
> > have a default radio/link to use in such cases.
> >
> > Ajoy-> Yes, but that is initial call setup scenario. Do we really need
> > Ajoy-> any seamlessness during initial call setup?
> >
> > -----Original Message-----
> > From: Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
> > Sent: Sunday, July 17, 2005 9:45 AM
> > To: Singh Ajoy-ASINGH1; Koora Kalyan Com Bocholt;
> > STDS-802-21@listserv.ieee.org
> > Subject: RE: [802.21] Discussion on transport protocol selection for
> MIH!
> >
> >
> >
> > > -----Original Message-----
> > > From: owner-stds-802-21@ieee.org [mailto:owner-stds-802-21@ieee.org]
> > On
> > > Behalf Of Singh Ajoy-ASINGH1
> > > Sent: Sunday, July 17, 2005 6:36 AM
> > > To: 'Koora Kalyan Com Bocholt'; 'STDS-802-21@listserv.ieee.org'
> > > Subject: RE: [802.21] Discussion on transport protocol selection for
> > MIH!
> > >
> > > Hi Kalyan,
> > >
> > > I would like to comment on one of your statement here.
> > >
> > > Regards,
> > > Ajoy
> > >
> > >
> > > If we select higher layer protocols (eg. layer 3), it is
> > >   difficult for the IS to be delivered before a generic layer
> > >   related connection is established (if we consider IP, then
> > >
> > > Ajoy-> If you have multi-link mobile, you can use IP transport of
> > > connected link to obtain information about neighboring link.
> > [Gupta, Vivek G]
> > Actually the difficulty is for the first time, when you are powering up
> or
> > in an un-initialized state or don't have any of the links connected. At
> > that
> > time which initial link to select may be an issue. But then you could
> > always
> > have a default radio/link to use in such cases.
> >
> >
> >
> >
> > >