| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dave,
A couple more comments here to try to address your questions.
Regarding the relationship of Anchor BS with the actual network architecture, Anchor BS as defined in .16e is from over-the-air perspective. For the case of FBSS, Anchor BS is the BS that transmit/receive control signalling and traffic over-the-air to/from the MSS. For the case of SHO, Anchor BS is the BS that transmits DL/UL-MAP to the MSS. The above definition is independent of whether the actual network configuration is decentralized or centralized. In a network configuration that consists of BSC/APC, one of the BTS/AP (typically the one with the strongest CINR) within the active set will be the Anchor BS from over-the-air perspective.
You raised a good point regarding the need to prevent a BS from being selected as the Anchor BS for the case of FBSS. One way to do this is not to include this BS in the Active Set of the MSS, since this BS will not be selected as an Anchor BS anyway. Note that Active Set membership is controlled by the BS side through MOB_BSHO_RSP message.
Please let me know if you have any further comments.
Regards,
Mo-Han
-----Original Message-----
From: owner-stds-802-16-mobile@listserv.ieee.org [mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of Mary Chion
Sent: Tuesday, August 03, 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>
-----Original Message-----
From: owner-stds-802-16-mobile@listserv.ieee.org
[mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of Mary Chion
Sent: Monday, August 02, 2004 9:21 AM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS
Hi, Jay nad Inkyu,
This is Mary Chion. Sorry about the late reply.
In FBSS, only one BS will be communicating with the MSS at any time instance (the anchor BS). The BS can choose one of the BS in the active set to be the anchor BS through MOB-BSHO-REQ/RSP message. Once the MSS confirms the HO with MOB-HO-IND, The MSS should only expect trasmission from the anchor BS.
Regarding the question of which BS have the data, it's really an implementation issue, it also depends on what kind of network architecture you will be using. If your network architecture includes a control point for the BSs (i.e. BSC), the control point can buffer the data and only send to current anchor BS. When a new anchor BS is chosen, the conotrl point will just redirect the traffic. With distributed system, the anchor BS should be resposible for the data. When the ahcnor BS is changed, the old anchor BS can forward data to the new anchor BS. The above scenarios are only examples, the implementatios can be different from each company and should not be specified in the standard.
Regards,
Mary
-----Original Message-----
From: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG]On Behalf Of Inkyu Paek
Sent: Monday, August 02, 2004 7:00 AM
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS
To my knowledge, all BS's in an active set share same data for an MSS.
Am I right?
Regards,
Inkyu Paek
hanarotelecom
----- Original Message -----
From: kihyoung <mailto:kihyoung@LGE.COM>
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
<mailto:STDS-802-16-MOBILE@LISTSERV.IEEE.ORG>
Sent: Monday, August 02, 2004 5:26 PM
Subject: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS
Dear MO-han
I have a quick question for my clarification.
I wonder which BSs are responsible for having Data for an MSS in FBSS(Fast BS Switching).
Do all BSs in active set have to share same data for an MSS?
OR,
Only a serving BS has data for an MSS then forwards the data to an anchor BS?
Thanks in advance.
Best regard.
jay
--------------------------------------------
Yongseok (jay) Jin
Research Engineer
Standards & System Research Group
Mobile Communication R&D Center, LG Electronics Inc.
--------------------------------------------
Phone:+82-(0)31-450-7187
Mobile:+82-(0)11-9953-3149
Fax:+82-(0)31-450-7912
e-mail: jayjay@lge.com
---------------------------