Re: [802.21] 802.21 Information Elements
On Thu, Oct 27, 2005 at 03:27:41PM -0700, Gupta, Vivek G wrote:
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > Sent: Thursday, October 27, 2005 11:32 AM
> > To: Gupta, Vivek G
> > Cc: STDS-802-21@LISTSERV.IEEE.ORG
> > Subject: Re: [802.21] 802.21 Information Elements
> >
> > Vivek and all,
> >
> > I think this is a good document that well captures many discussion
> > points made during the September meeting. I have several comments.
> [Vivek G Gupta]
> Thanx much for your comments Yoshi.
>
> >
> > General comments
> > ----------------
> >
> > - It would be good if we have a new column that indicates whether an
> IE
> > belongs to basic set or extended set.
> [Vivek G Gupta]
> Wanted to focus more on the information, then on information
> organization as part of this doc.
OK.
>
> >
> > - Are the 802.11 Applicability and 802.16 Applicability informational
> > for better understanding or should the two columns be included in the
> > draft text as well?
> [Vivek G Gupta]
> Only informational. Just to help us figure out if we need to add/amend
> anything in the 802.11/.16 specification
OK.
>
> >
> > Specific comments
> > -----------------
> >
> > - Number of point of Attachments (PoA) for a specific Access Network
> > in the Neighborhood
> >
> > Since the table contains Address Information for each PoA, the number
> > of PoAs is implicitly known. Do we need to define this IE?
> [Vivek G Gupta]
> The IEs are arranged in a Media Independent Neighbor Report type layout.
> So as part of that you would get this information. In that respect this
> is not really an IE.
It can be helpful if we could clearly define the term "IE". For
example, an IE in 802.11 specification usually means a concrete piece
of information encoded in a TLV format. On the other hand, an IE in
this particular document seems to be an abstract piece of information.
An abstract IE may be encoded into multiple concrete IEs or multiple
abstract IEs may be encoded into a single concrete IE...
>
>
> >
> > - Network Operator
> >
> > As someone pointed out in today's teleconf. on 802.16 amendment, the
> > 802.16e network operator provided by BSID is valid within 802.16
> > networks. As far as I remember, a rough agreement during the
> > September meeting is that 802.21 Network Operator should use a global
> > unique identifier across all network types (but there was no agreement
> > which specific identifier is appropriate.) I personally think that
> > operator's domain name might be the only acceptable global unique
> > identifier used for representing network operator across all network
> > types. Note that if an UE needs to obtain an 802.16e network operator
> > information of a specific 802.16 BS from non-802.16 network, it can be
> > obtained in the same way as PHY type and MAC type (media-specific
> > information is already defined in media-specific MIBs and can be
> > obtained via extended set access), so the 802.21 Network Operator does
> > not necessarily carry 802.16e network operator information.
> >
> [Vivek G Gupta]
> Yeah I agree. This was just an example for 802.16.
> If we agree on a global unique identifier, is this identifier already
> available for most operators or would it have to be constructed. Would
> be nice to use something that's already being widely used.
> Any other views on this....from operators/carriers?
>
>
> > - Subnet Information
> >
> > As far as I remember the discussion during September meeting, it is
> > hard to define for us to determine which specific higher-layer
> > information is useful for 802.21. I think Subnet information (and
> > higher layer service as suggested by Kalyan) can be better replaced
> > with a general item such as "higher-layer information", and make it
> > an extended set IE.
> >
> [Vivek G Gupta]
> That's one thought.
> But in any case it would be good to articulate and capture such
> information before we make it optional. At this stage would like to get
> all/most information folks think that could be used in handover. We
> could always organize it appropriately.
OK.
Thanks,
Yoshihiro Ohba