Re: stds-80220-eval-criteria: Joint UL/DL simulations?
Dear Khan
I do not think that DL/UL simulation can be achieved simultaneously at the same simulation run.You made an example for joint DL/UL simulation using HTTP operation with TCP Ack. In simulation, all traffic model shall be modeled as a probability function.Therefore, when make a simulation model interactive service such as web browsing or VoIP, we should take a traffic generation pattern every burst (burst size, idle duration, etc.) to generate the response traffic on the UL, furthermore, if we consider channel error or corrupted transmission, it is impossible that we can make a simulation set with DL/UL jointly.
Therefore, I think that the simulation should be achieved for DL and UL, respectively.
Regarding simulation run time..You told that the simulation run time would be the same. But I do not think so, Simulation run time would not be proportional increasing so that the joint DL/UL simulation requires longer simulation time. Addition to, we shall simulate the joint DL/UL model on the same machine, however, if we separate two simulation package, we can choose the shorter simulation run time from two different machines.
Regarding overhead and error modeling for separated simulation.
I think that this overhead modeling would be natural things. It requires the DL overhead (resource allocation) and its error probability. They can be provided or defined quantively. Of course this modeling approach may not be realistic...
However, to get stable and reasonable simulation results in shorter simulation time, we need a simplified simulation modeling keeping somewhat reasonable environment.
----- Original Message -----
From: "Khan, Farooq (Farooq)" <fkhan1@lucent.com>
To: <stds-80220-eval-criteria@ieee.org>
Sent: Wednesday, August 06, 2003 12:12 AM
Subject: stds-80220-eval-criteria: Joint UL/DL simulations?
>
> Another issue that I would like to discuss over tomorrow's conference call is whether the system simulations for the downlink and uplink be done separately or jointly. We need to determine this in order to move forward on specifying different simulation models in the Evaluation criteria.
>
> In the joint UL/DL simulations, both the uplink and downlink are simulated simultaneously in the same simulation run. Statistics on both uplink and downlink performance can be collected at the end of the simulation run. In the joint simulations, both directions of the traffic are simulations. For example, in case of web browsing application, HTTP requests would be simulated on the UL and HTTP response on the DL. Similarly, TCP segments in one direction and the TCP ACKs in the other direction. This would also apply to any MAC layer signaling etc. For example, MAC PDUs transmission in one direction and ACK/NACKs in the other direction.
>
> In the separate uplink/downlink simulations, the uplink and downlink are simulated in separate simulation runs and statistics are collected from these separate runs. For example, in case of web browsing application, HTTP response would be modeled in the DL simulations and HTTP request separately in the uplink simulations. One of the issues with separate DL/UL simulations is that some delay/bandwidth and error models would be needed for the traffic part on the link direction not simulated. Again assuming a web browsing application, HTTP request delay and error needs to be modeled on the UL for web browsing simulations on the DL.
>
> The separate UL/DL simulations may provide the benefit of faster simulation times (separately) because the details of only a single direction are simulated. However, two sets of simulations would be needed, one for the UL direction and other for the DL direction. In the joint simulations, details of both directions are simulated simultaneously and therefore the simulation run time can be longer. But the benefit is that a single set of simulations would be required. Therefore, in terms of total simulation time, both approaches can be equivalent. However, the joint approach provide a more realistic scenario and does not require additional delay/error models.
>
> Comments and suggestions are welcome,
>
> Farooq
>
>
>
>