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

[STDS-802-16] FW: [STDS-802-16] LE Ad-hoc-BS-BS Interf-Call for solutions-take this



Hi,

I received an e-mail from Nico, with the suggestion to use,
 for BS co-location, a higher antenna isolation value.

According to his computations and field experiments,
 Nico obtained 75dB antenna isolation, when
 mounted at 1m distance. Also, he attentionned myself
 that I forgot to take the ACI into account for this case.

So I changed the attached document and the conclusion
 text, that should read for A:

A. The performance is affected when using co-located sectors.
 For example, at 1m distance between antenae, with -12dB
 ACI, the interference level is aprox. -67dBm.

I still miss ACI values for OFDM, at QPSK 1/2. In standard
 are only values for 16QAM.

Kind Regards,

Marianna

P.S. Many thanks to Nico

-----Original Message-----
From: Marianna Goldhammer
Sent: Thursday, March 25, 2004 6:39 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: [STDS-802-16] LE Ad-hoc - BS-BS Interference - Call for solutions
Importance: High


Dear Folks,

I just finished with the analysis of BS-BS Interference,  NO
synchronization, for 5.8GHz.
Igal requested the addition of 2.4GHz, but meanwhile did not
 provide System Parameters.

1. The summary of the results is:

A. co-location: not possible, the Rx radio will be saturated;

B. minimum distance between BSs, due to adjacent channel
 interference, for 1dB RSL degradation and 10dB fade margin:
   - directional antennae and no co-ordination: 3.7km
   - one omni and one directional antenna: 1.64km
This means that if a system is up and running, and another BS
 will be installed at a distance lower than mentioned above, the
 remote users will loose connection (service disruption).

C. minimum distance between BSs, co-channel interference:
 more than 60km, for both cases. Same consequences as
 above.

All the computation details and explanatory figures are in the
 attached document.

2. I think that the problem to be resolved is clear, for this scenario.
 If somebody thinks otherwise, please let me know. Lets keep
 focus and go forward, to address, according to the charter:
 "Identification of techniques which may mitigate the problem,
 such as dynamic frequency selection, time co-ordination,
 creation of interference free periods, etc;"
So please send to the reflector your solutions; I have added to
 the document a page were we will centralize the comments and
 replay comments; no need to use the commentary: for your
 convenience, I will centralize the e-mails.

 Comments already received(Zion,Phil,Duncan) are reflected
 there. I added my comment:

"Use PHY sync of MAC Frames and Tx/Rx:
Co-ordination possible: Frame start - PHY Sync marker and MIB
 for Frame duration, Tx and Rx intervals.
Co-ordination not possible (private use): PHY only mechanism.
Systems may use GPS or follow the Sync Markers of already
 deployed systems."

Kind Regards,

Marianna

P.S. If somebody can help, and make the computations for the
 remaining scenarios, will be really useful.

Marianna Goldhammer
IEEE 802.16 LE-Ad-hoc Chair




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

C802.16-04_NNr3.doc