add some random thoughts on hopping and the oml interface
diff --git a/openbsc/doc/gsm-hopping.txt b/openbsc/doc/gsm-hopping.txt
new file mode 100644
index 0000000..5910939
--- /dev/null
+++ b/openbsc/doc/gsm-hopping.txt
@@ -0,0 +1,54 @@
+according to GSM 05.02:
+
+general parameters from CCCH:
+* CA cell allocation of ARFCN's (System Information / BCCH)
+* FN: TDMA frame number (t1,t2,t3') in SCH
+
+specific parameters from channel assignment:
+* MA: mobile allocation, defines set of ARFCN's, up to 64
+* MAIO: index
+* HSN: hopping sequence generator number (0..64)
+
+
+hopping sequence generation (6.2.3):
+
+u_int8_t rntable[114] = {
+ 48, 98, 63, 1, 36, 95, 78, 102, 94, 73,
+ 0, 64, 25, 81, 76, 59, 124, 23, 104, 100,
+ 101, 47, 118, 85, 18, 56, 96, 86, 54, 2,
+ 80, 34, 127, 13, 6, 89, 57, 103, 12, 74,
+ 55, 111, 75, 38, 109, 71, 112, 29, 11, 88,
+ 87, 19, 3, 68, 110, 26, 33, 31, 8, 45,
+ 82, 58, 40, 107, 32, 5, 106, 92, 62, 67,
+ 77, 108, 122, 37, 60, 66, 121, 42, 51, 126,
+ 117, 114, 4, 90, 43, 52, 53, 113, 120, 72,
+ 16, 49, 7, 79, 119, 61, 22, 84, 9, 97,
+ 125, 99, 17, 123
+};
+
+/* mai=0 represents lowest ARFCN in the MA */
+
+
+u_int8_t hopping_mai(u_int8_t hsn, u_int32_t fn, u_int8_t maio,
+ u_int8_t t1, u_int8_t t2, u_int8_t t3_)
+{
+ u_int8_t mai;
+
+ if (hsn == 0) /* cyclic hopping */
+ mai = (fn + maio) % n;
+ else {
+ u_int32_t m, m_, t_, s;
+
+ m = t2 + rntable[(hsn xor (t1 % 64)) + t3];
+ m_ = m % (2^NBIN);
+ t_ = t3 % (2^NBIN);
+ if (m_ < n then)
+ s = m_;
+ else
+ s = (m_ + t_) % n;
+ mai = (s + maio) % n;
+ }
+
+ return mai;
+}
+
diff --git a/openbsc/doc/oml-interface.txt b/openbsc/doc/oml-interface.txt
new file mode 100644
index 0000000..8ddcfea
--- /dev/null
+++ b/openbsc/doc/oml-interface.txt
@@ -0,0 +1,21 @@
+oml interface design notes
+
+problems:
+
+* there is no way how to tag a command sent to the BTS, with the response
+ having the same tag to identify the originator of the command
+* therefore, we can have e.g. both the BSC and the OML interface send a
+ SET ATTRIBUTE message, where the responses would end up at the wrong
+ query.
+
+the only possible solutions i can imagine:
+* have some kind of exclusive locking, where the OML interface gets blocked
+ from the BSC and is exclusively assigned to the OML console until all commands
+ of the OML console have terminated. This can either be done explicitly
+ dynamically or on demand
+
+* use the OML interface synchronously, i.e. always wait for the response from
+ the BTS before
+
+* unilateral / unsolicited messages need to be broadcasted to both the BSC and
+ the OML console