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>
>
>