Multiple bts and gsm core network instances on the same machine
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...)
#2 Updated by dexter almost 4 years ago
- % Done changed from 0 to 20
Managed to configure osmo-nitb and osmo-bts to work in parallel on one and the same host. Unfortunately OCTPHY seems to have problems to distinguish between the packets comming from the two bts instances, this is normal because currently both bts instances use the same ethernet interfaces. We need two independend virtual interfaces with different mac in order to make this work.
#3 Updated by dexter almost 4 years ago
- Status changed from In Progress to Stalled
- % Done changed from 20 to 30
Successfully tested two completely separate instances of osmo-nitb+osmo-bts next to each other. Now the packet switching part is still missing, since this part is currently not demanded, I set the ticket to stalled.