[STDS-802-16] Fw: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS

I stand corrected. Dave is absolutely right. Neither the language in the original or proposed revision 16e PAR restricts specification to the PHY and MAC.

Any limitation to the scope for 16e to PHY and MAC is inferentially inherited from the WG authorization and the PAR authorization for the base IEEE 802.16-2004 document. Though I can find no codification of the restriction in the 802 rules, since an amendment PAR adds/changes material in the original document without capacity to undo or violate the original documents scope and purpose, I think that an interpretation of inherited PAR restriction is likely correct. A revision PAR is another matter and seems to have the ability to supercede the original PAR. Thus inherited PAR restriction seems less applicable to a revision PAR. Traditionally, exception to the inherited restriction in scope and purpose must be specifically and clearly enumerated in the amendment PAR authorization and, while an amendment PAR exception might expand on the base document scope and purpose, it may not invalidate the base document scope and purpose. So, had we intended for 16e scope and purpose to exceed the PHY and MAC restriction of IEEE 802.16-2004 we would have had to clearly and unambiguously say so in the 16e PAR.

In this particular instance, I believe Dave's interpretation of 'Functions to support higher layer...' is flawed. I do not believe the sentence represents a clear statement of intent to exceed the PHY and MAC constraints of IEEE 802.16-2004. I draw specific attention to the distinctive wording 'Functions to support [emphasis added] higher layer....' We have traditionally interpreted that sentence to mean that new mobility PHY features and MAC messaging, including primitives and triggers, would be defined in 16e to enable or support higher layer mobility communications, beyond the scope of 16e work. I would argue that the sentence would certainly have read 'Higher layer handoff communications between base stations or sectors are specified' had we intended higher layer communications to be defined and not merely enabled by the standard.

Thanks,
Phil

----- Original Message -----

From: "Mcginniss, Dave S [NTK]" <david.s.mcginniss@MAIL.SPRINT.COM>

To: <STDS-802-16-MOBILE@listserv.ieee.org>

Sent: Saturday, August 07, 2004 1:32 AM

Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS

> In the Scope of the 802.16e PAR
> "SCOPE:This document provides enhancements to IEEE Std 802.16-2004 to Support subscriber stations moving at vehicular speeds and thereby specifies a system for combined fixed and mobile broadband wireless access. Functions to support higher layer handoff between base stations or sectors are
> specified. Operation is limited to licensed bands suitable for mobility fixed/mobile use below 11 6 GHz.
> Fixed 802.16-2004 subscriber capabilities shall not be compromised"
>
> I would interpret the " Functions to support higher layer handoff between base stations or sectors are specified." To mean that inter base station messaging is in scope. Where does the scope recieve MAC/PHY limitation in its scope. I know that IEEE 802.x pars are typicaly limited to MAC/PHY if this is the basis then it would have to explicitly state all other communications. What keeps these messages form being developed for delivery across the AI as would be the case if using 802.16 to backhaul across another BS to reach another? Doesn't this in fact offer the possibility of control of handoff functions residing in the center BS or AKA BSC/APC?
>
>
> David S. McGinniss
> Distinguished Member of Technical Staff
> Sprint Broadband Wireless Technology Development Group
> (630) 926-3184 david.s.mcginniss@mail.sprint.com
>
>
>
> David S. McGinniss
> Distinguished Member of Technical Staff
> Sprint Broadband Wireless Technology Development Group
> (630) 926-3184 david.s.mcginniss@mail.sprint.com
>
>
>
>
> -----Original Message-----
> From: owner-stds-802-16-mobile@listserv.ieee.org [mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of Phillip Barber
> Sent: Friday, August 06, 2004 5:58 PM
> To: STDS-802-16-MOBILE@listserv.ieee.org
> Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS
>
> Davd,
>
> BS-to-BS communications standardization is out of scope for 16e. 16e only
> covers PHY and MAC standardization of the air interface between MSS and BS.
> That is one reason NetMan was formed.
>
> Thanks,
> Phil
>
> ----- Original Message -----
> From: "Mcginniss, Dave S [NTK]" <david.s.mcginniss@MAIL.SPRINT.COM>
> To: <STDS-802-16-MOBILE@listserv.ieee.org>
> Sent: Friday, August 06, 2004 4:56 PM
> Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS
>
>
> > I think the terminology used serving and controlling help clarify
> discussion. I understand the concept in each case and agree about the
> hierarchical vs. flat discussed by Mary and Bill. I also understand that
> the BSC is unfortunately out of scope! Even with a flat network running
> lets say Ethernet from an aggregation switch point perspective still flat at
> layer three the mobility anchor point is important from a backhaul
> perspective. In addition 802.16e PAR indicates that the inter BS
> communications to achieve handoff are in scope. Am I missing something in
> the PAR language procluding the standardization of a BS that serves a
> mobility anchor point that by the wording would also be a BS providing AI?
> The AI may not be active or useful to all MSS so let's say it is useful to
> none but it is positioned to expedite handoff because it is collocated with
> my switch/Ethernet example. Does extending the messaging to support a BS of
> this type AKA BSC really fall out of scope of !
> > 802.16e? >From an operator perspective having this functionality
> standardized and hence cheaper and interoperable would be desirable. I
> think the SCOPE statement opens the door to address these functions and
> facilitate a better long term solution.
> >
> > Perhaps the entity in the FBSS scenario should be called the "serving
> > BS" and the entity in the SHO should be called the "controlling BS".
> > The role of "mobility anchor point" may be outside the scope of
> > 802.16.
> >
> > David S. McGinniss
> > Distinguished Member of Technical Staff
> > Sprint Broadband Wireless Technology Development Group
> > (630) 926-3184 david.s.mcginniss@mail.sprint.com
> >
> >
> >
> >
> > -----Original Message-----
> > From: owner-stds-802-16-mobile@listserv.ieee.org
> [mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of Bill Gage
> > Sent: Wednesday, August 04, 2004 7:06 AM
> > To: STDS-802-16-MOBILE@listserv.ieee.org
> > Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS
> >
> > Are we (incorrectly) using the term "anchor BS" for two different
> > concepts?
> >
> > Dave McGinniss appears to be referring to the *mobility* anchor point.
> > This is the BS (or BSC) that receives downlink packets and distributes
> > them to members of the active set. The mobility anchor point is tied
> > to the IP address assigned to the MSS and, in normal circumstances,
> > remains the mobility anchor point for as long as the MSS is using that
> > IP address.
> >
> > If you have a flat network, with a BS acting as the mobility anchor
> > point, then Dave is correct -- there will be a significant impact on
> > terrestrial backhaul requirements due to "tromboning" effects. The
> > total traffic over the backhaul link will be the traffic associated
> > with MSS served by that BS plus the replicated traffic forwarded by
> > that BS to other members of the active set for those MSS where it is
> > acting as the (mobility) anchor. Dimensioning of the backhaul link can
> > be tricky because you have to make assumptions about the number of MSS
> > roaming outside the serving area of the anchor BS, about the number of
> > MSS simultaneously in FBSS/SHO and about the number of members in an
> > active set.
> >
> > If you have a hierarchical network with a centralised entity (e.g.
> > BSC) acting as the mobility anchor point and distributing traffic to
> > the members of the active set, then the backhaul link just has to
> > handle the traffic associated with MSS served by that BS. Dimensioning
> > of the backhaul link is fairly straight forward because it is
> > ultimately tied to the capacity of the radio link.
> >
> >
> > Mary Chion is referring to the BS that, in FBSS, is selected from the
> > active set to pass traffic to and from the MSS. In a flat network,
> > this may or may not be equivalent to the anchor BS. In SHO, the anchor
> > BS is the one terminating the basic CID for a MSS. The role of
> > "anchor" can change dynamically according to radio link conditions.
> >
> > Perhaps the entity in the FBSS scenario should be called the "serving
> > BS" and the entity in the SHO should be called the "controlling BS".
> > The role of "mobility anchor point" may be outside the scope of
> > 802.16.
> >
> > Cheers ...
> >
> >
> > >-----Original Message-----
> > >From: Mary Chion
> > >Sent: August 3, 2004 6:07 PM
> > >To: STDS-802-16-MOBILE@listserv.ieee.org
> > >Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question for
> > >FBSS
> > >
> > >
> > >Dave,
> > >
> > >I think the issues you raised are cruicial ones. I would like to
> > >try to address some of them here.
> > >
> > >1. H_Add and H_Delete are parameters included in DCD message.
> > >They are set by the network and broadcast to all the MSS in the
> > >BS.
> > >
> > >2. Active set is part of of contribution for FBSS and SHO and it
> > >is adopted in the 802.16e.
> > >
> > >3. You are correct, there should be a limit in the number of BSs
> > >allowed in the active set. It can be done by one of the two ways:
> > >a) Since the BS is involved in the HO process, the BS can limit
> > >the number of BSs in the active set without changing the
> > >standard. When the MSS send MOB-MSSHO-REQ message to the BS, the
> > >BS will send the new active set information to the MSS in MOB-
> > >BSHO-RSP message and BS can limit the number of BS in the active
> > >set in the message. It is stated in the standard that "the actual
> > >Active Set chosen by the MSS shall be a subset of those listed in
> > >MOB_xxxHO-RSP and shall be indicated in MOB-HO-IND". b) We can
> > >specify the maximum number of BSs in active set in the standard.
> > >But, this might not be necessary.
> > >
> > >4. An Anchor BS is defined as one of the BSs in the active set.
> > >The role of Anchor BS in Fast BS Switching is to be the only BS
> > >communicating with the MSS. What's added in the standard is only
> > >addressing the over-the-air interface. I'm not sure if I fully
> > >understand what you mean by excluding a BS to be the anchor BS.
> > >For FBSS, an anchor BS is necessary for the HO scenario. I agree
> > >with you, if the same data are sent to all BSs in the active set
> > >BS instead of just to the anchor BS, there will be a major impact
> > >on backhaul capacity (especially for services with high speed
> > >data) and it might not even be an accpetable implementation.
> > >This is an important issue for network design. However, I don't
> > >think we can address this issue in 802.16e since 802.16e only
> > >defines the over-the-air interface. This should be resovled at
> > >system implentation.
> > >
> > >Please let me know what you think. Thanks.
> > >
> > >Regards,
> > >
> > >Mary
> > >
> > >-----Original Message-----
> > >From: Mcginniss, Dave S [NTK] [
> > >mailto:david.s.mcginniss@mail.sprint.com]
> > >Sent: Tuesday, August 03, 2004 5:08 PM
> > >To: Mary Chion; STDS-802-16-MOBILE@listserv.ieee.org
> > >Subject: RE: [STDS-802-16-MOBILE] [Harmonization] Question for
> > >FBSS
> > >
> > >
> > >
> > >In the entire example for Fast Cell Switching and Soft Handoff I
> > >had assumed the anchor was analogous to a BSC/APC (base station
> > >controller/Access Point Controller) Only in a decentralized
> > >implementation without this element would a BS/AP serve as an
> > >anchor. I think the original question posed by Jay form LG is a
> > >crucial one. If all the BS in the active set are served the same
> > >data for the MSS by the Anchor (BS/BSC) this could be a
> > >significant impact on backhaul requirements. Is there a concrete
> > >methodology for limiting the active set? I see the H_ADD and
> > >H_Delete messages but cant see where they are set. The Neighbor
> > >list can have 255 BS in it. The 802.16E/D4 has a lot of
> > >information to support FBSS and soft handoff has the active set
> > >been adopted? Should there be a value to set a limit on the
> > >number in the active set? Also should there be a parameter that
> > >if set precludes a BS form becoming an anchor. As an operator I
> > >would not want a Pico cell end node with little backhaul serving
> > >as an anchor. If you can set an option that a BS cannot serve as
> > >an anchor and FBSS is to be supported then in 6.3.20.2.6 "When
> > >operating in FBSS, the MSS only communicates with the Anchor BS
> > >for UL and DL unicast messages and traffic" is an incorrect
> > >statement.
> > >
> > >
> > >
> > >David S. McGinniss
> > >
> > >Distinguished Member of Technical Staff
> > >
> > >Sprint Broadband Wireless Technology Development Group
> > >
> > >(630) 926-3184 david.s.mcginniss@mail.sprint.com
> > ><mailto:david.s.mcginniss@mail.sprint.com>
> > >
> > >
> >
>