Cellular Network Infrastructure » Radio Access Network » OsmoBTS

In most of our software modules we offer flexibility to rename sockets and to bind services on different ip addresses, while some of the modules still have hardcoded socket names or similar limitations. In this task we want to setup two independed core networks on a single machine for test to rule out remaining limitations.

Things that should not be a problem:
GGSN: would simply bind on a different lo address (GGSN #1 on 127.0.0.1, GGSN #2 127.0.0.3)
SGSN: Connection from SGSN #1 to GGSN #1: gtp local-ip 127.0.0.2; ggsn 0 remote-ip 127.0.0.1
SGSN: Connection from SGSN #2 to GGSN #2: gtp local-ip 127.0.0.4; ggsn 0 remote-ip 127.0.0.3
SGSN: Connection from PCU #1 to SGSN #1: encapsulation udp local-port 23000
SGSN: Connection from PCU #2 to SGSN #2: encapsulation udp local-port 23001
PCU: Connection from PCU #1 to SGSN #1: gprs nsvc 0 local udp port 23100; gprs nsvc 0 remote udp port 23000
PCU: Connection from PCU #2 to SGSN #2: gprs nsvc 0 local udp port 23101; gprs nsvc 0 remote udp port 23001
BSC: MNCC socket paths of the BSC can be renamed via command line option but this should be migrated to a VTY option if possible.
BTS: Socket path can be changed via VTY
VTY/Control interfaces of all components can be bind to a different address

Things that are a problem:
BTS: Connection from BTS #1 to BSC #1: oml remote-ip 127.0.0.1
BTS: Connection from BTS #1 to BSC #2: oml remote-ip 127.0.0.1 > Clash!
Check if there is an option to change the abis over ip port for both, BTS and BSC

PCU: Connection to BTS: hardcoded socket path > Clash!
Make a VTY option to change the socket path!

(When done we probably should look out for more of such limitations. For new features we should always ensure that there are VTY commands to change socket names, ports and ip addresses, devices etc...)