--- a/src/lte/doc/source/lte-testing.rst Mon Dec 05 18:05:11 2011 +0100
+++ b/src/lte/doc/source/lte-testing.rst Mon Dec 05 19:20:19 2011 +0100
@@ -98,6 +98,26 @@
deals with floating point arithmetic approximation issues.
+E-UTRA Absolute Radio Frequency Channel Number (EARFCN)
+-------------------------------------------------------
+
+The test suite ``lte-earfcn`` checks that the carrier frequency used
+by the LteSpectrumValueHelper class (which implements the LTE spectrum
+model) is done in compliance with [TS36.101]_, where the E-UTRA
+Absolute Radio Frequency Channel Number (EARFCN) is defined. The test
+vector for this test suite comprises a set of EARFCN values and the
+corresponding carrier frequency calculated by hand following the
+specification of [TS36.101]_. The test passes if the carrier frequency
+returned by LteSpectrumValueHelper is the same as the known value for
+each element in the test vector.
+
+
+
+
+
+
+
+
System Tests
~~~~~~~~~~~~
@@ -331,45 +351,53 @@
Building Propagation Loss Model
-------------------------------
-The aim of the system test is to verify the integration of the BuildingPathlossModel with the lte module. The test exploits a set of three pre calculated losses for generating the expected SINR at the receiver counting the transmission and the noise powers. These SINR values are compared with the results obtained from a lte simulation. The losses are calculated off-line with an Octave script (/test/reference/lte_pathloss.m).
-
+The aim of the system test is to verify the integration of the
+BuildingPathlossModel with the lte module. The test exploits a set of
+three pre calculated losses for generating the expected SINR at the
+receiver counting the transmission and the noise powers. These SINR
+values are compared with the results obtained from a LTE
+simulation that uses the BuildingPathlossModel. The reference loss values are
+calculated off-line with an Octave script
+(/test/reference/lte_pathloss.m). Each test case passes if the
+reference loss value is equal to the value calculated by the simulator
+within a tolerance of :math:`0.001` dB, which accouns for numerical
+errors in the calculations.
-RLC UM tests
-------------
+RLC
+---
-A suite of unit tests validate the RLC UM implementation in
-isolation. The following tests have been implemented:
-
- * With a single transmitter RLC/UM, a known SDU arrival pattern, and
- a known Tx opportunity notification pattern passed to the RLC/UM by
- the MAC, check that the RLC PDUs created by the RLC/UM are correct.
- * With a single transmitter RLC/UM, a single receiver RLC/UM, and
- error-free RLC PDU delivery, check that a set of known SDUs are
- delivered correctly.
- * With a single transmitter RLC/UM, a single receiver RLC/UM, and
- erroneous RLC PDU delivery with a given RLC PDU loss pattern, check
- that all and only the RLC SDUs that should be delivered by the
- receiving RLC/UM are in fact delivered.
+Two test suites ``lte-rlc-um-transmitter`` and
+``lte-rlc-am-transmitter`` check that the RLC/UM and the RLC/AM
+implementation work correctly. Both these suites work by testing RLC
+instances connected to special test entities that play the role of the
+MAC and of the PDCP, implementing respectively the LteMacSapProvider
+and LteRlcSapUser interfaces. Different test cases (i.e., input test
+vector consisting of series of primitive calls by the MAC and the
+PDCP) are provided that check the behavior in the following cases:
-RLC AM tests
-------------
-
-Another suite of unit tests validates the RLC AM implementation in
-isolation. The following tests have been implemented:
+ #. one SDU, one PDU: the MAC notifies a TX opportunity causes the creation of a PDU which exactly
+ contains a whole SDU
+ #. segmentation: the MAC notifies a TX opportunity that is smaller than the SDU
+ size, which is then to be fragmented;
+ #. concatenation: the MAC notifies a TX opportunity that is bigger than the SDU, hence
+ multiple SDUs are concatenated in the same PDU
+ #. buffer status report: a series of new SDUs notifications by the
+ PDCP is inteleaved with a series of TX opportunity notification in
+ order to verify that the buffer status report procedure is
+ correct.
- * With a single transmitter RLC/AM, a known SDU arrival pattern, and
- a known Tx opportunity notification pattern passed to the RLC/AM by
- the MAC, check that the RLC PDUs created by the RLC/AM are
- correct.
- * With a single transmitter RLC/AM, a single receiver RLC/AM, and
- error-free RLC PDU delivery, check that a set of known SDUs are
- delivered correctly
- * With a single transmitter RLC/AM, a single receiver RLC/AM, and
- erroneous RLC PDU delivery with a given RLC PDU loss pattern, check
- that all and only the RLC SDUs that should be delivered by the
- receiving RLC/AM are in fact delivered
+In all these cases, an output test vector is determine manually from
+knowledge of the input test vector and knowledge of the expected
+behavior. These test vector are specialized for RLC/UM and
+RLC/AM due to their different behavior. Each test case passes if the
+sequence of primitives triggered by the RLC instance being tested is
+exacly equal to the output test vector. In particular, for each PDU
+transmitted by the RLC instance, both the size and the content of the
+PDU are verified to check for an exact match with the test vector.
+
+
@@ -406,6 +434,23 @@
received traffic pattern is detected for any UE, the test fails.
+TFT classifier
+--------------
+
+The test suite ``eps-tft-classifier`` checks in isolation that the
+behavior of the EpsTftClassifier class is correct. This is performed
+by creating different classifier instances where different TFT
+instances are activated, and testing for each classifier that an
+heterogeneous set of packets (including IP and TCP/UDP headers) is
+classified correctly. Several test cases are provided that check the
+different matching aspects of a TFT (e.g. local/remote IP address, local/remote port) both for uplink and
+downlink traffic. Each test case corresponds to a specific packet and
+a specific classifier instance with a given set of TFTs. The test case
+passes if the bearer identifier returned by the classifier exactly
+matches with the one that is expected for the considered packet.
+
+
+
End-to-end LTE-EPC data plane functionality
-------------------------------------------