stds-80220-eval-criteria: PHY/MAC/Networking simulation approaches
Still responding to Marianna's msg about simulation ..
but I have changed the subject since this is a different topic.
It touches upon the larger discussion of
full-TCP v. "selected TCP mechanisms such as handshake, slow start".
On the issue of simulation appraoches,
I have had success with taking
the aggregate PHY rate (and also a more sophisticated approach
that uses a channel model that changes rates and error
conditions based on proportion statistics), and using
traffic models to measure ECR (equiv. circuit rate).
This approach gives you results like no of users
for particular ECR. But it glosses over detail effects.
But is faster, less complex, and sometimes
more insightful compared to other options.
It is still valid. Depends on what the objective is.
This approach decouples the detail effets of
traffic/network modeling and radio-layer (PHY/MAC) modeling.
On the other hand, if you want to capture the
dependance of the user experience on the
interactions of the traffic model with the
underlying MAC/PHY model, then you cannot decouple so easily.
e.g. if there are bursty errors, then a
TCP-based session can go into a timeout situation
and be dead for many seconds even if the channel
recovers. You would not see this type of
effect if you look at the average rate.
The right approach depends on what the objectives
and the constraints are.
My personal observation: ...
Accurate radio layer (PHY/MAC/interference) simulations
are complex, and the output is often the statistics
of C/NI conditions and possible rates. (along the lines
of what you have said).
The next step is to capture the effect of
traffic/packet statistics and how each particular
user modem switches rates, and retransmits.
This dramatically increases the complexity
of the simulation.
As applications become more bursty and have
protocol dependencies (e.g. Web on TCP), the
trend in the simulation community is to simulate
more and more details. This is aided by computers
becoming faster. This is the trend for simulation packages
like Opnet, ns2, and Glomosim/Qualnet which are now being
used to simulate all the way from Web to TCP to IP to MAC to PHY.
This comprehensive approach is often driven
by the networking community and the PHY/MAC
can sometimes get left behind. For popular
standards like 802.11, MAC/PHY models have been
added. Even there, the MAC is more accurate than
the PHY. Simple PHY can capture signal, noise, and
interference. But fast effects, coding effects,
delay spread issues etc. are not fully addressed.
The good news is that people continue to work
on improving MAC/PHY models in a way that fits into
the network simulation packages. (All these are very
recent developments). My personal opinion is that
the PHY/MAC simulation models have to fit into the
rest of the simulation methodologies if you want
to simulate all the application/protocol effects.
The PHY details will beed to be abstracted, and
the right topic of discussion would be what kind
of abstraction is acceptable. e.g. how accurate is
it to take a set of bit-rates/error-rate and their
probabilities and use that in a simulation.
- Shankar
-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Thursday, July 31, 2003 11:40 AM
To: Shankaranarayanan,N K (Shankar); stds-80220-eval-criteria@ieee.org
Subject: RE: stds-80220-eval-criteria: Deplyment for simulations (was
FW: Non-member submission from [<shankar@research.att.com>]
Hi Shankar,
My experience goes with deployment simulations, for the central cell,
with the scope to receive the C/(N+I) distribution in the central cell.
For a given BER and a given modulation+coding combination,
you will have a given C/(N+I) threshold.
So you will be able to evaluate the percentage of the users that can
use a given modulation+coding (you will look always at the max. rate
possible in a given location), and after that you may calculate the
average PHY data rate over the cell. This rate may be used for net
capacity calculation, using traffic models or evaluating the MAC+PHY
efficiency.
Another simulation output will be the combination of PHY rates, and
for voice traffic for example, you will be able to simulate the traffic
using different rates, working with the found percentages and
proportionally combining the rates.
This is the way we simulate.
What do you think?
Marianna
-----Original Message-----
From: shankar@research.att.com [mailto:shankar@research.att.com]
Sent: Thursday, July 31, 2003 5:08 PM
To: Marianna Goldhammer; stds-80220-eval-criteria@ieee.org
Subject: RE: stds-80220-eval-criteria: Deplyment for simulations (was
FW: Non-member submission from [<shankar@research.att.com>]
Dear Marianna,
I agree that CDMA and TDMA are different.
But the main issue would be the kind
of simulation that can be done. Both systems
can still be treated similarly
in the kind of simulation that I
am thinking about.
I am not sure I fully understand the
kind of simulations that you are talking about.
The wrapping discussion applies only if
the details of packet/signal tx/rx are
simulated in the nodes in all the 19 cells.
I suspect your simulation may not
be like this.
There is nothing wrong with analyzing
only the center cell. Wrapping gives you
some simulation efficiency advantage.
But it may not be a valid option in
some cases.
- Shankar
-----Original Message-----
From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
Sent: Thursday, July 31, 2003 6:02 AM
To: Klerer Mark; 'stds-80220-eval-criteria@ieee.org';
Shankaranarayanan,N K (Shankar)
Subject: RE: stds-80220-eval-criteria: Deplyment for simulations (was
FW: Non-member submission from [<shankar@research.att.com>]
Dear Shankar,
I think that there is a difference between CDMA and TDMA systems,
related to the required complexity of deployment simulations.
CDMA systems, to improve capacity, use "multi-user detection"
algorithms. TDMA systems do not care about other user detection.
The TDMA companies do not have the needed tools, to perform CDMA like
simulations. Also do not need them.
So I propose to use for TDMA systems the basic 19 cell deployment,
analyzing only the behavior of the center cell.
Kind Regards,
Marianna
-----Original Message-----
From: Klerer Mark [mailto:M.Klerer@flarion.com]
Sent: Wednesday, July 30, 2003 7:07 PM
To: 'stds-80220-eval-criteria@ieee.org'
Subject: stds-80220-eval-criteria: FW: Non-member submission from
[<shankar@research.att.com>]
Forwarded on behalf of a non-member.
-----------------
From: <shankar@research.att.com>
To: <stds-80220-eval-criteria@ieee.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ruebert.ieee.org
id h6UG19bv021201
As promised at the July meeting, here is
a reference on "hexagonally wrapped"
cellular topologies. This paper is available
on IEEE Explore. This paper talks
about general cases, including the specific
case of 19 cells. The specific case
of 19 cells is also discussed in the
appendix of the 1xEV-DV document in the
drop-box.
If the simulation involves
full simulation of all bases and mobiles
(as opposed to some abstracted cumulative
interference from boundary cells), there
is no difference in complexity or time
between the wrapped and non-wrapped simulations.
The advantage of wrapping is that there are
more (19x times) results and that increases
the statistical efficiency of each run.
The number of cells simulated in the
wrapped case is still 19.
For each receiver, the transmitter position
may get transformed to another "wrapped" position
such that every receiver appears to have
two tiers of 6+12=18 interferers around it.
As discussed in the meeting, there
may be subtle issues if the relative positions
of the mobiles/bases have some
complex inter-dependencies.
The question to ask is: If a transmitter T1
appears at one place for receiver R1, and
appears to be at another place for receiver R2,
(at no point will any one receiver see multiple
signals from T1), does that affect R1, R2,
or some third-party R3 that is trying to
manage multiple things. It may mess up some kind
of referred/derived topology map if
R2 were to later communicate to R1 about its
perceived location of T1.
By the way, note that 19 is a prime number.
If the reuse pattern involves a cluster
of 3 or 4 or 7 cells, then there is an
issue of the pattern not repeating itself.
- N. K. Shankar
=============
Symmetric cellular network embeddings on a torus
Iridon, M. Matula, D.W.
This paper appears in: Computer Communications and Networks, 1998.
Proceedings. 7th International Conference on Meeting Date: 10/12/1998
-10/15/1998 Publication Date: 12-15 Oct 1998
Location: Lafayette, LA , USA
On page(s): 732-736
References Cited: 9
IEEE Catalog Number: 98EX226
Number of Pages: xxii+929
INSPEC Accession Number: 6220023
------------------------------------------------------------------------
Abstract:
Infinite planar cellular networks are embedded on a torus to obtain a
symmetric regular finite network sample region for performance analysis.
We show that a "hexagonal wrap" toroidal embedding preserves
translational and rotational symmetry on all three axes of a hexagonal
lattice and is preferable to a "Cartesian wrap" embedding. Hexagonal
tilings and embeddings are obtained for all rhombic tile sizes. Certain
tilings are shown to provide modular based neighbor addressing schemes
that simplify distributed channel assignment algorithms. Hierarchical
"hexagons within a hexagon" tilings are illustrated with the large
hexagon exhibiting the sample repeat and comprising a multiplicity of
channel frequency repeat small hexagonal the clusters. The symmetric
hexagonal sample region repeat embeddings are noted to be useful for
probabilistic analysis of high utilization channel assignment
performance both theoretically and by simulation
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.
************************************************************************
************