Amarisoft

LTE MOCN

The purpose of this tutorial is to show you how to configure and test LTE MOCN.  MOCN stands for Multiple Operator Core Network and it is a type of network sharing technology. There are some of key features to be noted in this technology

With this tutorial, you would also learn how to connect one eNB to different MMEs.  Since the configuration is pretty complicated, it would be good to have some big picture of the test concept and the configuration. It is illustrated below. When you follow through the configuration section, try to associate each configuration files/parameters to this diagram, otherwise you may easily get lost.

LTE MOCN Concept 01

Table of Contents

Introduction

Multiple Operator Core Network (MOCN) is a sophisticated network sharing solution standardized in 3GPP to enable multiple mobile network operators (MNOs) to share a single Radio Access Network (RAN) infrastructure while maintaining independent core network operations. In the context of Long Term Evolution (LTE) networks, MOCN facilitates significant reductions in capital and operational expenditures by allowing operators to jointly utilize eNodeBs and spectrum resources, thereby improving resource utilization and accelerating network deployments. Architecturally, a shared RAN broadcasts multiple Public Land Mobile Network (PLMN) identifiers, enabling user equipment (UE) from different operators to access their respective core network entities—such as Mobility Management Entities (MMEs) and Serving Gateways (S-GWs)—over a common radio interface. The eNodeB is configured to recognize and route signaling and data traffic to the appropriate core network based on the selected PLMN, ensuring logical separation of subscriber traffic and operator-specific policies. MOCN plays a critical role in expanding coverage, especially in rural or less dense environments, fostering industry collaboration, and supporting increasingly complex service requirements. This tutorial introduces the practical aspects of configuring and testing LTE MOCN, focusing on the technical steps required to connect a single eNodeB to multiple operator core networks, as well as best practices for managing the associated configuration complexity. By understanding the underlying architecture and configuration principles, network engineers can effectively deploy and maintain shared LTE networks that are robust, scalable, and compliant with multi-operator environments.

Summary of the Tutorial

This tutorial outlines the step-by-step procedures and methodologies for configuring, executing, and analyzing a Multi-Operator Core Network (MOCN) test scenario using a callbox setup with two MMEs, a single eNB, and simulated or commercial UEs. The focus is on validating correct configuration, operation, and signaling for supporting two PLMNs in a single LTE cell, as well as confirming proper UE attachment and network registration behaviors.

The documented methodology ensures a comprehensive approach for validating MOCN configuration and operation, from initial setup through signaling verification and log analysis, focusing on the ability of the system to support UEs from different PLMNs within a shared radio environment.

Test Setup

In this setup, two instances of MME is running in the callbox. MME 0 runs together with LTE service and MME 1 runs manually.

TestSetup Callbox UEsim 1sdr 01

Configuration

There are so many configuration files applied to almost every component of the system. It may be confusing if you don't have clear understandings on overall test concept.  Keep the illustration at the beginning of this page in mind and try to associate these configurations to the illustration.

Configuration File Setup

I used ue-lte-2plmn.cfg which is copied and modified from ue.default.cfg on UE sim.

LTE MOCN UeSIM Config 01

I used enb-1cell-2plmn.cfg which is copied and modified from enb.default.cfg.

LTE MOCN enb Config 01

I used two separate mme configuration files : mme-ims-2plmn-0.cfg and mme-ims-2plmn-1.cfg which are copied and modified from mme-ims.cfg. Note that mme.cfg is symbolically linked to mme-ims-2plmn-0.cfg. ue_db-ims-2plmn.cfg is copied and modified from ue_db-ims.cfg. ue_db-ims-2plmn.cfg is called (included) within mme-ims-2plmn-0.cfg and mme-ims-2plmn-1.cfg

LTE MOCN mme Config 01

I used ots-2mme.cfg which is copied and modified from ots.default.cfg

LTE MOCN ots Config 01

Configuration for eNB

In enb-1cell-2plmn.cfg, I made modifications as follows.

The first important change is in mme_list. In a normal single-operator setup, the eNB usually has only one MME address, but in this MOCN example one more mme_addr is added so that the same eNB can connect to two different MMEs. Here 127.0.1.100 is used for MME 0 and 127.0.1.101 is used for MME 1. Since both MMEs are running on the same Callbox PC in this tutorial, loopback-style IP addresses can be used. If the MMEs are running on different machines, these addresses should be changed to the actual IP addresses of those MME machines.

The gtp_addr remains as 127.0.1.1 in this example. This parameter is the local bind address used for GTP traffic between the eNB and the core network side. Since this tutorial runs the eNB and MMEs locally on the same Callbox PC, there is no need to change gtp_addr. If the MME or gateway side is moved to another host or another network interface, then this address may need to be changed according to the actual interface used for the S1-U/GTP path.

The next important change is in cell_list, more specifically in the broadcasted PLMN identity list. In this example, plmn_list includes two PLMNs, "00101" and "00102". This means the eNB broadcasts both PLMN identities in SIB1. From the UE point of view, this single LTE cell appears as a shared cell that supports both operators. A UE configured for PLMN 00101 can camp on this cell as PLMN 1, and another UE configured for PLMN 00102 can camp on the same cell as PLMN 2.

So the key idea of this eNB configuration is simple. The mme_list tells the eNB that there are two MMEs available, and the plmn_list tells the UE that this cell supports two PLMNs. After the UE selects one of the broadcast PLMNs, the eNB uses that PLMN information to route the UE signaling toward the corresponding MME. This is the essential eNB-side behavior required for the LTE MOCN test.

LTE MOCN enb Config 02

Configuration for MME 0

Followings are the configuration in mme-ims-2plmn-0.cfg

This MME represents the core network side for PLMN 00101, so the plmn value is kept as "00101". In this example, most of the basic MME identity parameters are kept the same as the default configuration, including mme_group_id: 32769 and mme_code: 1. The network name and short name are also kept as "Amarisoft Network" and "Amarisoft". These values are sent to the UE in EMM information, but they are not the main point of this MOCN configuration.

The gtp_addr is set to 127.0.1.100. This address is important because it should match the MME 0 side address that the eNB uses in its mme_list. In the eNB configuration, 127.0.1.100 was added as the MME address for the first MME, so this MME instance should bind to the same local address. Since this tutorial runs the MME on the Callbox PC, a 127.x.x.x local address can be used. If the MME is running on a different PC, this should be replaced with the actual IP address reachable from the eNB.

The most important modification in this MME 0 configuration is the IP address pool assigned to the UE. In the pdn_list for the "default" PDN, first_ip_addr is set to 192.168.2.2 and last_ip_addr is set to 192.168.2.66. This defines the UE IP address range that MME 0 can assign to UEs attached through PLMN 00101. The reason for changing this range is to avoid overlap with the IP address range used by the other MME. In a multi-MME or multi-PLMN test, each core network should have its own UE IP pool, otherwise two UEs attached to different MMEs may be assigned overlapping IP addresses and the user-plane routing can become confusing or incorrect.

One additional note is that the IP pool size should follow the expected Amarisoft requirement where last_ip_addr - first_ip_addr should be 2^n. In this example, 192.168.2.66 - 192.168.2.2 gives a difference of 64, which is 2^6. This makes the address range valid for this configuration. The ip_addr_shift value is set to 2, and dns_addr is set to 8.8.8.8. These are kept as normal PDN-related settings and are not specific to MOCN, but they should still be configured consistently with the rest of the IP plan.

So the key point for MME 0 is that it keeps PLMN 00101 and uses its own local bind address, 127.0.1.100, while assigning UE IP addresses from the 192.168.2.2 to 192.168.2.66 range. This makes MME 0 clearly separated from MME 1 at both the signaling/core identity level and the UE IP allocation level.

LTE MOCN Configuration MME 0 01

For the additional PDN entries in MME 0, the same IP separation rule is applied. The purpose is to make sure that every PDN type has its own UE IP address range and that these ranges do not overlap with the ranges used by the other MME. This is especially important in this MOCN test because two different MMEs are running at the same time, and each MME should manage its own UE address space independently.

For the "internet" PDN, first_ip_addr is set to 192.168.3.2 and last_ip_addr is set to 192.168.3.66. This means that UEs using the internet APN through MME 0 will be assigned an IPv4 address from this range. The address range is chosen so that it does not overlap with the IP range configured in mme-ims-2plmn-1.cfg. As in the previous case, the difference between last_ip_addr and first_ip_addr should be 2^n. Here, 192.168.3.66 - 192.168.3.2 gives a difference of 64, so it satisfies the 2^n rule.

The IPv6 configuration for the internet PDN is also changed using the same logic. The first_ipv6_prefix is set to 2001:468:2000:1:: and the last_ipv6_prefix is set to 2001:468:2000:1025::. This gives the internet PDN its own IPv6 prefix range, separated from the IPv6 ranges used by other PDNs or by the other MME. The dns_addr includes both IPv4 and IPv6 DNS server addresses, so the PDN can support IPv4/IPv6 operation when pdn_type is set to ipv4v6.

For the "ims" PDN, first_ip_addr is set to 192.168.4.2 and last_ip_addr is set to 192.168.4.66. This range is used for IMS APN traffic through MME 0. Again, the range is selected to avoid overlap with the other MME and with the other PDNs in the same MME configuration. The difference between 192.168.4.66 and 192.168.4.2 is also 64, so it follows the same 2^n rule.

The IMS PDN also has a separate IPv6 prefix range. first_ipv6_prefix is set to 2001:468:3000:1:: and last_ipv6_prefix is set to 2001:468:3000:1025::. The p_cscf_addr is configured with both an IPv4 P-CSCF address, 192.168.4.1, and an IPv6 P-CSCF address, 2001:468:3000:1::. This is important for IMS because the UE needs P-CSCF information during IMS registration. The DNS address is also configured with both IPv4 and IPv6 DNS values.

So the main point of this part is that MME 0 uses separate IP pools for each APN: the default PDN uses the 192.168.2.x range, the internet PDN uses the 192.168.3.x range, and the IMS PDN uses the 192.168.4.x range. Each range is selected so that it does not overlap with MME 1, and each range is also aligned with the required 2^n address-size rule. This makes the multi-PLMN and multi-MME setup cleaner because UE IP allocation remains separated per MME and per PDN.

LTE MOCN Configuration MME 0 02

For the "sos" PDN in MME 0, the same address separation rule is applied again. This PDN is configured with access_point_name: "sos" and emergency: true, which means this APN is intended for emergency service related operation. Since this is still part of the MME 0 configuration, its UE IP address range should be different from the ranges used by the default, internet, and ims PDNs, and it should also not overlap with any IP range configured in MME 1.

In this example, first_ip_addr is set to 192.168.5.2 and last_ip_addr is set to 192.168.5.66. This means that UEs using the sos PDN through MME 0 will be assigned an IPv4 address from the 192.168.5.x range. The difference between 192.168.5.66 and 192.168.5.2 is 64, so it follows the same 2^n rule required for the IP pool size. This is the same logic used for the previous PDNs: the actual subnet is changed for each PDN, while the size of the address range is kept consistent.

The IPv6 prefix range is also changed for the sos PDN. first_ipv6_prefix is set to 2001:468:4000:1:: and last_ipv6_prefix is set to 2001:468:4000:1025::. This gives the sos PDN its own IPv6 address space and prevents overlap with the other PDN types. The p_cscf_addr is also configured with both IPv4 and IPv6 addresses, 192.168.5.1 and 2001:468:4000:1::, so the UE can receive P-CSCF information when this PDN is used. The dns_addr is configured with both IPv4 and IPv6 DNS addresses as well.

The NAS ciphering and integrity algorithm preference settings are left mostly as default in this example. nas_cipher_algo_pref is empty, and the comment indicates that EEA0 is always the last option. nas_integ_algo_pref is set to [ 2, 1 ], meaning the MME gives preference to the listed NAS integrity algorithms in that order. These parameters are not the main part of the MOCN configuration, but they are still part of the MME behavior during NAS security setup.

At the end of the configuration, the user database is included by using include "ue_db-ims-2plmn.cfg". This file contains the UE subscription information used by the MME. In this MOCN tutorial, this is important because the UE subscription and PLMN-related settings should match the PLMN served by this MME. So, for MME 0, the main configuration logic is that PLMN 00101 is served by this MME, the MME binds to 127.0.1.100, and each PDN type has its own non-overlapping IPv4 and IPv6 address range.

LTE MOCN Configuration MME 0 03

Configuration for MME 1

Followings are the configuration in mme-ims-2plmn-1.cfg .

This MME represents the second core network in the MOCN test, so its configuration should be separated from MME 0. The important point is that MME 1 uses a different local service address, a different GTP bind address, a different PLMN, and a different UE IP address range. This separation prevents the two MMEs from conflicting with each other while they are running at the same time on the same Callbox PC.

The com_addr is changed to 0.0.0.0:9100. This is different from MME 0, which used 0.0.0.0:9000. Since each MME instance provides its own remote API and web interface, they cannot use the same port number. By assigning port 9100 to MME 1, both MME 0 and MME 1 can be accessed independently.

The gtp_addr is set to 127.0.1.101. This is also different from MME 0, which used 127.0.1.100. This address should match the second MME address configured in the eNB mme_list. In the eNB configuration, 127.0.1.101 was added as the address of MME 1, so when the eNB needs to connect to the core network for the second PLMN, it can connect to this MME instance. Since this tutorial runs everything on the same Callbox PC, the 127.x.x.x local address can be used. If MME 1 is running on a different machine, this should be changed to the actual reachable IP address of that host.

The plmn is changed to "00102". This is the key PLMN-level difference between MME 0 and MME 1. MME 0 serves PLMN 00101, while MME 1 serves PLMN 00102. Therefore, when the eNB broadcasts both PLMN 00101 and PLMN 00102 in SIB1, a UE selecting PLMN 00101 will be routed to MME 0, and a UE selecting PLMN 00102 will be routed to MME 1. This is the main MOCN behavior being tested here: the same radio cell is shared, but the UE is connected to a different core network depending on the selected PLMN.

The network name is also changed to "Amarisoft Network 1" and the network short name is changed to "Amarisoft 1". These names are sent to the UE in EMM information. This change is not strictly required for the basic MOCN routing itself, but it is useful for testing because it makes MME 1 visibly different from MME 0. When checking UE behavior or logs, this can help you confirm that the UE is being served by the expected MME.

For the default PDN, first_ip_addr is set to 192.168.2.100 and last_ip_addr is set to 192.168.2.164. This defines the UE IPv4 address pool used by MME 1 for the default APN. The range is intentionally different from the default PDN range used by MME 0, which was 192.168.2.2 to 192.168.2.66. Even though both are in the 192.168.2.x subnet, the actual allocation ranges do not overlap. This is important because MME 0 and MME 1 are independent core-network instances, and overlapping UE IP assignment could make routing and test result interpretation confusing.

The same 2^n range-size rule is applied here as well. The difference between 192.168.2.164 and 192.168.2.100 is 64, which is 2^6. So this address range follows the same requirement used in the MME 0 configuration. The ip_addr_shift and dns_addr are kept in the same style as the previous configuration, where dns_addr is set to 8.8.8.8.

So the main idea of the MME 1 configuration is to make it parallel to MME 0, but not identical. MME 1 uses PLMN 00102, binds to 127.0.1.101, uses API port 9100, advertises a different network name, and assigns UE IP addresses from a non-overlapping range. With this configuration, the eNB can connect to both MMEs, and the UE selected PLMN determines which MME handles the attach procedure.

LTE MOCN Configuration MME 1 01

For the "internet" and "ims" PDNs in MME 1, the same non-overlapping address allocation rule is applied. The purpose is to make MME 1 use address pools that are parallel to MME 0, but shifted to a different range so that the two MMEs do not assign the same UE IP addresses. This is important because both MMEs are active in the same MOCN test environment, and overlapping UE IP pools can make user-plane routing and log analysis confusing.

For the "internet" PDN, first_ip_addr is set to 192.168.3.100 and last_ip_addr is set to 192.168.3.164. This range is used for UEs that attach to PLMN 00102 and request the internet APN through MME 1. In MME 0, the internet PDN used 192.168.3.2 to 192.168.3.66, so this MME 1 range is in the same 192.168.3.x address space but does not overlap with MME 0. The difference between 192.168.3.164 and 192.168.3.100 is 64, so it also satisfies the 2^n range-size rule.

The IPv6 range for the internet PDN is changed in the same way. In this configuration, first_ipv6_prefix is set to 2001:468:2000:2000:: and last_ipv6_prefix is set to 2001:468:2000:3000::. This separates the MME 1 IPv6 prefix range from the MME 0 internet PDN range. The DNS configuration includes both IPv4 and IPv6 DNS addresses, so the APN can support IPv4/IPv6 operation when pdn_type is set to ipv4v6.

For the "ims" PDN, first_ip_addr is set to 192.168.4.100 and last_ip_addr is set to 192.168.4.164. This is the IMS APN address pool for UEs served by MME 1. In MME 0, the IMS PDN used 192.168.4.2 to 192.168.4.66, so again the MME 1 range is intentionally separated from MME 0 while keeping the same general IP planning structure. The address difference is also 64, which follows the same 2^n requirement.

The IPv6 prefix range for the IMS PDN is also changed. first_ipv6_prefix is set to 2001:468:3000:2000:: and last_ipv6_prefix is set to 2001:468:3000:3000::. This makes the IMS IPv6 range for MME 1 different from the IMS IPv6 range used by MME 0. The p_cscf_addr is configured as 192.168.4.1 and 2001:468:3000:1::. This provides the UE with P-CSCF information for IMS registration. The DNS address is configured with both IPv4 and IPv6 DNS values.

So in this part of the MME 1 configuration, the internet and IMS PDN pools are changed to the .100 to .164 range, while MME 0 used the .2 to .66 range. This keeps the two MME configurations similar enough to understand easily, but separated enough to avoid IP allocation conflict. In the overall MOCN test, this helps confirm that a UE attached through PLMN 00102 is really being served by MME 1 and is receiving an address from the MME 1 address pool.

LTE MOCN Configuration MME 1 02

For the "sos" PDN in MME 1, the same IP range separation rule is applied. This PDN is configured with access_point_name: "sos", emergency: true, and pdn_type: "ipv4v6". Since this is the SOS/emergency PDN for MME 1, it should have its own IPv4 and IPv6 address ranges that do not overlap with the SOS PDN range configured in MME 0.

In this example, first_ip_addr is set to 192.168.5.100 and last_ip_addr is set to 192.168.5.164. This is different from MME 0, where the SOS PDN used 192.168.5.2 to 192.168.5.66. So both MMEs use the same 192.168.5.x address space for the SOS APN, but the actual allocation ranges are separated. This makes it easy to recognize which MME assigned the UE IP address. If the UE receives an address around 192.168.5.2 to 192.168.5.66, it belongs to MME 0. If it receives an address around 192.168.5.100 to 192.168.5.164, it belongs to MME 1.

The address range also follows the same 2^n rule. The difference between 192.168.5.164 and 192.168.5.100 is 64, which is 2^6. This keeps the IP pool format consistent with the other PDN configurations used in this tutorial.

The IPv6 prefix range is also changed for MME 1. first_ipv6_prefix is set to 2001:468:4000:2000:: and last_ipv6_prefix is set to 2001:468:4000:3000::. This is different from the MME 0 SOS IPv6 range, which used 2001:468:4000:1:: to 2001:468:4000:1025::. The purpose is the same as IPv4: each MME should have a separate address allocation range so that there is no conflict between the two core networks.

The p_cscf_addr is configured as 192.168.5.1 and 2001:468:4000:1::. This provides P-CSCF information to the UE when this PDN is used. The dns_addr is also configured with both IPv4 and IPv6 DNS addresses. These settings are not unique to MOCN, but they should be kept consistent with the APN and IP addressing plan.

The NAS ciphering and integrity algorithm preference settings are kept the same style as MME 0. nas_cipher_algo_pref is empty, and nas_integ_algo_pref is set to [ 2, 1 ]. These parameters control NAS security algorithm preference, but they are not the main MOCN-related changes in this section.

At the end, include "ue_db-ims-2plmn.cfg" is used again as the UE database file. This means both MME instances can refer to the same UE database file, but each MME still serves a different PLMN and uses different IP pools. So the key point of this section is that the SOS PDN in MME 1 is configured in parallel with MME 0, but all allocation ranges are shifted to the .100 to .164 side to avoid overlap.

LTE MOCN Configuration MME 1 03

Configuration for ue_db

In ue_db-ims-2plmn.cfg, I have defined two USIM parameters as shown below.

In this file, two USIM entries are defined. The first USIM entry is mostly kept from the default configuration, and the second USIM entry is created by copying the first one and changing the PLMN-related part. This allows the two simulated UEs to behave as subscribers of different PLMNs while still using the same UE database file.

For the first UE, imsi is set to 001010123456789. In this IMSI, the first five digits, 00101, represent the PLMN part. This means this UE is associated with PLMN 00101. Since MME 0 is configured with plmn: "00101", this UE is expected to be authenticated and served by MME 0 when it camps on the shared LTE cell.

The authentication-related parameters are kept as default in this example. sim_algo is set to "xor", which means the USIM authentication algorithm uses the XOR-based test algorithm. The amf, sqn, and K values are also configured for the test USIM. These values should match between the UE subscription database and the UE simulator side, otherwise authentication can fail during the attach procedure.

The IMS-related identities are also configured based on the same PLMN. The impi is set to 001010123456789@ims.mnc001.mcc001.3gppnetwork.org, and the domain is ims.mnc001.mcc001.3gppnetwork.org. Here mcc001 and mnc001 correspond to PLMN 00101. The impu list includes SIP identities for this UE, such as the IMSI-based identity and telephone-style identities. These values are mainly used for IMS registration and service testing.

multi_sim is set to true, which is marked as experimental in the configuration comment. In this tutorial, the important point is not the multi_sim feature itself, but that the UE database contains subscription entries for more than one PLMN. With this first UE entry, the network has a subscriber profile for PLMN 00101, so UE 1 can attach through the MOCN shared cell and be routed to the MME serving PLMN 00101.

LTE MOCN Configuration ue db 01

For the second UE, another USIM entry is added in the same ue_db-ims-2plmn.cfg file. This entry is almost a copy of the first UE entry, but the IMSI is changed to 001020123456789. In this IMSI, the first five digits, 00102, represent the PLMN part. This means the second UE is associated with PLMN 00102, so this UE is expected to be served by MME 1, which is configured with plmn: "00102".

The authentication-related parameters are kept the same as the first UE in this example. sim_algo is still set to "xor", and the same amf, sqn, and K values are used. This makes the configuration simple because the main difference between the two UE subscriptions is the PLMN part of the IMSI. In a real network, each subscriber would normally have its own unique authentication key and subscription profile, but for this tutorial the focus is on PLMN-based MOCN routing, so keeping the other parameters similar makes the test easier to understand.

One thing to be careful about is that the IMS-related identities shown here still look based on mnc001.mcc001, such as impi and domain using ims.mnc001.mcc001.3gppnetwork.org. If the tutorial is focused only on basic attach and PDN connectivity, the most important value is the IMSI PLMN part, 00102. However, if you are also testing IMS registration for the second PLMN, you may need to make the IMS domain and IMS private/public identities consistent with the second PLMN as well. For PLMN 00102, that would usually mean using mnc002.mcc001 instead of mnc001.mcc001.

So the main purpose of this second UE entry is to create a subscriber belonging to PLMN 00102. When this UE camps on the shared LTE cell, it can see both PLMN 00101 and PLMN 00102 in SIB1, but because its IMSI belongs to PLMN 00102, it is expected to select or attach through PLMN 00102. Then the eNB routes the signaling to MME 1, and MME 1 authenticates the UE using this second UE database entry.

LTE MOCN Configuration ue db 02

Configuration for ots

In ots-2mme.cfg , I have added the following part to lauch the second mme in addition to the first mme by lte service. I created a new component named "MME1" and associated it with mme-ims-2plmn-1.cfg.

The purpose of this change is to make the OTS/lte service launch two MME instances instead of only one. In the default style configuration, only one MME component is defined, but for this MOCN test we need one MME for PLMN 00101 and another MME for PLMN 00102. So a new component named MME1 is added in addition to the original MME component.

The original MME component is kept as the first MME instance. It uses MME_TYPE="MME", MME_PATH="/root/mme", and MME_CONFIG_FILE="config/mme.cfg". This part represents the normal MME service definition. In this tutorial, the important new part is the second component definition where COMPONENTS+=" MME1" is added. This tells the OTS service manager that there is one more component to start.

For the second MME instance, MME1_TYPE is set to "MME", meaning this component is also an MME process. MME1_PATH is set to "/root/mme", so it uses the same MME executable location as the first MME. MME1_WIN is set to "6", which defines the window/session used to run this component. MME1_INIT is set to "-6", following the same startup style as the original MME component. The most important parameter is MME1_CONFIG_FILE, which is set to "config/mme-ims-2plmn-1.cfg". This makes the second MME instance start with the MME 1 configuration file instead of the default MME configuration.

So the key idea is that OTS does not automatically know that you want to run two MMEs. You need to explicitly add another component, give it a unique component name such as MME1, and point it to the second MME configuration file. After this change, when the OTS service starts the EPC side, it can launch both MME and MME1. The first MME handles the first PLMN configuration, and the second MME handles the second PLMN configuration. This is what allows the shared eNB to connect to two different core-network instances in the MOCN test.

LTE MOCN Configuration ots 1

Configuration for UEsim

In ue-lte-2plmn.cfg , I have configured the following two UEs.

The purpose of this file is to simulate two UEs so that each UE can camp on a different PLMN broadcast by the same eNB.

The most important setting here is multi_ue: true. This allows the UE simulator to run multiple UEs at the same time. Since this tutorial is testing two UEs, one for PLMN 00101 and one for PLMN 00102, this option should be enabled.

In this example, CHANNEL_SIM is set to 0, so the UE channel simulator is disabled. Because of this, the configuration simply enables multi_ue: true without enabling channel_sim. This keeps the test simple and lets us focus on PLMN selection and MME routing.

The other parameters define the basic radio setup. TDD is set to 0, so the test uses FDD. CELL_BANDWIDTH is set to 5, so the bandwidth is 5 MHz. N_ANTENNA_DL and N_ANTENNA_UL are both set to 1, so this is a SISO test. These values should match the eNB configuration.

So the main point of this section is simple. Enable multi_ue: true so that two UEs can run in the simulator. Then configure each UE with the proper USIM and PLMN information so that one UE camps on PLMN 00101 and the other UE camps on PLMN 00102.

LTE MOCN Configuration UEsim 0

For the first UE, the configuration forces the UE to camp on PLMN 00101. This is done by setting preferred_plmn_list to [ "00101" ] and setting the IMSI to 001010123456789. Since the PLMN part of this IMSI is also 00101, this UE is treated as a subscriber of PLMN 00101.

With this setting, when the UE searches the cell and reads the PLMN list from SIB1, it selects PLMN 00101 from the broadcast PLMN list. Then the eNB routes this UE toward the MME that serves PLMN 00101, which is MME 0 in this tutorial.

So the main point is simple. This UE is configured with PLMN 00101 in both preferred_plmn_list and IMSI, so it is expected to attach to PLMN 00101 through MME 0.

LTE MOCN Configuration UEsim 1

For the second UE, the configuration forces the UE to camp on PLMN 00102. This is done by setting preferred_plmn_list to [ "00102" ] and setting the IMSI to 001020123456789. Since the PLMN part of this IMSI is 00102, this UE is treated as a subscriber of PLMN 00102.

With this setting, when the UE reads the PLMN list from SIB1, it selects PLMN 00102 from the broadcast PLMN list. Then the eNB routes this UE toward the MME that serves PLMN 00102, which is MME 1 in this tutorial.

So the main point is that the first UE is configured for PLMN 00101 and the second UE is configured for PLMN 00102. Even though both UEs camp on the same LTE cell, they are routed to different MMEs depending on the selected PLMN.

LTE MOCN Configuration UEsim 2

Perform the test

After the configuration is ready, start the test and first check whether the eNB cell is configured as expected. You can do this from the eNB console using cell_phy and cell commands.

In the cell_phy output, you can confirm the basic physical cell configuration. The output shows that the cell is LTE, Band 7, 5 MHz bandwidth, DL EARFCN 3350, UL EARFCN 21350, and antenna configuration is 1 DL antenna and 1 UL antenna. This confirms that the radio side is running with the expected basic LTE cell setup.

Then use the cell command to check the higher-level cell configuration. In this output, the important part for this MOCN test is the plmn field. It shows 00101 00102, which means the eNB is broadcasting both PLMN 00101 and PLMN 00102. This confirms that the plmn_list configured in enb-1cell-2plmn.cfg is actually applied to the running cell.

So the main thing to verify at this step is simple. cell_phy confirms that the LTE cell is running with the expected radio configuration, and cell confirms that the same cell is broadcasting two PLMNs. If you see both 00101 and 00102 in the plmn field, the eNB side of the MOCN configuration is working as intended.

LTE MOCN Run 1

In the eNB console, check the S1 connection status by using the s1 command. Since two MMEs are started in this test, it may take some time until both S1 connections become ready. Usually, you may need to wait around 30 seconds after starting the service.

In the output, there are two S1 connections. The first one shows server=127.0.1.100:36412, state=setup_done, and PLMN=00101. This means the eNB has successfully connected to MME 0 for PLMN 00101. The second one shows server=127.0.1.101:36412, state=setup_done, and PLMN=00102. This means the eNB has also successfully connected to MME 1 for PLMN 00102.

So the important thing to check here is that both S1 connections are in setup_done state. If both MMEs are connected and each one shows the correct PLMN, the eNB-to-MME part of the MOCN setup is working properly.

LTE MOCN Run 2

Start the eNB trace log by running the t command in the eNB console.

After you run this command, the eNB starts printing trace logs in real time. Press [return] to stop the trace means the trace mode is now active, and you can stop it later by pressing Enter.

This trace log is useful for checking the actual attach procedure of each UE. In the next steps, you can start the UE simulator and watch whether UE 1 attaches through PLMN 00101 and UE 2 attaches through PLMN 00102.

LTE MOCN Run 3

Power on the first UE from the UEsim console by running power_on 1. This turns on UE 1 only.

In this tutorial, UE 1 was configured with preferred_plmn_list: [ "00101" ] and IMSI 001010123456789, so after power-on it should search the LTE cell, read the PLMN list from SIB1, select PLMN 00101, and start the attach procedure toward that PLMN.

If you are using a commercial UE instead of UEsim, this step simply means powering on the first UE or enabling its cellular connection. The expected result is the same: the UE should camp on PLMN 00101 and attach through MME 0.

LTE MOCN Run 3 1

Confirm that the UE camps on the cell from the eNB trace log.

In the trace, the PRACH line shows that the UE has sent a random access preamble and the eNB has detected it. For example, PRACH: cell=01 means the PRACH was received on cell 01, seq=44 is the detected preamble sequence, ta=4 is the timing advance value, and snr=28.3 dB indicates the PRACH signal quality.

After that, the table shows UE_ID 1 with RNTI 003d. This means the first UE has successfully accessed the cell and the eNB has assigned an RNTI to it. You can also see DL and UL activity such as MCS, bitrate, SNR, PUCCH power, and HARQ-related counters. These values indicate that the UE is not only detected by PRACH, but is also communicating with the eNB.

So the main point of this step is that PRACH detection and UE_ID/RNTI creation confirm that UE 1 has camped on the LTE cell and started communicating with the eNB.

LTE MOCN Run 4

Power on the second UE from the UEsim console by running power_on 2. This turns on UE 2 while UE 1 is already running.

In this tutorial, UE 2 was configured with preferred_plmn_list: [ "00102" ] and IMSI 001020123456789. So after power-on, UE 2 should search the same LTE cell, read the PLMN list from SIB1, select PLMN 00102, and start the attach procedure toward MME 1.

If you are using a commercial UE instead of UEsim, this step means powering on the second UE or enabling its cellular connection. The expected result is that the second UE camps on the same shared LTE cell, but attaches through PLMN 00102 instead of PLMN 00101.

LTE MOCN Run 5

Confirm that the second UE also camps on the cell from the eNB trace log.

In this trace, another PRACH is detected, which means the second UE has started random access to the cell. The line PRACH: cell=01 seq=14 ta=0 snr=29.0 dB shows that the eNB received the PRACH from the UE with good signal quality.

After this, the trace table shows two UE IDs: UE_ID 1 and UE_ID 2. This confirms that both UEs are now active on the same LTE cell. UE 1 is still using RNTI 003d, and UE 2 is using RNTI 003e. Since UE 2 was configured with preferred_plmn_list: [ "00102" ] and IMSI 001020123456789, this UE is expected to attach through PLMN 00102 and be routed to MME 1.

So the main point here is that the eNB trace now shows both UE 1 and UE 2. This confirms that the second UE has successfully camped on the same shared cell while the first UE is still connected.

LTE MOCN Run 6

Check the connected UE list from the eNB console by running the ue command.

In this example, two UEs are listed. RAN_UE_ID 1 is using RNTI 003d, and RAN_UE_ID 2 is using RNTI 003e. This confirms that both UEs have accessed the same LTE cell and are known by the eNB.

One thing to note is that this list may not always show the UE after the attach is completed. If the UE finishes the attach procedure and moves into idle mode, it may disappear from this active UE list even though it successfully camped on the cell. So if you do not see the UE here, it does not always mean the test failed. In that case, continue to the next step and check the attach result or MME-side status.

LTE MOCN Run 7

Check the connected UE from the MME 0 console by running the ue command.

In this output, one UE is listed with SUPI 001010123456789. This is the first UE, and the PLMN part of the IMSI is 00101. The REG field shows Y, which means the UE is registered in this MME. The PLMN field also shows 00101, confirming that this UE attached through PLMN 00101.

You can also confirm that the UE received an IP address. In this example, IP_ADDR is 192.168.2.2. This address is from the default PDN IP range configured in mme-ims-2plmn-0.cfg, so it confirms that the UE was served by MME 0 and received an address from the MME 0 IP pool.

So the main check here is that UE 001010123456789 is registered in MME 0 with PLMN 00101 and assigned IP address 192.168.2.2.

LTE MOCN Run 8

Check the connected UE from the MME 1 console by running the ue command.

In this output, one UE is listed with SUPI 001020123456789. This is the second UE, and the PLMN part of the IMSI is 00102. The REG field shows Y, which means the UE is registered in this MME. The PLMN field also shows 00102, confirming that this UE attached through PLMN 00102.

You can also confirm that the UE received an IP address. In this example, IP_ADDR is 192.168.2.100. This address is from the default PDN IP range configured in mme-ims-2plmn-1.cfg, so it confirms that the UE was served by MME 1 and received an address from the MME 1 IP pool.

So the main check here is that UE 001020123456789 is registered in MME 1 with PLMN 00102 and assigned IP address 192.168.2.100. This confirms that the second UE is connected to the second core network through the shared LTE cell.

LTE MOCN Run 9

Log Analysis

Sample Log

To verify MOCN operation, it is better to collect logs from most of the related components, including eNB, MME, and IMS if IMS service is involved. At minimum, you should enable RRC and NAS logs because these show the UE connection procedure, PLMN selection, attach request, authentication, security setup, and attach complete. However, for easier troubleshooting, I recommend enabling all major log components for both eNB and MME.

In the Amarisoft Web GUI, activate the log components such as MME, eNB, IMS, and MBMSGW as needed. For this tutorial, MME and eNB are the most important because MOCN behavior is mainly verified by checking whether each UE is routed to the correct MME according to the selected PLMN. The eNB log helps you confirm RRC connection and S1 routing, while the MME log helps you confirm NAS attach, registration status, PLMN, and assigned UE IP address.

Once logging is enabled, you can check the attach flow in the log viewer. For example, you should see messages such as Attach request, Authentication request/response, Security mode command/complete, Attach accept, Attach complete, and EMM information. These messages confirm that the UE completed the NAS attach procedure successfully. In this test, UE 1 should appear with IMSI 001010123456789 and PLMN 00101, while UE 2 should appear with IMSI 001020123456789 and PLMN 00102.

So the main point of this step is to collect enough logs to prove the complete MOCN behavior. The eNB confirms that both UEs access the same shared LTE cell, and the MME logs confirm that each UE is registered to the correct PLMN and assigned an IP address from the correct MME IP pool.

LTE MOCN Log 01

Enable all MME core-network log components from the Amarisoft Web GUI.

Select the MME component from the left panel, then open the log configuration window. In this window, set the MME-related layers to debug level and enable the payload option. This makes the log detailed enough to show NAS, S1AP, GTP-U, IMS, and other core-network messages.

For this MOCN test, NAS and S1AP are the most important logs. NAS shows the attach procedure, authentication, security mode, attach accept, attach complete, and PLMN registration. S1AP shows the signaling path between the eNB and the selected MME. However, enabling all MME components is useful because it gives you more information if the UE does not attach, if the wrong MME is selected, or if the UE does not receive the expected IP address.

After changing the log settings, press Update to apply the configuration. Once this is done, the MME log should contain enough information to verify that UE 1 is registered through PLMN 00101 on MME 0 and UE 2 is registered through PLMN 00102 on MME 1.

LTE MOCN Log 02

For log analysis, you can use the Layer filter in the Amarisoft Web GUI to focus only on the messages that are important for MOCN verification. In most cases, NAS, RRC, and S1AP are enough to understand the signaling flow.

RRC logs show the radio connection procedure between the UE and the eNB, such as RRC connection setup, UE capability enquiry, RRC reconfiguration, and RRC release. This confirms that the UE is connected to the shared LTE cell.

NAS logs show the attach and registration procedure, such as Attach request, Authentication, Security mode, Attach accept, Attach complete, Detach request, and Service request. This is where you can confirm the UE IMSI and the PLMN-related behavior.

S1AP logs show the signaling between the eNB and the MME. This is especially important for MOCN because it helps confirm which MME the eNB is using for each UE. In this test, UE 1 should be routed to the MME for PLMN 00101, and UE 2 should be routed to the MME for PLMN 00102.

So, for normal MOCN analysis, filter the log by RRC, NAS, and S1AP first. RRC confirms that the UE is connected to the cell, NAS confirms that the UE completes attach with the expected IMSI/PLMN, and S1AP confirms that the signaling is routed to the correct MME.

LTE MOCN Log 03

Make sure that S1AP connection is established for both MMEs before checking UE attach behavior. In the log, you should see S1 setup request and S1 setup response for the first MME, and then another S1 setup request and S1 setup response for the second MME. This confirms that the eNB has successfully connected to both core-network instances.

After confirming the S1AP connection, check SIB1 in the RRC log. SIB1 should include two PLMN identities, matching the PLMNs configured in the eNB configuration file. In this example, SIB1 broadcasts PLMN 00101 and PLMN 00102. This is a crucial part of MOCN because the UE can only select and camp on a PLMN if that PLMN is advertised by the cell.

So the key verification here is simple. S1AP confirms that the eNB is connected to both MMEs, and SIB1 confirms that the shared LTE cell is broadcasting both PLMNs. If both are correct, the MOCN foundation is ready: the same eNB can advertise multiple operators and route each UE toward the proper MME based on the selected PLMN.

LTE MOCN Log 04

Check the S1AP setup message toward MME1. You can identify this MME connection by checking the IP address and port in the log. In this example, the selected S1 setup request is sent to 127.0.1.100:36412, which corresponds to MME1/MME 0 in this test setup.

In the decoded S1 setup request, check pLMNidentity. Here, pLMNidentity is 00101, which means this S1 connection is established for the MME serving PLMN 00101.

Also check broadcastPLMNs under supportedTAs. In this example, broadcastPLMNs includes both 00101 and 00102. This means the eNB is telling the MME that the supported tracking area broadcasts both PLMNs. This is expected in MOCN because the shared eNB cell broadcasts multiple PLMNs even though this particular MME serves PLMN 00101.

So the important check here is that the S1 setup toward the first MME shows pLMNidentity = 00101, while broadcastPLMNs contains both 00101 and 00102. This confirms that the eNB is connected to the MME for PLMN 00101, and at the same time the shared cell is configured to broadcast both PLMNs.

LTE MOCN Log 05

Check the S1AP setup response from MME1 and confirm the servedPLMNs value.

In this example, the selected message is S1 setup response from 127.0.1.100. This response is coming from the first MME. In the decoded message, servedPLMNs is set to 00101, which means this MME is serving PLMN 00101.

This is different from broadcastPLMNs in the S1 setup request. broadcastPLMNs shows the PLMNs broadcast by the shared eNB cell, so it includes both 00101 and 00102. servedPLMNs in the S1 setup response shows the PLMN served by this specific MME, so for MME1/MME 0 it should be 00101.

So the key check here is that the S1 setup response from the first MME contains servedPLMNs = 00101. This confirms that the first MME is correctly configured as the core network for PLMN 00101.

LTE MOCN Log 06

Check the S1AP setup request toward MME2. You can identify this connection by the IP address and port number. In this example, the selected S1 setup request is sent to 127.0.1.101:36412, which corresponds to the second MME in this test setup.

In the decoded S1 setup request, pLMNidentity is shown as 00101. This value is part of the eNB identity information, so it does not necessarily mean that this MME serves only PLMN 00101. The more important field for MOCN broadcast information is broadcastPLMNs under supportedTAs.

Here, broadcastPLMNs includes both 00101 and 00102. This confirms that the eNB is informing the second MME that the tracking area/cell is broadcasting both PLMNs. This is expected because the shared eNB cell is configured to broadcast both PLMN 00101 and PLMN 00102 in SIB1.

So the key point is that the S1 setup request is sent to the second MME at 127.0.1.101:36412, and the message includes broadcastPLMNs = 00101 and 00102. This confirms that the shared eNB is connected to the second MME while still advertising both PLMNs as part of the MOCN cell configuration.

LTE MOCN Log 07

Check the S1AP setup response from the second MME and confirm the servedPLMNs value.

In this example, the selected message is the S1 setup response from 127.0.1.101:36412. This IP address corresponds to the second MME in this tutorial. In the decoded message, servedPLMNs is set to 00102, which means this MME is serving PLMN 00102.

This is the expected result. The first MME at 127.0.1.100 serves PLMN 00101, and the second MME at 127.0.1.101 serves PLMN 00102. Even though the eNB broadcasts both PLMNs in SIB1, each MME reports only the PLMN that it serves in the S1 setup response.

So the key check here is that the S1 setup response from the second MME contains servedPLMNs = 00102. This confirms that the second MME is correctly configured as the core network for PLMN 00102.

LTE MOCN Log 08

Check the Attach Request from the first UE and confirm the IMSI value.

In this log, the Attach Request is associated with UE ID 1, and the IMSI shown in the log is 001010123456789. This matches the first UE configuration in ue-lte-2plmn.cfg, where the IMSI was set to 001010123456789 and preferred_plmn_list was set to 00101.

The important point is the PLMN part of the IMSI. The IMSI starts with 00101, so this UE belongs to PLMN 00101. Since MME 0 is configured to serve PLMN 00101, this Attach Request should be handled by MME 0.

So this step confirms that UE 1 is the UE configured for PLMN 00101, and its Attach Request is using IMSI 001010123456789 as expected.

LTE MOCN Log 09

Check the S1AP Initial UE Message for the first UE and confirm the PLMN values in the TAI and EUTRAN-CGI fields.

In this example, the Initial UE Message is sent toward the first MME. You can identify it by the MME connection address and by the UE IMSI shown around the same attach flow. This is the UE with IMSI 001010123456789, so it should be handled by the MME serving PLMN 00101.

In the decoded S1AP message, id-TAI contains pLMNidentity = 00101 and TAC = 0001. This means the tracking area identity reported to the MME belongs to PLMN 00101. Also, id-EUTRAN-CGI contains pLMNidentity = 00101 and the cell ID value. This means the cell global identity used for this UE context is also associated with PLMN 00101.

So the important check here is that both id-TAI pLMNidentity and id-EUTRAN-CGI pLMNidentity are set to 00101. This confirms that the first UE is being reported to MME 1/MME 0 as a UE attached through PLMN 00101.

LTE MOCN Log 10

Check the S1AP Initial Context Setup Request message for the first UE.

This message is sent from the MME to the eNB after the UE has passed the earlier attach steps such as Attach Request, Authentication, and Security Mode. In this example, the message is sent from 127.0.1.100:36412, so it is coming from the MME that serves PLMN 00101.

In the message list, the UE is shown with IMSI 001010123456789. This confirms that this Initial Context Setup Request belongs to the first UE. The message asks the eNB to create the UE context and set up the radio/access bearer for this UE. After this step, the eNB can continue with RRC Connection Reconfiguration and complete the bearer setup procedure.

So the important point here is that the first UE is being handled by the correct MME, and the MME is now requesting the eNB to create the initial UE context. This is one of the key messages confirming that the attach procedure for UE 1 is progressing normally through PLMN 00101.

LTE MOCN Log 11

Check the Attach Accept message for UE1 and confirm the IP address assigned to the UE.

In this example, the Attach Accept belongs to UE1 with IMSI 001010123456789. In the decoded NAS message, you can see the default EPS bearer context information, and the PDN address field shows IPv4 = 192.168.2.2. This IP address is within the default PDN range configured in mme-ims-2plmn-0.cfg, where first_ip_addr was set to 192.168.2.2 and last_ip_addr was set to 192.168.2.66.

This confirms that UE1 is attached through MME 0 and receives an IP address from the MME 0 address pool. Since UE1 was configured for PLMN 00101, this result is expected.

So the main check here is that the Attach Accept for UE1 contains IPv4 address 192.168.2.2, and this address belongs to the IP range configured for PLMN 00101 / MME 0. This confirms that the UE attach and IP allocation are working correctly for the first PLMN.

LTE MOCN Log 12

Check the EMM Information message for UE1 and confirm the network name.

In this example, the EMM Information message belongs to UE1 with IMSI 001010123456789. In the decoded message, the Full name for network field is shown as "Amarisoft Network". This matches the network_name configured in mme-ims-2plmn-0.cfg.

This is another way to confirm that UE1 is being served by MME 0. Since MME 0 is configured for PLMN 00101 and uses the network name "Amarisoft Network", seeing this value in the EMM Information message means the UE received operator information from the expected MME.

So the main check here is that UE1 receives EMM Information with network name "Amarisoft Network". This confirms that UE1 is attached through the first MME / PLMN 00101 side.

LTE MOCN Log 13

Check the Attach Request from the second UE and confirm the IMSI value.

In this log, the Attach Request is associated with UE ID 2, so this is the second UE. In the decoded NAS message, the IMSI is shown as 001020123456789. This matches the second UE configuration in ue-lte-2plmn.cfg, where the IMSI was set to 001020123456789 and preferred_plmn_list was set to 00102.

The important part is the PLMN portion of the IMSI. Since the IMSI starts with 00102, this UE belongs to PLMN 00102. Therefore, this UE is expected to be handled by the second MME, which was configured to serve PLMN 00102.

So this step confirms that UE 2 is the UE configured for PLMN 00102, and its Attach Request is using IMSI 001020123456789 as expected.

LTE MOCN Log 14

Check the S1AP Initial UE Message for the second UE and confirm the PLMN values in id-TAI and id-EUTRAN-CGI.

In this example, the Initial UE Message is sent to the second MME at 127.0.1.101:36412. This message belongs to UE ID 2, which is the UE configured with IMSI 001020123456789 and preferred PLMN 00102.

In the decoded message, id-TAI pLMNidentity is set to 00102. This means the tracking area identity used for this UE is based on the PLMN selected by the UE, which is PLMN 00102. This is expected because UE2 is configured to camp on PLMN 00102.

However, id-EUTRAN-CGI pLMNidentity is shown as 00101. This indicates that the E-UTRAN Cell Global Identity is still using the primary PLMN identity of the cell. In this configuration, the cell itself appears to use PLMN 00101 as the main cell identity, while PLMN 00102 is included as an additional broadcast PLMN for MOCN operation.

So the important point here is that UE2 is routed to MME2 with id-TAI pLMNidentity = 00102, while id-EUTRAN-CGI pLMNidentity remains 00101. This is a useful detail to notice in MOCN logs because the selected PLMN for the UE and the primary PLMN used in the cell identity may not always be the same.

LTE MOCN Log 15

Check the S1AP Initial Context Setup Request message for the second UE.

In this example, the selected message is sent from 127.0.1.101:36412, so it is coming from the second MME. This message belongs to UE ID 2, which is the UE configured with IMSI 001020123456789 and PLMN 00102.

The Initial Context Setup Request is sent by the MME to the eNB after the UE has passed the initial attach steps, such as Attach Request, Authentication, and Security Mode. This message asks the eNB to create the UE context and set up the bearer for this UE.

In this log, you can also see bearer-related information such as E-RAB ID, transportLayerAddress, GTP-TEID, and NAS-PDU. These values indicate that the MME is preparing the user-plane bearer and sending the NAS message toward the UE through the eNB.

So the main point here is that the second UE is being handled by the second MME, and the MME is requesting the eNB to create the initial UE context. This confirms that the attach procedure for UE2 is progressing normally through PLMN 00102.

LTE MOCN Log 16

Check the Attach Accept message for UE2 and confirm the assigned IP address.

In this example, the Attach Accept belongs to UE2. In the decoded NAS message, the PDN address field shows IPv4 = 192.168.2.100. This address is within the default PDN range configured in mme-ims-2plmn-1.cfg, where first_ip_addr was set to 192.168.2.100 and last_ip_addr was set to 192.168.2.164.

This confirms that UE2 is attached through MME 1 and receives an IP address from the MME 1 address pool. Since UE2 was configured for PLMN 00102, this is the expected result.

So the main check here is simple. UE2 receives IP address 192.168.2.100, and this address belongs to the IP range configured for PLMN 00102 / MME 1. This confirms that the second UE is attached to the correct core network through the shared MOCN cell.

LTE MOCN Log 17

Check the EMM Information message for UE2 and confirm the network name.

In this example, the EMM Information message belongs to UE2. In the decoded message, the Full name for network field is shown as "Amarisoft Network 1". This matches the network_name configured in mme-ims-2plmn-1.cfg.

This confirms that UE2 is being served by the second MME. Since MME 1 is configured for PLMN 00102 and uses the network name "Amarisoft Network 1", seeing this value in the EMM Information message means the UE received operator information from the expected MME.

So the main check here is that UE2 receives EMM Information with network name "Amarisoft Network 1". Together with the earlier checks, this confirms that UE1 is served by PLMN 00101 / MME 0, while UE2 is served by PLMN 00102 / MME 1, even though both UEs are connected through the same shared LTE cell.

LTE MOCN Log 18

RRC / NAS Signaling

SIB1

: This is the SIBmessage sent by eNB  to configure multiple PLMN. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement).

{

  message c1: systemInformationBlockType1: {

    cellAccessRelatedInfo {

      plmn-IdentityList {

        {

          plmn-Identity {

            mcc {

              0,

              0,

              1

            },

            mnc {

              0,

              1

            }

          },

          cellReservedForOperatorUse notReserved

        },

        {

          plmn-Identity {

            mcc {

              0,

              0,

              1

            },

            mnc {

              0,

              2

            }

          },

          cellReservedForOperatorUse notReserved

        }

      },

      ...

    },

    cellSelectionInfo {

      ...

    },

    ...

    schedulingInfoList {

      ...

    },

    ...

  }

}

 

EMM Information

: This is the EMM Information sent by eNB  to inform the network name. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement).

Protocol discriminator = 0x7 (EPS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered)

Auth code = 0xba7bd082

Sequence number = 0x02

Protocol discriminator = 0x7 (EPS Mobility Management)

Security header = 0x0 (Plain NAS message, not security protected)

Message type = 0x61 (EMM information)

Full name for network:

  Length = 16

  Data = 81 c1 76 58 9e 9e bf cd 74 90 b3 4c bf bf e5 6b

Short name for network:

  Length = 9

  Data = 81 c1 76 58 9e 9e bf cd 74

Local time zone = 10

Universal time and local time zone:

  Data = 22 30 70 22 51 41 0a

Network daylight saving time:

  Length = 1

  Data = 00

 

Tips

Decoding Network Name

You can decode Network Name into human readable format using an online tool : http://smstools3.kekekasvi.com/topic.php?id=288

LTE MOCN Tips DecodingNetworkName 01

© 2025 All rights reserved | Legal notice |