Implement a proper subscriber connection mapping. Create a new
subscr_conn when one of the stored BSCs sends a conn.ind and use that
subscr_conn for all related connection-oriented messages with the same
RAN-side conn_id to send messages back and forth between BSC and MSC.
Add subscr_conn_get_next_id based on OsmoBSC's
bsc_sccp_inst_next_conn_id.
With this patch, it's possible to do a successful Location Updating
procedure between MS2 and MSC in the following network:
MS1 --- BTS1 --- BSC1 --.
BSCNAT --- MSC
MS2 --- BTS2 --- BSC2 --'
Related: SYS#5560
Change-Id: I1556aa665fbb0a97507f98794e74820731fa6935
Once a BSC has sent a RESET to BSCNAT, store it. This will be used in
future patches to build connection mappings between MSC and BSCs, and to
block messages from BSCs that did not send a RESET.
I've considered using a FSM, but at least right now there doesn't seem
to be multiple states worth storing. We only have the BSC before it has
done the RESET (and then it's simply not in our list) and after it did
the RESET (in the list).
Don't use the stored BSCs in the forwarding logic just yet, a future
commit will replace the current forwarding code with proper connection
mappings.
Related: SYS#5560
Change-Id: Icd7316c49ef26fb45ad45a2ccc1a7916bfb0a387
Oliver Smith