Re: [802.21] HLSI
Handovers within 802.11 access points can use .11k Neighbor Report and
location element. For handovers across different media, 802.11
information service can provide a generic neighbor report and location
information.
Yoshihiro Ohba
On Wed, Sep 07, 2005 at 05:58:07AM -0700, Paine, Richard H wrote:
> 11k provides the Neighbor Report and has a location element as well.
> Are you taking these into account for 802.11 device handoff? Are you
> considering the neighbor report-like mechanisms for other wireless
> technologies (like cellular).
>
> Richard H. Paine
> Success is getting what you want, happiness is liking what you get!
> Cell: 206-854-8199
> IPPhone: 425-373-8964
> Email: richard.h.paine@boeing.com
>
> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@TARI.TOSHIBA.COM]
> Sent: Tuesday, September 06, 2005 9:17 AM
> To: Gupta, Vivek G
> Cc: Yoshihiro Ohba; STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] HLSI
>
> On Tue, Sep 06, 2005 at 10:19:18AM -0700, Gupta, Vivek G wrote:
> >
> > List of Networks Supported, Roaming_list_Availabale,
> >
> > Neighbor_reports_Available is questionable as well.
> >
> > [Vivek G Gupta]
> >
> > Why are these questionable? These seem lot more promising from a
> > handover policy perspective.
>
> "List of Networks Supported" and "Neighbor_reports_Available" can be
> integrated into Neighbor List (i.e., a list of neighboring PoAs) in
> which network type is included in each PoA in the list. Similarly,
> Roaming_list_Available should be Roaming List (i.e., a list of roaming
> operators, not just a flag).
>
> Yoshihiro Ohba
>
> >
> >
> >
> > Network_Operator
> >
> > could be improved to contain an IANA-assigned, global unique SMI
> >
> > enterprise number as well as the name of the operator. Location could
> >
> > be improved to carry RFC 3825 Location Configuration Information (just
> >
> > having latitude and longitude is insufficient to represent a
> >
> > geo-coordinate).
> >
> > [Vivek G Gupta] Agree
> >
> >
> >
> > >
> >
> > >
> >
> > >
> >
> > > The media dependent IEs currently include:
> >
> > >
> >
> > > { Cipher_Suites, Authentication_Methods, Cost (free/not free),
> >
> > > IP_Version, Data_Rates, QoS, Neighbor_Maps }
> >
> >
> >
> > In my analysis, Cipher_Suites, Authentication_Methods, Data_Rates, QoS
> >
> > are questionable.
> >
> > [Vivek G Gupta]
> >
> > Again why?
> >
> > Knowledge of security (supported or not), availability of QoS and
> > supported data rates can influence selecting PoA decisions.
> >
> >
> >
> >
> >
> > I agree on representing Cost as a binary value
> >
> > (free or not free).
> >
> >
> >
> > >
> >
> > >
> >
> > >
> >
> > > We could use a basic TLV format to represent these, along with a
> > simple
> >
> > > mechanism to query or set the values,
> >
> > >
> >
> > > of different IEs, so not sure why we really need a basic schema and
> > > an
> >
> > > extended schema and all the other baggage along with it.
> >
> >
> >
> >
> >
> > I am currently defining TLV format for IEs defined in basic set. I
> >
> > think the IEs defined in basic set should be able to be queried using
> >
> > not only XML but also TLV. On the other hand, I do believe schemas
> >
> > (basic schema and extended schema) are needed to support extensibility
> >
> > to deal with any link-layer technologies including the existing ones
> >
> > and future ones as well as to make flexible and efficient information
> >
> > queries.
> >
> > [Vivek G Gupta]
> >
> > Why cannot extensibility be supported with a basic TLV type format?
> >
> > You can always query for list of supported networks and supported
> > capabilities and go from there.
> >
> > In any case would like to see more focus on definition/identification
> > of appropriate IEs across different networks.
> >
> >
> >
> >
> >
> > After the July meeting, I did qualitative analysis on the
> >
> > applicability of XML/RDF to 802.21 information service and the
> >
> > analysis result will be described in my another contribution prepared
> >
> > for the September meeting, which is a white paper about 802.21
> >
> > information service using XML/RDF technologies.
> >
> > [Vivek G Gupta]
> >
> > Great!
> >
> > We also need draft text for the 802.21 specification and need to clean
>
> > up the Information Services section as well.
> >
> >
> >
> >
> >
> > I really want to settle on all of those basic issues on information
> >
> > service in the September meeting.
> >
> > [Vivek G Gupta]
> >
> > Fantastic! Lemme know how I can help
> >
> >
> >
> > Best regards,
> >
> > Yoshihiro Ohba
> >
> >
> >
> >
> >
> > >
> >
> > >
> >
> > >
> >
> > > Best Regards,
> >
> > >
> >
> > > -Vivek
> >
> > >
> >
> > >
> >
> > >
> >
> > > -----Original Message-----
> >
> > > From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf
> > > Of
> >
> > > Yoshihiro Ohba
> >
> > > Sent: Monday, September 05, 2005 8:59 PM
> >
> > > To: stds-802-21@listserv.ieee.org
> >
> > > Subject: HLSI
> >
> > >
> >
> > >
> >
> > >
> >
> > > I am currently writing up a contribution to revise Information
> > > Service
> >
> > >
> >
> > > sections and I have the following questions:
> >
> > >
> >
> > >
> >
> > >
> >
> > > The HLSI IE defines several flags indicating the available
> > higher-layer
> >
> > >
> >
> > > services including ISP, MMS, IMS, MIP, VPN, SIP and NAT.
> >
> > >
> >
> > >
> >
> > >
> >
> > > - What is the exact meaning of "VPN support"? Does it mean that if
> >
> > >
> >
> > > you connect to the PoA then all data traffic will be automatically
> >
> > >
> >
> > > forwarded to some remote network over a dedicated tunnel between the
> >
> > >
> >
> > > PoA and the remote network? Or does it mean that the network
> > > provides
> >
> > >
> >
> > > a VPN gateway? Or does it mean that the mobile terminal connected
> > > to
> >
> > >
> >
> > > the PoA can establish a VPN connection to any VPN gateway. Or
> >
> > >
> >
> > > something else? The first definition does not make sense because
> > > you
> >
> > >
> >
> > > will need additional information about the remote network to make a
> >
> > >
> >
> > > handover decision. The latter two definitions do not make sense
> >
> > >
> >
> > > either, because there are several different ways of establishing a
> > > VPN
> >
> > >
> >
> > > connection (i.e., IPsec, SSL, L2TP, PPTP, etc.) and you will need
> >
> > >
> >
> > > additional information as to which VPN method is used to make a
> >
> > >
> >
> > > handover decision.
> >
> > >
> >
> > >
> >
> > >
> >
> > > - What is the exact meaning of "SIP support"? Does it mean that the
> >
> > >
> >
> > > network has a SIP server or proxy, or something else?
> >
> > >
> >
> > >
> >
> > >
> >
> > > - Do we really need HLSI IE defined in the basic set? I think it
> > > can
> >
> > >
> >
> > > be defined in extended set. This is because we might need more
> >
> > >
> >
> > > detailed information about higher-layer (such as IP addresses and
> >
> > >
> >
> > > prefixes of access routers, supported IP mobility optimization
> >
> > >
> >
> > > mechanism, list of supported ISPs, etc.) to make a higher layer
> >
> > >
> >
> > > information and just defining a set of flags seems like a half-baked
> >
> > >
> >
> > > solution. Such detailed information can be provided via
> > > schema-based
> >
> > >
> >
> > > query by which various higher-layer (and lower-layer) MIB objects
> > > can
> >
> > >
> >
> > > be retrieved once converted to RDF data.
> >
> > >
> >
> > >
> >
> > >
> >
> > > Regards,
> >
> > >
> >
> > >
> >
> > >
> >
> > > Yoshihiro Ohba
> >
> > >
> >