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

RE: [802.21] Ad hoc telecon for Dec 13th



> -----Original Message-----
> From: Srinivas.Sreemanthula@nokia.com
> [mailto:Srinivas.Sreemanthula@nokia.com]
> Sent: Tuesday, December 27, 2005 3:02 PM
> To: Gupta, Vivek G; reijo.salminen@seesta.com;
> benjamin.kohtm@SG.PANASONIC.COM; STDS-802-21@listserv.ieee.org
> Subject: RE: [802.21] Ad hoc telecon for Dec 13th
> 
> HI Vivek,
> We had the common IS use cases in mind so we concluded it may not be
> needed. I can take an example and get your opinions on this. If the
STA
> is now in some radio network and want to query information over L2
from
> a visible WLAN network, do you want the STA to first perform MIH
> registration before providing IS? Also we said that this could be in
> state 1, so the MIH registration cannot be secure.
[Vivek G Gupta] 
From a deployment perspective many of us have raised certain issues with
this scenario. This scenario puts quite a bit of constraint on WLAN AP,
which needs to comprehend 802.21 IS requests, then contact the 802.21
info server (if not already part of AP) fetch the response to query
(possibly over L3 from 802.21 info server) repackage it and sent it back
to client. There have also been discussions that since transactions
cannot be secure in this case, all info elements may NOT be available in
state 1 and queries for those info elements that are not supported by
service providers/802.21 info server, may be returned empty. Further,
commands and events could not be supported in this case as well.
So yes since only a very small subset of MIH services may be available
in this case, MIH registration in this case may have limited benefits
and may not be feasible. 
Will this be still valid if the above scenario used L3 for access to
information elements? I guess somewhere in this thread meaning of MIH
registration is probably lost and it may help to clarify that.


> 
> On the second issue, currently MIH services can be intermixed on
various
> transports. Like IS for L2 and ES/CS for L3 or viceversa. IMO, MIH
> registration would be the same transport as ES/CS services. The issue
> was related to multiple registrations based on transport. Do you see
> that ES/CS can be provided at both L2 and L3 in the same network? I
can
> understand for different networks, it is upto the STA to decide which
> network ES/CS control it prefers and accordingly maintain a
registration
> (one). If two were active in different networks, the STA can report
> events to both but can receive commands from only one.
> 
[Vivek G Gupta] 
There are some interesting scenarios here and we may need to carefully
analyze these in more detail.

> Regards,
> Srini
> 
> >-----Original Message-----
> >From: ext Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
> >Sent: Wednesday, December 21, 2005 9:11 AM
> >To: Sreemanthula Srinivas (Nokia-NRC/Dallas);
> >reijo.salminen@seesta.com; benjamin.kohtm@SG.PANASONIC.COM;
> >STDS-802-21@listserv.ieee.org
> >Subject: RE: [802.21] Ad hoc telecon for Dec 13th
> >
> >
> >Srini,
> >
> >[1] Why don't we need registration for IS? Should the MIH
> >enabled Information Service server start providing service to
> >any UE without registration?
> >
> >[2] As for tying transport and MIH registration, in my view it
> >does lead to less complex implementations. Mixing and matching
> >transport and different services may lead to additional
> >complexity without any undue benefits.
> >For example if communication and registration has been
> >established using
> >L2 and if you are accessing a set of services using L2, and if
> >suddenly/in between the MIH PoS starts sending some of the
> >messages over L3, the client may have difficulty in dealing with it.
> >Why would one want to do MIH registration using one transport
> >and then use MIH services over another transport?
> >
> >Best Regards
> >-Vivek
> >
> >> -----Original Message-----
> >> From: Srinivas.Sreemanthula@nokia.com
> >> [mailto:Srinivas.Sreemanthula@nokia.com]
> >> Sent: Monday, December 19, 2005 2:09 PM
> >> To: Gupta, Vivek G; reijo.salminen@seesta.com;
> >> benjamin.kohtm@SG.PANASONIC.COM; STDS-802-21@listserv.ieee.org
> >> Subject: RE: [802.21] Ad hoc telecon for Dec 13th
> >>
> >> Vivek and Reijo,
> >> There is a common understanding that the registration for IS may
not
> >be
> >> feasible. So far the focus has been only on ES/CS. Do you see the
> >> benefit of tying the transport to the MIH registration?
> >>
> >> My understanding was to have a transport independent framework for
> >this
> >> concept. One could use any transport as long as the credentials/ids
> >are
> >> same. Then the question is could one have multiple sets of
> >credentials
> >> that can be used to do multiple registrations between two peers?
> >> Possible, but what is the benefit? Another question to ask - Are we
> >> talking about multiple registration between two MIH peers?
> >Or multiple
> >> registrations to the network involving MIH in STA to multiple MIH
> >> entities in the network? If latter, we need some coordination among
> >the
> >> involved MIH network entities or else it may be conflicting.
> >>
> >> In the end, it is possible to do it if we have some concrete use
> >cases.
> >>
> >> Regards,
> >> Srini
> >>
> >> >-----Original Message-----
> >> >From: ext Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
> >> >Sent: Saturday, December 17, 2005 6:04 AM
> >> >To: Reijo Salminen; Sreemanthula Srinivas (Nokia-NRC/Dallas);
> >> >benjamin.kohtm@SG.PANASONIC.COM; STDS-802-21@listserv.ieee.org
> >> >Subject: RE: [802.21] Ad hoc telecon for Dec 13th
> >> >
> >> >
> >> >One reason I can think of for multiple registrations
> >between two MIH
> >> >peers is if they end up using multiple (different) transports. For
> >> >example if two MIH peers were using say L3 for IS and say L2 for
> >> >ES/CS, quite likely you may need multiple registrations.
> >> >
> >> >BR,
> >> >-Vivek
> >> >
> >> >> -----Original Message-----
> >> >> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On
> >> >Behalf Of
> >> >> Reijo Salminen
> >> >> Sent: Saturday, December 17, 2005 12:06 AM
> >> >> To: Srinivas.Sreemanthula@NOKIA.COM;
> >> >benjamin.kohtm@SG.PANASONIC.COM;
> >> >> STDS-802-21@listserv.ieee.org
> >> >> Subject: RE: [802.21] Ad hoc telecon for Dec 13th
> >> >>
> >> >> Hello,
> >> >>
> >> >> Comment on the multiple registrations, I think it would be
useful
> >for
> >> >eg.
> >> >> due to the mentioned bandwidth reasons. For example if for a
> >roaming
> >> >> subscriber there is frequent registrations/deregistrations due
to
> >> >changes
> >> >> in
> >> >> the access network (or if the operator of the access network has
> >> >different
> >> >> policies for MIH support at different parts of the access
> >> >network). It
> >> >> could ease the registration process if there could be several
> >> >> registrations,
> >> >and
> >> >> they could be in different states.
> >> >>
> >> >> Comments?
> >> >>
> >> >> BR, Reijo
> >> >>
> >> >>
> >> >>
> >> >> -----Original Message-----
> >> >> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On
> >> >Behalf Of
> >> >> Srinivas.Sreemanthula@nokia.com
> >> >> Sent: Saturday, December 17, 2005 12:33 AM
> >> >> To: benjamin.kohtm@SG.PANASONIC.COM;
STDS-802-21@listserv.ieee.org
> >> >> Subject: RE: [802.21] Ad hoc telecon for Dec 13th
> >> >>
> >> >> Hi Benjamin,
> >> >> I agree with you discovery will happen before as shown in
> >the flow
> >> >> diagram. That statement was specifically referring to ES/CS
> >messages
> >> >> after the discovery procedure. I will change the text to
> >> >reflect this
> >> >> comment.
> >> >>
> >> >> On the second issue, can you elaborate why one would need
> >more than
> >> >one
> >> >> registration between two MIH peers? We discussed the need for
only
> >> >one.
> >> >>
> >> >> Regards,
> >> >> Srini
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: ext Benjamin Koh [mailto:benjamin.kohtm@SG.PANASONIC.COM]
> >> >> >Sent: Monday, December 12, 2005 11:29 PM
> >> >> >To: STDS-802-21@listserv.ieee.org
> >> >> >Subject: Re: [802.21] Ad hoc telecon for Dec 13th
> >> >> >
> >> >> >Hi!
> >> >> >
> >> >> >Unfortunately I'll not be able to attend this teleconf,
> >however I
> >> >> >have some comments regarding the ES/CS registration.
> >> >> >
> >> >> >"MIH peers may not provide or accept MIH messages without an
> >active
> >> >> >registration session"
> >> >> >While I'm not against having such a requirement, we should
> >consider
> >> >> >allowing some form of (limited?) query or discovery before
> >> >> >registration.
> >> >> > A scenario may be for the initiating node to first
> >query and find
> >> >> >out what are the available Event/Command Services before
> >deciding
> >> >> >whether or not to initiate the registration process
> >(which may be
> >> >> >expensive in terms of time, bandwidth and/or processing).
> >> >This may be
> >> >> >related to some aspects of ES/CS discovery.
> >> >> >
> >> >> >"Establishes a session setup and assigns an id"
> >> >> >Does this imply that that multiple simultaneous sessions
> >> >between the
> >> >> >same two nodes may require multiple registrations?
> >> >> >What is the scenario you have in mind for that?
> >> >> >
> >> >> >Regards,
> >> >> >Ben
> >> >> >
> >> >> >
> >> >> >Srinivas Sreemanthula wrote:
> >> >> >> Hello all,
> >> >> >> Here is the slideset that is built on top of last meeting
> >> >and some
> >> >> >> email discussions. We can use these topics for open
> >> >discussions and
> >> >> >> draw some conclusions.
> >> >> >>
> >> >> >> Regards,
> >> >> >> Srini
> >> >> >>
> >