Running Multiple MME
The purpose of this tutorial is to show you how to run multiple MME and let multiple cells get connected to different MME. You can run multiple instances of mme in a callbox without any extra license requirement. The main use case for this is to test roaming scenario.
In live network, multiple RAN belongs to different carriers and multiple separate core network are involved in roaming scenario. In Amarisoft callbox, running multiple instances of RAN(eNB, gNB) requires additional license and further tricky setup. As an alternative, it is recommend to use single instance of eNB/gNB with multiple cells that has different PLMN and then run the multiple instances of Core Network (MME) as roaming test environment.
Table of Contents
Introduction
In modern mobile telecommunications, the Evolved Packet Core (EPC) forms the fundamental backbone for LTE networks, coordinating all essential processes such as user authentication, mobility management, and inter-network connectivity. At the heart of the EPC, the Mobility Management Entity (MME) is responsible for managing signaling between the user equipment (UE) and the core network, orchestrating tasks like bearer activation/deactivation, security procedures, and handover decisions. In real-world deployments, especially in roaming scenarios, multiple MMEs are used to represent different core networks belonging to various operators, enabling seamless service continuity and network interoperability as users move across geographical and administrative boundaries. This tutorial focuses on demonstrating how to configure and operate multiple MME instances within a single test environment, specifically using an Amarisoft callbox. By leveraging this approach, engineers can simulate complex roaming scenarios—where different cells (each with unique Public Land Mobile Networks, or PLMNs) connect to distinct MMEs—without the need for additional hardware licenses or intricate RAN setups. This configuration mirrors live network architectures where multiple RANs and core networks coexist, thus providing a powerful and cost-effective platform for development, validation, and troubleshooting of roaming functionalities. Understanding this architecture is vital for network engineers, testers, and solution architects aiming to ensure robust roaming support, optimize inter-operator interactions, and maintain high service reliability within heterogeneous mobile ecosystems.
-
Context of the Technology
- The tutorial centers on LTE/EPC architecture, with an emphasis on the role of the Mobility Management Entity (MME) within the core network.
- In a typical roaming scenario, multiple MMEs are deployed to represent core networks from different operators, supporting inter-PLMN connectivity and user mobility.
- Amarisoft callbox is used as a testbed, offering a flexible environment to emulate live network conditions without extensive hardware requirements.
-
Relevance and Importance
- Roaming functionality is critical for mobile users requiring uninterrupted service across different operator networks.
- Testing roaming in a controlled lab setup allows for early detection of interoperability issues, security vulnerabilities, and handover failures.
- Using multiple MMEs in a single callbox streamlines the simulation of complex scenarios, reduces licensing costs, and accelerates the development/testing lifecycle.
-
Learning Outcomes
- Acquire practical skills to deploy and manage multiple MME instances within a single test environment.
- Gain insights into configuring multiple cells with distinct PLMNs and associating them with separate MMEs.
- Understand the architectural principles behind roaming, core network segmentation, and inter-PLMN signaling flows.
- Learn troubleshooting techniques for common challenges encountered in multi-MME and roaming scenarios.
-
Prerequisite Knowledge and Skills
- Familiarity with LTE/EPC architecture, including components such as eNB/gNB, MME, and PLMN concepts.
- Basic understanding of Amarisoft callbox operation, including instance management and network configuration.
- Experience with Linux-based environments and network virtualization is beneficial for efficient setup and troubleshooting.
Summary of the Tutorial
This tutorial demonstrates the procedure to set up and verify a multi-MME and multi-IMS configuration on a single callbox PC, focusing on configuration steps and test methodology. The test involves launching two instances each of MME and IMS, associating each to different eNB cells and PLMNs, and verifying their operation using the lte service and network/OS tools. The following summarizes the test procedure:
-
Test Setup:
- Two instances of MME and IMS are configured and launched automatically by the lte service on a single callbox PC.
- All components are managed within a 'screen' session for easier monitoring.
- A single or duplicated ue_db configuration may be used, but care should be taken to avoid mismatches.
-
Configuration Procedures:
-
eNB Configuration:
- The eNB configuration file (enb-2cell-2plmn.cfg) is set up with two cells, each mapped to distinct rf_port and PLMN values.
- Each cell is explicitly assigned to a different PLMN (e.g., 00101 and 00102).
- Multiple mme_addr entries are added to associate with both MME instances.
- plmn_list[] in the cell_default section is commented out to allow per-cell PLMN configuration.
-
MME Configuration:
- Two separate MME configuration files (mme-ims-0.cfg and mme-ims-1.cfg) are created, each with distinct GTP addresses and PLMN assignments.
- mme-ims-0.cfg is aligned with the first cell and uses default MME settings for PDN/APN and IMS associations.
- mme-ims-1.cfg is configured for a different PLMN and uses distinct network addresses and IMS associations from MME 0.
- Each MME has its own set of PDN/APN entries and IP address pools configured accordingly.
-
IMS Configuration:
- Two IMS configuration files (ims.default0.cfg and ims.default1.cfg) are created, each aligned to one MME and with different network parameters as required.
- Address and binding parameters (e.g., sip_addr, sctp_addr, etc.) are set per IMS instance to avoid conflicts.
-
OTS Configuration:
- The OTS configuration (ots-multi-mme.cfg) is updated to register both MME and IMS configurations as separate components in the UI.
- MME_CONFIG_FILE, MME1_CONFIG_FILE, IMS_CONFIG_FILE, and IMS1_CONFIG_FILE variables are set to their respective symbolic link paths.
-
eNB Configuration:
-
Test Execution and Verification:
- The lte service is started; all eNB and MME components launch automatically and are available in the screen session.
- The presence of mme1 as a new component in both the screen session and WebGUI is verified.
- Network interfaces (TUN devices) created by each MME configuration are checked using OS tools to confirm correct instantiation.
- IPv4 and IPv6 routing tables are examined to verify routes established by the lte service and OS.
- eNB connection to both MMEs is confirmed by inspecting the S1 setup status using the screen interface.
- Each MME’s connection to the eNB and each IMS’s connection to its associated MME are verified via their respective UIs.
-
Log Analysis:
- Sample logs capture the startup sequence, including SCTP socket establishment, S1 setup requests and responses between eNB and each MME, and SIB1 broadcast from each cell using the configured PLMN.
- The addition of the new MME1 component is confirmed visually in the WebGUI log screenshots.
The tutorial does not perform UE attach procedures but focuses on the infrastructure setup and verification of multi-MME/multi-IMS operation, ensuring each network element is correctly configured and operational.
Test Setup
In this setup, two instances of MME/IMS are running in the callbox. All the components will launch automatically by lte service and all the components will be automatically added to 'screen' window as well. (
In this example, a single eNB instance provides two LTE cells. Cell 1 uses sdr0 and PLMN 1 and connects to MME 0 running with mme-ims-0, while Cell 2 uses sdr1 and PLMN 2 and connects to MME 1 running with mme-ims-1. Each MME is also associated with a separate IMS instance, using ims.default0 for IMS 0 and ims.default1 for IMS 1.
This arrangement creates two independent LTE core-network paths within one Callbox PC and allows the two cells to represent different roaming networks without running multiple eNB instances.
Configuration
The configuration for this use case is pretty complicated comparing to regular use case because you need to add additional components (MME1 and IMS1 in this case) and associate separate configuration files for them. In addition, you need to modify OTS configuration as well to incoporate the newly added components.
Configuration File Setup
I used enb-2cell-2plmn.cfg which is copied and modified from enb-2cell-ho.cfg (These configuration files are located in /root/enb/config).
I used two separate mme configuration files : mme-ims-0.cfg and mme-ims-1.cfg which are copied and modified from mme-ims.cfg. Note that mme0.cfg and mme1.cfg are symbolically linked to mme-ims-0.cfg and mme-ims-1.cfg respectively. (These configuration files are located in /root/mme/config).
I used two separate ims configuration files : mme.default.0.cfg and mme.default1.cfg which are copied and modified from ims.default.cfg. Note that ims0.cfg and ims1.cfg are symbolically linked to ims.default0.cfg and ims.default1.cfg respectively. (These configuration files are located in /root/mme/config).
I used ots-multi-mme.cfg which is copied and modiefied from ots.default.cfg (These configuration files are located in /root/ots/config).
Configuration for eNB
In enb-2cell-2plmn.cfg , I made modifications as follows.
Configure one mme_addr entry for each MME. The existing mme_addr value 127.0.1.100 points to MME 0, and the additional mme_addr value 127.0.1.101 points to MME 1. Because both MME instances run on the same Callbox PC, different loopback addresses in the 127.x.y.z range can be assigned to distinguish the two MME endpoints. The eNB establishes a separate S1AP connection to each configured mme_addr.
Because both MME instances and the eNB run on the same Callbox PC, the gtp_addr parameter does not need to be changed. The value 127.0.1.1 is used as the local GTP-U bind address of the eNB for user-plane communication with both MMEs. The separate MME instances are distinguished by their mme_addr values in the mme_list block, while the eNB can continue using the same local gtp_addr for both connections.
Now we are going to two cells with different PLMNs and get each of them mapped to different rf port.
For the first cell, the rf_port parameter is set to 0, so the cell uses RF port 0. The plmn_list parameter contains 00101, which identifies the PLMN broadcast by this cell. The cell_id parameter is set to 0x01 and forms the lower 8 bits of the SIB1 cellIdentity, while tac defines the Tracking Area Code advertised in SIB1.
For the second cell, the rf_port parameter is set to 1, so this cell is transmitted through RF port 1. The plmn_list parameter is configured with PLMN 00102, allowing the cell to represent a different operator network from the first cell.
The cell_id parameter is set to 0x02, providing a different lower 8-bit cell identity, while n_id_cell is set to 2 to assign a distinct physical cell identity. The root_sequence_index parameter is also configured with a different value so that the PRACH preamble sequence is separated from that of the first cell.
Comment out the plmn_list parameter in the cell_default block so that no common PLMN configuration is inherited by all cells. In this setup, each cell must broadcast a different PLMN, so plmn_list is configured separately inside each cell entry in the cell_list block.
If plmn_list remains active in cell_default, the same default PLMN configuration is applied to every cell, which would prevent the cells from representing separate operator networks as required for this multiple-MME roaming test.
Configuration for MME 0
Followings are the configuration in mme-ims-0.cfg.
This configuration is used for MME 0, which serves the first eNB cell configured with PLMN 00101. This MME instance is based on the default MME configuration, so the main network parameters remain unchanged.
The gtp_addr parameter is set to 127.0.1.100 and is used as the local GTP-U and S1AP bind address for MME 0. The plmn parameter remains 00101 so that it matches the PLMN configured for the first cell. The mme_group_id and mme_code parameters also keep their default values.
The ims_list block is unchanged and points to the IMS instance through ims_addr 127.0.0.1 and bind_addr 127.0.0.2. This associates MME 0 with the default IMS 0 configuration.
Keep the default PDN configuration in the pdn_list block. The pdn_type parameter is set to ipv4, and access_point_name is configured as default. UE IPv4 addresses are allocated from first_ip_addr 192.168.2.2 through last_ip_addr 192.168.2.254. The dns_addr parameter remains 8.8.8.8, while ip_addr_shift controls the spacing between allocated IP addresses.
Keep the internet PDN/APN configuration unchanged in the pdn_list block. For IPv4 service, pdn_type is set to ipv4 and access_point_name is set to internet. UE IPv4 addresses are allocated from first_ip_addr 192.168.3.2 through last_ip_addr 192.168.3.254, with dns_addr set to 8.8.8.8.
The commented IPv6 example uses pdn_type ipv4v6 to support dual-stack connectivity. The IPv6 allocation range is defined by first_ipv6_prefix 2001:468:2000:1:: and last_ipv6_prefix 2001:468:2000:ffff::. The dns_addr list includes both the IPv4 DNS address 8.8.8.8 and the IPv6 DNS address 2001:4860:4860::8888.
Keep the ims PDN/APN configuration unchanged in the pdn_list block. The access_point_name parameter is set to ims, and pdn_type is set to ipv4v6 to provide dual-stack connectivity for IMS services.
For IPv4, UE addresses are allocated from first_ip_addr 192.168.4.2 through last_ip_addr 192.168.4.254. For IPv6, the allocation range is defined by first_ipv6_prefix 2001:468:3000:1:: and last_ipv6_prefix 2001:468:3000:ffff::. The p_cscf_addr parameter provides both IPv4 and IPv6 P-CSCF addresses to the UE, while dns_addr supplies the corresponding IPv4 and IPv6 DNS server addresses.
Keep the sos PDN/APN configuration in the pdn_list block. The access_point_name parameter is set to sos, emergency is enabled with emergency: true, and pdn_type is set to ipv4v6 to support emergency services over both IPv4 and IPv6.
The IPv4 address range remains 192.168.5.2 through 192.168.5.254. The IPv6 prefix range is configured from 2001:468:4000:1:: through 2001:468:4000:ffff::. This IPv6 range is kept separate from the ranges used by the other MME configuration to avoid address overlap. The p_cscf_addr parameter provides the IPv4 and IPv6 P-CSCF addresses used for emergency IMS signaling.
Configuration for MME 1
Followings are the configuration in mme-ims-1.cfg. NOTE that this MME has configured for the PLMN 310260 and use the gtp_addr which is different from MME 0. Also mis_addr and bind_addr in ims_list are set differently from MME 0.
Since MME 0 and MME 1 run simultaneously on the same Callbox PC, parameters that identify local services and bind addresses must be different from those used in mme-ims-0.cfg.
The log_filename parameter is set to /tmp/mme1.log so that MME 1 writes to a separate log file. The com_addr parameter uses port 9100, preventing the remote API and Web interface from conflicting with the port used by MME 0.
The gtp_addr parameter is set to 127.0.1.101. This provides a separate local GTP-U and S1AP bind address for MME 1 and matches the second mme_addr entry configured in the eNB mme_list block.
The plmn parameter is set to 310260, so only a cell advertising PLMN 310260 can be associated with this MME. The mme_group_id and mme_code parameters remain unchanged because the separate gtp_addr and PLMN already distinguish this MME instance.
In the ims_list block, ims_addr is set to 127.0.0.3 and bind_addr is set to 127.0.0.4. These addresses are different from the IMS addresses used by MME 0, allowing MME 1 to communicate with its own IMS instance without address conflicts.
Note that the PLMN configured earlier for the second cell was 00102. To connect that cell to this MME, the cell plmn_list and the MME plmn parameter must use the same PLMN value.
Configure the default PDN/APN in the pdn_list block with pdn_type set to ipv4 and access_point_name set to default. For MME 1, the IPv4 address pool is changed to first_ip_addr 192.168.12.2 through last_ip_addr 192.168.12.254.
This subnet must be different from the 192.168.2.0/24 range used by MME 0. Using a separate UE address pool prevents IP address overlap and allows traffic from the two MME instances to be routed and identified independently. The ip_addr_shift and dns_addr parameters remain unchanged from the default configuration.
Configure the internet PDN/APN in the pdn_list block with address ranges different from those used by MME 0. For IPv4 service, pdn_type is set to ipv4 and access_point_name is set to internet. The UE address pool is defined by first_ip_addr 192.168.13.2 and last_ip_addr 192.168.13.254.
The optional IPv6 configuration uses pdn_type ipv4v6, with first_ipv6_prefix set to 2001:468:1200:1:: and last_ipv6_prefix set to 2001:468:1200:ffff::. Both the IPv4 subnet and IPv6 prefix range are changed to prevent address overlap with the internet PDN configured for MME 0. The ip_addr_shift and dns_addr parameters remain unchanged.
Set "ims" PDN/APN differently from MM0 configuration. ptn_type is "ipv4v6", the range of ip address is 192.168.14.2~192.168.14.254 and 2001:468:1300:1::~2001:468:1300:ffff:: respectively.
Configure the ims PDN/APN in the pdn_list block with address ranges different from those used by MME 0. The access_point_name parameter is set to ims, and pdn_type is set to ipv4v6 to support both IPv4 and IPv6 IMS connectivity.
The IPv4 address pool is defined by first_ip_addr 192.168.14.2 and last_ip_addr 192.168.14.254. The IPv6 prefix range is defined by first_ipv6_prefix 2001:468:1300:1:: and last_ipv6_prefix 2001:468:1300:ffff::. These ranges are changed to prevent overlap with the IMS PDN address pools configured for MME 0.
The p_cscf_addr parameter is also updated to 192.168.14.1 and 2001:468:1300:1:: so that UEs connected through MME 1 receive the P-CSCF addresses associated with this IMS network. The dns_addr parameter remains unchanged.
Set "sos" PDN/APN differently from MM0 configuration. ptn_type is "ipv4v6", the range of ip address is 192.168.15.2~192.168.15.254 and 2001:468:1400:1::~2001:468:1400:ffff:: respectively.
Configure the sos PDN/APN in the pdn_list block with address ranges different from those used by MME 0. The access_point_name parameter is set to sos, emergency is enabled with emergency: true, and pdn_type is set to ipv4v6 to support emergency services over both IPv4 and IPv6.
The IPv4 address pool is defined by first_ip_addr 192.168.15.2 and last_ip_addr 192.168.15.254. The IPv6 prefix range is defined by first_ipv6_prefix 2001:468:1400:1:: and last_ipv6_prefix 2001:468:1400:ffff::. These ranges are kept separate from the SOS PDN address pools configured for MME 0 to avoid IP address overlap.
The p_cscf_addr parameter is updated to 192.168.15.1 and 2001:468:1400:1:: so that emergency IMS traffic is directed to the P-CSCF associated with MME 1 and IMS 1. The dns_addr parameter remains unchanged.
Configuration for IMS 0
Followings are the configuration in ims.default0.cfg.
This configuration is used for IMS 0 and remains mostly unchanged from the default IMS configuration. This IMS instance is associated with MME 0 and serves the IMS and emergency PDNs configured for the first core-network instance.
In the sip_addr block, the IMS SIP addresses remain 192.168.4.1 and 2001:468:3000:1:: for the ims APN, and 192.168.5.1 and 2001:468:4000:1:: for the sos APN. These addresses match the p_cscf_addr values configured in mme-ims-0.cfg. The bind_addr values are kept the same as the corresponding SIP addresses.
The sctp_addr parameter remains 127.0.0.1 for the SG interface toward MME 0. The cx_server_addr and rx_server_addr parameters remain 127.0.1.100, matching the gtp_addr used by MME 0. The cx_bind_addr parameter remains 127.0.0.1.
The mms_server_bind_addr and com_addr parameters also retain their default values. Since this is the first IMS instance, no address or port changes are required.
Configuration for IMS 1
Followings are the configuration in ims.default1.cfg. You should configure the parameters differently from the IMS 0 configuration.
Thisconfiguration is used for IMS 1. Because IMS 0 and IMS 1 run simultaneously on the same Callbox PC, the local addresses, service ports, and interface endpoints must be different from those configured in ims.default0.cfg.
The log_filename parameter is set to /tmp/ims1.log so that IMS 1 writes to a separate log file. In the sip_addr block, the IMS APN uses 192.168.14.1 and 2001:468:1300:1::, while the SOS APN uses 192.168.15.1 and 2001:468:1400:1::. These values match the p_cscf_addr parameters configured for the IMS and SOS PDNs in mme-ims-1.cfg.
The mms_server_bind_addr parameter is changed to 192.168.13.1:1111 to use the Internet PDN subnet assigned to MME 1. The sctp_addr parameter is set to 127.0.0.3 for the SG connection with MME 1.
For the Cx interface, cx_server_addr is set to 127.0.1.101, matching the address of MME 1, while cx_bind_addr is set to 127.0.0.3. The rx_server_addr parameter is also set to 127.0.1.101 so that Rx signaling is directed to the MME 1 core-network instance.
The com_addr parameter uses port 9103, preventing the IMS 1 remote API and Web interface from conflicting with the port used by IMS 0.
Configuration for OTS
Followings are the configuration in ots-multi-mme.cfg The purpose of this step is to integrate the new components into the screen UI(User Interface).
This config is updated so that both MME instances are launched automatically by the LTE service and displayed as separate components in the screen interface.
For the first MME, MME_CONFIG_FILE is set to config/mme0.cfg. A new component named MME1 is then added to COMPONENTS for the second MME instance. The MME1_TYPE parameter identifies the component as an MME, MME1_WIN assigns screen window 6, and MME1_PATH specifies the MME executable location. The MME1_CONFIG_FILE parameter points to config/mme1.cfg, allowing the second MME to start with its own configuration independently of MME 0.
Set IMS_CONFIG_FILE to config/ims0.cfg for the first IMS instance. Then add a new component named IMS1 to COMPONENTS and set IMS1_CONFIG_FILE to config/ims1.cfg so that the second IMS instance starts with its own configuration.
The IMS1_TYPE parameter identifies the component as IMS, IMS1_WIN assigns it to screen window 7, and IMS1_PATH specifies the executable directory. IMS1_DEP defines the component that must be available before IMS1 starts. With these settings, IMS 0 and IMS 1 are launched and displayed independently in the same screen session.
Perform the test
In this test, I would just run a lte service with additional MME. I would not try any UE attach. In this test, all the eNB and mme is run automtically by lte service.
Restart the LTE service with service lte restart so that the eNB, MME, IMS, and newly added MME1 and IMS1 components are launched automatically according to ots-multi-mme.cfg. No UE attachment is required for this test because the objective is only to verify that the additional core-network instances start correctly.
Run screen -r to open the LTE service screen session. A new screen window named MME1 should appear at the position defined by MME1_WIN, which is set to 6. The displayed component name must match the MME1 name added to the COMPONENTS parameter. The presence of the MME1 window confirms that the second MME was successfully integrated into the LTE service startup and screen interface.
The new IMS1 component is displayed in screen window 7, matching the IMS1_WIN parameter in ots-multi-mme.cfg. The window name IMS1 also matches the component name added to COMPONENTS, confirming that the second IMS instance was successfully launched with config/ims1.cfg and integrated into the LTE service screen session.
While the LTE service is running, MME 0 creates one TUN interface for each configured PDN/APN. These interfaces act as local gateways for UE user-plane traffic.
tun0 uses 192.168.2.1 for the default APN, tun1 uses 192.168.3.1 for the internet APN, tun2 uses 192.168.4.1 and 2001:468:3000:1:: for the ims APN, and tun3 uses 192.168.5.1 and 2001:468:4000:1:: for the sos APN. The interface addresses correspond to the PDN address ranges configured in mme-ims-0.cfg.
While the LTE service is running, MME 1 creates a separate set of TUN interfaces for its configured PDN/APNs.
tun4 uses 192.168.12.1 for the default APN, tun5 uses 192.168.13.1 for the internet APN, tun6 uses 192.168.14.1 and 2001:468:1300:1:: for the ims APN, and tun7 uses 192.168.15.1 and 2001:468:1400:1:: for the sos APN. These addresses correspond to the PDN address pools configured in mme-ims-1.cfg and are kept separate from the tun0 through tun3 interfaces created by MME 0.
The IPv4 routing table shows the routes automatically created for the PDN address pools of both MME instances. The route -n command displays each destination subnet and the TUN interface used to reach it.
The 192.168.2.0/24 through 192.168.5.0/24 routes point to tun0 through tun3 and correspond to the default, internet, ims, and sos PDNs configured for MME 0. The 192.168.12.0/24 through 192.168.15.0/24 routes point to tun4 through tun7 and correspond to the four PDNs configured for MME 1.
Because each MME uses separate IPv4 subnets, the operating system can route UE traffic to the correct TUN interface without address conflicts between the two core-network instances.
The IPv6 routing table shows the routes automatically created for the IPv6 prefixes configured in both MME instances.
For MME 0, the IMS prefix 2001:468:3000::/48 is routed through tun2, while the SOS prefix 2001:468:4000::/48 is routed through tun3. For MME 1, the IMS prefix 2001:468:1300::/48 is routed through tun6, while the SOS prefix 2001:468:1400::/48 is routed through tun7.
The table also contains host routes for the local IPv6 addresses assigned to each TUN interface, including 2001:468:3000:1::, 2001:468:4000:1::, 2001:468:1300:1::, and 2001:468:1400:1::. The separate IPv6 prefix ranges ensure that traffic is routed to the correct MME and TUN interface without overlap between the two core-network instances.
Return to the LTE service screen and select the eNB window. Run the s1 command to verify the S1AP connections established toward both MME instances.
The output should show server 127.0.1.100 with PLMN 00101 and server 127.0.1.101 with PLMN 00102. The state setup_done confirms that the eNB has successfully completed the S1 Setup procedure with each MME.
It may take some time for both connections to reach setup_done. Run the s1 command several times until both MME connections are displayed in the setup_done state.
Go to the MME 0 screen window and run the enb command to verify the connected eNB. The output shows PLMN 00101, eNB ID 0x1a2e0, and the eNB S1 address 127.0.1.1 with its SCTP port.
The presence of this entry confirms that the eNB cell configured with PLMN 00101 has successfully established an S1 connection with MME 0. The #UECtx value is 0 because no UE has been attached in this test.
Go to the MME1 screen window and run the enb command to verify the eNB connected to the second MME instance. The output shows the eNB ID, S1 address, SCTP port, supported TAC, and the current number of UE contexts.
The presence of the eNB entry confirms that MME1 has successfully established the S1 connection. The #UECtx value remains 0 because no UE is attached during this test.
In this screenshot, the displayed PLMN is 00101. For the intended two-PLMN setup, verify that the second cell plmn_list and the MME1 plmn parameter use the same second PLMN value, such as 00102.
Go to the IMS 0 screen window and run the mme command to verify the connected MME. The output shows the MME connection at 127.0.0.2:10042, which corresponds to the bind_addr configured for IMS 0 in the MME ims_list block.
The presence of this entry confirms that MME 0 has successfully established its connection with IMS 0. The Users value is 0 because no UE is attached or registered during this test.
Go to the IMS1 screen window and run the mme command to verify the MME connected to the second IMS instance. The output shows the MME connection at 127.0.0.4:10042, which corresponds to the bind_addr configured for IMS 1 in the MME1 ims_list block.
The presence of this entry confirms that MME 1 has successfully established its connection with IMS 1. The Users value is 0 because no UE is attached or registered during this test.
Log Analysis
The screenshots below shows only the initial connection of each network components and SIB1 message from each cell. I have tried this with real UE and captured the full log from attach to IMS registration for both cells. Check out the Sample Logs.
Open the Amarisoft WebGUI and verify that the additional MME1 and IMS1 components appear automatically in the component list. These entries are created from the COMPONENTS configuration in ots-multi-mme.cfg.
The green status indicators confirm that both components are running and connected to the WebGUI. MME1 and IMS1 can now be selected independently to monitor their logs, protocol messages, and connection status alongside the original MME and IMS components.
Followings are some of highlighted steps you may want to check.
The WebGUI log shows that the eNB successfully establishes an SCTP connection to MME 0 at 127.0.1.100:36412. After the SCTP association is created, the eNB sends an S1 Setup Request and receives an S1 Setup Response, confirming that the S1AP connection with MME 0 is successfully established.
The WebGUI log shows that the eNB successfully establishes a separate SCTP connection to MME 1 at 127.0.1.101:36412. After the SCTP association is created, the eNB sends an S1 Setup Request to MME 1 and receives an S1 Setup Response. This confirms that the second S1AP connection is successfully established independently from the connection to MME 0.
The eNB sends an S1 Setup Request to MME 0 through the SCTP connection at 127.0.1.100:36412. The message includes the Global eNB ID with PLMN 00101 and eNB ID 0x1A2E0, the eNB name enb1a2e0, the supported tracking area with TAC 0x0001, and the broadcast PLMN list. This request allows MME 0 to identify the eNB and verify that it supports the PLMN and tracking area managed by this MME.
MME 0 sends an S1 Setup Response to the eNB through 127.0.1.100:36412. The response includes the Served GUMMEI information and Relative MME Capacity. Receipt of this successful response confirms that the S1AP connection between the eNB and MME 0 has been established.
The eNB sends an S1 Setup Request to MME 1 through the SCTP connection at 127.0.1.101:36412. The request includes the Global eNB ID, eNB name, supported tracking area, broadcast PLMN information, and Default Paging DRX.
This message allows MME 1 to identify the eNB and verify that the configured tracking area and PLMN are supported before accepting the S1AP connection.
MME 1 sends an S1 Setup Response to the eNB through 127.0.1.101:36412. The response includes the Served GUMMEI information and Relative MME Capacity advertised by MME 1. Receipt of this successful response confirms that the S1AP connection between the eNB and MME 1 has been established.
Cell 1 periodically broadcasts SIB1 on the BCCH with PLMN 001-01, matching the plmn_list configuration for the first cell. In the plmn-Identity field, the MCC digits are 0, 0, 1 and the MNC digits are 0, 1. The same SIB1 also advertises TAC 0x0001 and the configured cell identity, allowing UEs to identify and select Cell 1 as part of PLMN 001-01.
Cell 2 periodically broadcasts SIB1 on the BCCH with PLMN 001-02, matching the plmn_list configuration for the second cell. In the plmn-Identity field, the MCC digits are 0, 0, 1 and the MNC digits are 0, 2. This confirms that Cell 2 advertises a different PLMN from Cell 1 while using the configured tracking area and cell identity.
