| Harald Welte | 143f1f5 | 2009-10-26 20:38:37 +0100 | [diff] [blame] | 1 | oml interface design notes |
| 2 | |
| 3 | problems: |
| 4 | |
| 5 | * there is no way how to tag a command sent to the BTS, with the response |
| 6 | having the same tag to identify the originator of the command |
| 7 | * therefore, we can have e.g. both the BSC and the OML interface send a |
| 8 | SET ATTRIBUTE message, where the responses would end up at the wrong |
| 9 | query. |
| Holger Hans Peter Freyther | b7b6cf5 | 2012-08-06 12:41:45 +0200 | [diff] [blame] | 10 | * The BTS has 10s to ACK/NACK a command. We do not run any timers. |
| Harald Welte | 143f1f5 | 2009-10-26 20:38:37 +0100 | [diff] [blame] | 11 | |
| 12 | the only possible solutions i can imagine: |
| 13 | * have some kind of exclusive locking, where the OML interface gets blocked |
| 14 | from the BSC and is exclusively assigned to the OML console until all commands |
| 15 | of the OML console have terminated. This can either be done explicitly |
| 16 | dynamically or on demand |
| 17 | |
| 18 | * use the OML interface synchronously, i.e. always wait for the response from |
| 19 | the BTS before |
| 20 | |
| 21 | * unilateral / unsolicited messages need to be broadcasted to both the BSC and |
| 22 | the OML console |