add some random thoughts on hopping and the oml interface
This commit is contained in:
parent
1ebac14b51
commit
2930bb9b4b
|
@ -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