add some random thoughts on hopping and the oml interface
This commit is contained in:
parent
eb429b7b44
commit
143f1f56d9
|
@ -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;
|
||||||
|
}
|
||||||
|
|
|
@ -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
|
Loading…
Reference in New Issue