RE: [802.21] discovery vs. discovery
Cheng,
I think there are three classes of information:
(1) Network identity
(2) Access point identity and static capabilities
(3) Access point dynamic capabilities
("Network identity" can be a fairly complicated aspect in some models if roaming agreements are taken into account.)
Of these, (1) and (3) are most suited for being advertised in beacons. (1) because it is such a crucial part of the decision whether to use a network, and (3) because it may dynamically change.
In any single network, (2) is likely to be generally similar between access points, so optimisations for this case are reasonable.
Equally, in a wired network, physical connection tends to imply that the network identity is usable, so you can optimise for that case. Also in wired networks, (3) tends to be less of an issue.
Mike.
-----Original Message-----
From: owner-stds-802-21@listserv.ieee.org [mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Cheng Hong
Sent: Tuesday, June 22, 2004 9:27 AM
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] discovery vs. discovery
Hi Reijo, Michael, and all,
I think it would be good to first draw the line clearly between the network
discovery and the information discovery.
What sorts of information should be classified as the the network discovery?
Is it just the discovery of the identity of the network, maybe also the
network behind it (as in the WLAN interworking discussion)? How about the
network capabilities? Would they be for the network discovery or the
information discovery? For example, when talking about the QoS information,
as defined in .11e, certain parts of the QoS information are also available
in the beacon.
Another possible way to separate them would be from L2 and L3. Network
discovery only provides info regarding L2, and information discovery would
be regarding L3 info. I remember a few delegates mentioned about this in the
teleconf. But I am not sure this is the concensus for the group. And, this
seems also regards to how we look at the 'neighbourhood information'.
Regarding the 3GPP/2, it might be very difficult to ask them to change their
L2 to accommodate the .21, especially currently they are not yet looking at
seamless handover to/from .21 to their cellular network. But, I think for
most of the functions we discussed here, they already have corresponding
mechanisms available.
As for the 3GPP standards mentioned by Reijo, the TS22.234, 23.234, 24.234,
33.234, (29.234 - may not be relevant)are WLAN interworking standards.
Therefore, WLAN mechanisms would be reused (they won't define a new WLAN
standard). Since these TS are still under development, official LS to 3GPP
would be helpful. Also, it could be directed to .11 WIEN group for
discussion, since the they are specifically working on WLAN to 3G
interworking.
cheers
Cheng Hong
> -----Original Message-----
> From: owner-stds-802-21@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of
> Reijo Salminen
> Sent: Tuesday, June 22, 2004 3:21 PM
> To: Michael.G.Williams@NOKIA.COM; STDS-802-21@LISTSERV.IEEE.ORG
> Subject: RE: discovery vs. discovery
>
>
> Hello, .21
>
> Some comments,
>
> What is the 'network node' in 2), is it an AP, the mobile
> station or something else? I mean that it is a bit difficult
> to follow what the sentence "a mechanism definition or
> protocol specification for a network node to locate .21 aware
> nodes which are producing "neighborhood information" in .21
> format" means exactly.
>
> The, regarding the offline comments about 3GPP/PP2
> willingness/ability to modify their L2 - this is a question
> to be handled officially and in a professional way in the
> liaison activity. As we have seen in the 3GPP TS 23.234 the
> intention is to use SIM/USIM based authentication and 3GPP
> AAA server for WLAN users in order to be able to interwork
> with 3GPP system. In order to enable the seamless handover
> between the above mentioned systems, it should be clarified
> which of the existing 3GPP TS'es need to be updated, and if
> there is needed new ones, the same is valid for 3GPP2. Also
> what is needed is a realistic timeplan for the needed updates
> to be done, and who are the contact persons for each TS.
>
> BR, Reijo
>
> PS. A good book to read about the 3GPP radio access is 'Holma
> & Toskala: WCDMA for UMTS', maybe you Michael have a copy
> since they are your colleagues from Nokia...
>
>
> -----Original Message-----
> From: owner-stds-802-21@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of
> Michael.G.Williams@NOKIA.COM
> Sent: 21. kesäkuuta 2004 23:52
> To: STDS-802-21@LISTSERV.IEEE.ORG
> Subject: discovery vs. discovery
>
> Hi everyone,
>
> In section 2, Functional Requirements, a suggestion was made
> to call the two types of discovery under discussion:
>
> 1) Network Discovery
> 2) Informational Discovery
>
> Here is a potential framework for the two.
>
> 1) Is the "traditional" network discovery
> concept/requirement. .21 would provide a media independent
> specification that defines optimal ways to determine the
> existence of L2 networks. Most wireless networks offer the
> beacon/probe type advertisement now. .21 might specify the
> essential information that is required across all conformant
> MACs within this function.
>
> 2) Informational Discovery would be a mechanism definition or
> protocol specification for a network node to locate .21 aware
> nodes which are producing "neighborhood information" in .21
> format. Some MACs offer such information now. We have
> discussed a variety of additional information beyond that
> defined in any MAC, as potentially being useful in optimized
> handover. .21 might specify a way of advertising additional
> information in an extensible way that permits the "handover
> state machine" to access it.
>
> It might be that the two services compliment each other, so
> for MACs which don't have a beacon (e.g. .3) or can't/don't
> want to modify the beacon, they could publish the 1) through
> a 2) service.
>
> Please comment!
>
> There are some strong comments offline that 3GPP/PP2 can not
> modify their L2 to add functionality such as the above. Are
> there comments on this too?
>
>
> Best Regards,
> Michael
>
>