RE: [802.21] HLSI
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
>
> >
>