Attention is currently required from: osmith, pespin.
1 comment:
Patchset:
we also have to think of the case when a BTS is added during runtime of the BSC. At this point the bsc-nat doesn't know yet about the related cell identifier.
A new BTS cannot yet have any subscribers registered to it, so one could still use CIL sniffing of the COMPLETE L3 INFO in addition to the BSSMAP RESET based mechanism.
So we'll need the RESTET based mechanism, and either
I would think the CIL sniffing is the more elegant approach. So The RESET based list helps us with the initial state after e.g. a bsc-nat reset, and the CIL sniffing helps us to keep up with changes afterwards.
Last, but not least we *may* have to keep in mind that BSSMAP message have a maximum length (typically imposted by the underlying SCCP/M3UA capability) and a very long list of BTSs in the BSC might overflow the BSSMAP RESET message that we're generating. For a pure SIGTRAN network this should not be a problem. However, for anything that actually still uses traditional SS7 circuits, there is a 272 byte limit on the MTP level. I guess we can ignore that for now but make sure to document this in the (bsc?) user manual, i.e. that with a large numer of BTSs this BSSMAP RESET message size could exceed the 272 byte limit of circuit-switched SS7/MTP, and that it is intended to be used over pure M3UA/SIGTRAN where such constraints don't exist (see RFC 4666 Section 1.3.2.1).
To view, visit change 27767. To unsubscribe, or for help writing mail filters, visit settings.