Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] [STDS-802-16-MOBILE] [Harmonization] Re: Questi on for FBSS



Phil and All,
 
I find BS-to-BS stuff necessary and useful. Let me note also that the 802 practice more or less follows definition of 802 scope. This is the reality .   
 
Concerning SHO/FBSS, I believe there is a bunch of omissions, ambiguities and inconsistencies. I don't know what is "some type of stateless HO condition",
so I cannot judge whether it is true. I have a list of simple questions and cannot find answers.
 
 When MSS communicates simultaneously to several BSs [during SHO], is it registered at all of them? If not, then there are no connections, so impossible to communicate. If yes, how does it happen? Section 6.3.20.4 describes what happens at network entry / re-entry. But is it relevant to SHO?  My perception is that SHO is defined as a middle state
of handover [I say "perception" because the text is ambiguous] . First state is when MSS registered at Serving BS, second is SHO, third is MSS registered at [single] Target BS.
This is in line with 6.3.20.2 which defines the HO as "process in which an MSS migrates from the air-interface provided by one BS to the air-interface provided by another BS".
If this understanding of states is correct, 6.3.20.4 [talking on network re-entry at Target BS] is not relevant to transition between first state and second.
So marriage between MSS and BS from Active Set is not a network re-entry and there is no description of the procedure.
 
Contribution #171 [prototype of 6.3.20.2.6] at page 1 provides definition of all involved parties that confirms above understanding of states [not included in normative text].
 
We can speculate more, read more related contributons, compare our perceptions, but it only means that the text is ambiguous and probably inconsistent.
 
Vladimir
-----Original Message-----
From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Thursday, August 12, 2004 11:07 AM
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] [STDS-802-16-MOBILE] [Harmonization] Re: Question for FBSS

Vladimir and All,
 
As has been said previously in this list, in the definition "LAN and MAN standards, mainly [emphasis added] for the lowest 2 layers of the Reference Model for Open Systems Interconnection (OSI)", mainly is not only. There is a very important distinction. And there have been and continue to be 802 WGs that deal with non-PHY and MAC, higher layers normative specification. I believe my previous analysis holds true on PAR scope.
 
Regarding your observations on the shortcomings of the approved SHO/FBSS text, I agree that the language needs clarification and revision. Relationship of Anchor BS as Serving BS comes to mind. I do not agree that the revision requires creation of the logical constructs definitions in 16e you identify. I believe that those definitions are more appropriate in NetMan and not necessary to the MSS-to-BS communications standard. If it were voodoo magic that made some of those features work (synchronized BS communications; etc...), it would not matter to the air interface, so long as it works. Of course we must have confidence that the features can be reliably implemented in order to justify inclusion in the standard. Given that those mechanisms work in current cellular technologies, I think we can have confidence that the mechanisms do in fact work and we can identify them in NetMan adequately to support their function in 16e.
 
Your observation that SHO/FBSS uses some type of stateless HO condition is not true. SHO/FBSS uses the fully optimized HO mechanism in the standard for BS enjoying full context sharing and state management, with a minor twist. Essentially SHO/FBSS is no different than normal optimized HO except that it uses a special HO notification mechanism and a special control list to assure that the Target BS has all of its information. But the SHO/FBSS is consummated through RNG-REQ/RSP optimized sequencing including any necessary re-mapping just like regular optimized HO process.
 
Thanks,
Phil
 
----- Original Message -----
Sent: Thursday, August 12, 2004 2:33 AM
Subject: RE: [STDS-802-16] Fw: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS

Phil, Dave and All,
 
IEEE 802 deals with "LAN and MAN standards, mainly for the lowest 2 layers of the Reference Model for Open Systems Interconnection (OSI)"
There were many discussions on BS-to-BS communication at initial stage of 16e. The consensus was more or less
that "we need it though it is out of the scope of 802.16, let's put it into informational addendum". Compare it to AP-to-AP communication (802.11F) which is
not a standard document, but "recommended practice" document. BS-to-BS communication stuff in 16e is not really interop specifications as it does not
contain spec of underlying network layers for BS-to-BS interconnection.
 
Back to the "anchor problem", I understand Dave's concern because I have yet more concerns :-(
Section 6.3.20.2.6 in 16e/D4 is so unclear [including language] that I wrote the following set of comments/ questions.
I believe that without clarification of #1 and #5 one cannot really understand what is going on. Item #4 looks like show stopper.
 
Concerning #2, in Portlan I tried to clarify with  contributirs of #170 and #171 what must be model of BS for which SHO/FBSS may be possible.
Actually for Active Set of BSs there must be a common MAC controller connected to several PHY transceivers by communication lines.
If MAC controller is far away from the transceivers, microwave connection may add tens of milliseconds to MAC round trip delay [example: BR-allocation latency].
High delay will harm communication with all MSSs including those not in SHO/FBSS mode [majority of MSSs].  
To keep delay low we should have all transceivers close to MAC processor [e.g. at same backplane]. 
 
Anyway, Active Set must contain only those BSs that have common MAC controller. Apparently such BSs come in sets, so capability to participate in
Active Set is not individual capability, but rather group capability.  
 
 
  1. There is a need in detailed specification of PHY scenarios for SHO/FBS [similar to "SHO Based Macro-Diversity Transmission Scenarios" in IEEE C802.16e-04/170r1]. For MAC operations there is a big difference between RF level combining, soft combining and selection diversity.
  2. The assumption of SHO is that state machines of MAC [of specific connections] at all BSs from Active Set are tightly synchronized. At SHO two BSs must transmit SAME PHY BURST at DL that means concatenation of same MAC PDUs with same payloads, headers/subheaders, CIDs, BSNs. Can it be practically implemented other way than having a single MAC processor in which the whole burst payload is being built and then distributed to several BS transceivers? Obviously not all BSs will be implemented this way. It means that ability to participate in Active Set must be a not individual capability of BS but GROUP capability [group consists of BSs having "common MAC processor"]. So the standard needs a language to describe capability of this type. There must be a definition of process MSS follows to learn such group capability. Possible implementation: a "L1 combining group ID" might be assigned to relevant BSs so that if for two BSs "group IDs" are equal, they have "common MAC processor" and therefore may be a part of same Active Set. 
  3. All other topics of standard consider one MSS - one BS relationship. SHO/FBSS topic is the only one that considers one MSS - many BSs relationship. So there is a need in definition of "anchor BS -MSS", "non-anchor BS - MSS" etc. relationship. Operations [like "Anchor BS update"] must be described in these terms. See also #4.
  4. It is not clear from tte text at which BS the MSS is registered while in SHO/FBSS state. According to the rest of definitions in 802.16-2004/802.16e, MSS is either registered at certain BS [then having specific connections associated with specific Service Flows, security context etc.] or it is not [and then there is no network data transfer between the MSS and the BS]. If the answer is that MSS in SHO/FBSS state is not registered to any BS then there are no authentication relationship and no MAC connections between BSs and MSS and therefore most of MAC definitions is not applicable.
  5. There is a need in certain set of conditions (assumptions) for SHO/FBSS procedures to be applicable (like frame clock synch  - see original contribution #171r1).
  6. Definitions of terms SHO and FBSS are absent (see contribution #171r1).
  7. Why described "SHO" ["FBSS"] procedure is referred to as "handover"? MSS may stay registered at certain BS just using diversity combining of any sort. Seems more logical to redefine "SHO state" as e.g. "L1 combining with respect to Active Set X " [FBSS as "L2 combining"], both not necessarily related to any HO. Then handover of certain type will include a phase when the MSS is in "SHO" state. 
  8. FBSS is not a good name as the closest association is changing serving BSs i.e. regular handover
  9. Combining SHO and FBSS specs in same sections makes text too complicated
The following fragment of the text shows language problems [my comments appear in bold]
 
6.3.20.2.6 SHO and FBSS Decision and Initiation
While in SHO or FBSS, the MSS and the BS [which BS? There might be several related to the MSS] shall maintain a list of BSs that are involved in SHO or FBSS with the MSS. The list is called the Active Set. Among the BSs in the Active Set, an Anchor BS is defined.
When operating in FBSS, the MSS only communicates with the Anchor BS for UL and DL unicast messages and traffic [Very unclear language. All UL MAC Messages are unicasts as they have unicast CID in generic MAC header; so unclear what is "UL unicast messages". Traffic is carried as a payload of MAC messages; so unclear what is "messages and traffic"]. When operating in SHO, the MSS communicates with all BSs in the Active Set for UL and DL unicast messages and traffic. [See previous comment about the language. Also does MSS receive from all BSs e.g. RNG-RSP messages (which are unicast)? If yes, then which value of time offset (measured at which BS) is encoded in this message? ]
 
Rest of the text looks similar.
Looks like the SHO/FBSS text needs to be re-written.
 
Vladimir
 
 
 
 
-----Original Message-----
From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Monday, August 09, 2004 1:46 AM
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] Fw: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS

I tried posting this before with no luck. I Thought I would try again.
 
Thanks,
Phil
 
----- Original Message -----
Sent: Saturday, August 07, 2004 11:07 AM
Subject: Re: [STDS-802-16-MOBILE] [Harmonization] Question for FBSS

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


This mail passed through mail.alvarion.com

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
This mail was sent via mail.alvarion.com

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************


This mail passed through mail.alvarion.com

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
This mail was sent via mail.alvarion.com

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************