gsm_data: use ascending order for interference boundaries

It's more logical to have the boundaries sorted in ascending order:

  * band 1 represents lowest interference levels,
  * band 5 represents highest interference levels.

Change-Id: Ie9bf4bf0c89418685b8ea5096332d22cfba7c521
Related: SYS#5313

4 files changed, 16 insertions, 16 deletions

diff --git a/doc/manuals/chapters/interf_meas.adoc b/doc/manuals/chapters/interf_meas.adoc
index 62b08c4ae..c82ff4907 100644
--- a/doc/manuals/chapters/interf_meas.adoc
+++ b/doc/manuals/chapters/interf_meas.adoc
@@ -19,7 +19,7 @@ Below are the default values for them:
 network
  bts 0
   interference-meas avg-period 6 <1>
-  interference-meas level-bounds -85 <2> -91 -97 -103 -109 -115 <3>
+  interference-meas level-bounds -115 <2> -109 -103 -97 -91 -85 <3>
 ----
 <1> Averaging period (`Intave`) in SACCH multiframe periods (480ms).
 <2> Interference level boundary `0` (in dBm).
@@ -34,11 +34,11 @@ According to 3GPP TS 48.008, there exist five interference bands and six
 averaged interference levels (initially in dBm) into these 5 bands.
 
 ----
--85 dBm    -91 dBm    -97 dBm   -103 dBm   -109 dBm   -115 dBm
-   | <1>      | <2>      | <3>      | <4>      | <5>      | <6>
-   +----------+----------+----------+----------+----------+
-   |  band 1  |  band 2  |  band 3  |  band 4  |  band 5  |
-   +----------+----------+----------+----------+----------+
+-115 dBm   -109 dBm   -103 dBm    -97 dBm    -91 dBm    -85 dBm
+    | <1>      | <2>      | <3>      | <4>      | <5>      | <6>
+    +----------+----------+----------+----------+----------+
+    |  band 1  |  band 2  |  band 3  |  band 4  |  band 5  |
+    +----------+----------+----------+----------+----------+
 ----
 <1> Interference level boundary `0` (outer).
 <2> Interference level boundary `X1`.
@@ -49,7 +49,7 @@ averaged interference levels (initially in dBm) into these 5 bands.
 
 Unfortunately, it's not clearly defined by 3GPP how the BTS is supposed to map
 dBm values outside of the outer boundaries (`0` and `X5`) to band values.  The
-ip.access nanoBTS, for example, would map values -75 dBm and -120 dBm to bands
+ip.access nanoBTS, for example, would map values -120 dBm and -75 dBm to bands
 1 and 5, respectively.  osmo-bts replicates this behavior.
 
 === PDCH and dynamic timeslot handling
diff --git a/src/osmo-bsc/gsm_data.c b/src/osmo-bsc/gsm_data.c
index 0134e34c9..988d70efa 100644
--- a/src/osmo-bsc/gsm_data.c
+++ b/src/osmo-bsc/gsm_data.c
@@ -1120,12 +1120,12 @@ enum gsm48_rr_cause bsc_gsm48_rr_cause_from_rsl_cause(uint8_t c)
 const struct gsm_interf_meas_params interf_meas_params_def = {
 	.avg_period = 6, /* 6 SACCH periods */
 	.bounds_dbm = {
-		 85, /*  0:  -85 dBm */
-		 91, /* X1:  -91 dBm */
-		 97, /* X2:  -97 dBm */
-		103, /* X3: -103 dBm */
-		109, /* X4: -109 dBm */
-		115, /* X5: -115 dBm */
+		115, /*  0: -115 dBm */
+		109, /* X1: -109 dBm */
+		103, /* X2: -103 dBm */
+		 97, /* X3:  -97 dBm */
+		 91, /* X4:  -91 dBm */
+		 85, /* X5:  -85 dBm */
 	},
 };
 
diff --git a/tests/nanobts_omlattr/nanobts_omlattr_test.c b/tests/nanobts_omlattr/nanobts_omlattr_test.c
index 0b9f6d9bb..1b3cc8e5f 100644
--- a/tests/nanobts_omlattr/nanobts_omlattr_test.c
+++ b/tests/nanobts_omlattr/nanobts_omlattr_test.c
@@ -163,7 +163,7 @@ int main(int argc, char **argv)
 	bts->location_area_code = 1;
 	bts->gprs.rac = 0;
 	uint8_t attr_bts_expected[] =
-	    { 0x19, 0x55, 0x5b, 0x61, 0x67, 0x6d, 0x73, 0x18, 0x06, 0x0e, 0x00,
+	    { 0x19, 0x73, 0x6d, 0x67, 0x61, 0x5b, 0x55, 0x18, 0x06, 0x0e, 0x00,
 		0x02, 0x01, 0x20, 0x33, 0x1e, 0x24, 0x24, 0xa8, 0x34, 0x21,
 		0xa8, 0x1f, 0x3f, 0x25,
 		0x00, 0x01, 0x0a, 0x0c, 0x0a, 0x0b, 0x01, 0x2a, 0x5a, 0x2b,
diff --git a/tests/nanobts_omlattr/nanobts_omlattr_test.ok b/tests/nanobts_omlattr/nanobts_omlattr_test.ok
index 2f3ff771e..e1029a4bf 100644
--- a/tests/nanobts_omlattr/nanobts_omlattr_test.ok
+++ b/tests/nanobts_omlattr/nanobts_omlattr_test.ok
@@ -1,6 +1,6 @@
 Testing nanobts_attr_bts_get()...
-result=  19555b61676d7318060e00020120331e2424a83421a81f3f2500010a0c0a0b012a5a2b03e80a0d230a080362093f99000700f11000010539
-expected=19555b61676d7318060e00020120331e2424a83421a81f3f2500010a0c0a0b012a5a2b03e80a0d230a080362093f99000700f11000010539
+result=  19736d67615b5518060e00020120331e2424a83421a81f3f2500010a0c0a0b012a5a2b03e80a0d230a080362093f99000700f11000010539
+expected=19736d67615b5518060e00020120331e2424a83421a81f3f2500010a0c0a0b012a5a2b03e80a0d230a080362093f99000700f11000010539
 ok.
 
 Testing nanobts_attr_nse_get()...