S1-flex: configuration and NNSF extension
OpenAirInterface has support for S1-flex, i.e. it can be connected to multiple MMEs (of possibly different operators) and route control plane traffic to the right MME. S-GW selection is implicit, as a S-GW is indicated by the MME and therefore data plane traffic routing is done appropriately.
The LTE RRC SIB1 message has support of broadcasting up to six PLMN IDs. A UE can indicate the desired network (the selected PLMN Identity in the RRCConnectionSetupComplete message). Support for this has been added, too.
Configuration
Instead of the previous configuration
tracking_area_code = "1";
mobile_country_code = "208";
mobile_network_code = "94";the MCC/MNC configuration now becomes a list (in this example with two PLMN IDs):
tracking_area_code = 1;
plmn_list = (
{ mcc = 208; mnc = 94; mnc_length = 2; },
{ mcc = 208; mnc = 95; mnc_length = 2; }
)plmn_list can contain up to six elements. Please mind that all values are now passed as an integer (not a string). This has the advantage that the configuration module can check the allowed values. The mnc_length field was implicit before; it may be set to 2 or 3 and better reflects the internal data representation. The values of the broadcast_plmn_index parameter described below are indices over the plmn_list.
According to the example, the SystemInformationBlock1 will now be broadcasted with PLMN IDs 20894 and 20805. A phone should also show both IDs in the network selection dialog.
If plmn_list is not defined or the old mobile_country_code/mobile_network_code parameters are present, initialization will be aborted. Please note the tracking_area_code now also is an integer (as opposed to the string representation before) due to implicit parameter checking of the configuration module. If it is left as string, this could lead to misbehavior and cannot be detected by the configuration module at the moment.
To connect to two MMEs of one or more operators, simply add them to the mme_ip_address list like so:
mme_ip_address = (
{
ipv4 = "192.168.12.240";
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
},
{
// ... second MME ...
}
);In particular, when sniffing network traffic of the eNodeB, you should see multiple S1SetupRequests directed to each of the MMEs listed in your configuration.
An additional broadcast_plmn_index parameter has been added. It permits to define the Global eNodeB ID as exposed to the MME in S1SetupRequest as well as defining which broadcasted PLMNs are communicated. Assuming the above given plmn_list with two Broadcast PLMNs, the following example defines that the eNodeB communicates the first PLMN both as ID and its only PLMN tracking area to the first MME ([0]), whereas for the second MME, the second PLMN is used as ID and both the first and second PLMN ([0,1]) are anounced in its tracking area.
mme_ip_address = (
{
// IP address etc here
broadcast_plmn_index = [0];
},
{
// IP address etc here
broadcast_plmn_index = [1,0];
}
);If broadcast_plmn_index = [1] was given for the second MME, the second PLMN ID would be used for both Global eNodeB ID and PLMN tracking area. Thus, no MME would know that this eNodeB operates for different CNs. Leaving out this parameter assumes a default of [0,...,N-1] for all MMEs with N being the number of PLMN IDs in the plmn_list.
When connecting a UE, it should now be routed to the right MME. Check again the Wireshark traffic to verify this and read the section below to understand how MMEs are selected at the NAS First Request.
NNSF (NAS Node Selection Function)
The appropriate MME is selected in the NNSF (NAS Node Selection Function). The different selection functions (see list below) are implemented in the file s1ap_eNB_nnsf.c and called from s1ap_eNB_nas_procedures.c.
TS 36.300 19.2.1.7 briefly describes how an MME should be selected. In OAI, MMEs are selected by
- GUMMEI,
- MME code,
- Selected PLMN Identity from RRCConnectionSetupComplete, or
- Smallest MME capacity ratio.
In the following, these steps are described. Differences with regard to OAI versions prior to tag 2018.w38 are marked in italics.
1. NNSF through GUMMEI
In the case a UE indicates the last registered MME, its GUMMEI is used to find this MME among the currently connected MMEs.
Previous versions of OAI simply returned the MME with the highest capacity if an MME with the indicated GUMMEI could not be found. This however might lead to false positives with respect to the selected PLMN Identity and has therefore been moved to step 3 (and is also checked in step 4).
2. MME code
In the case a UE indicates the MME code of the last registered MME, this code together with the selected PLMN identity is used to find this MME among the currently connected MMEs.
Previous versions of OAI ignored the selected PLMN identity and returned the MME with the highest capacity if no MME matched the requested MME code. This however could lead to false positives. Now, if no MME could be found, no MME is returned. The code checking for the highest MME capacity has been removed and is left to steps 3 or 4.
3. Selected PLMN Identity from RRCConnectionSetupComplete
If no last registered MME or no MME code are indicated, an MME indicating to serve the requested PLMN (using the selected PLMN identity from the RRCConnectionSetupComplete message) is chosen. An MME indicates this in S1SetupResponse message at S1AP setup (servedGUMMEIs). The MME matching this criteria and having the smallest MME capacity ratio is chosen.
Previous versions of OAI did not include this step.
4. Highest MME capacity
If no MME has been selected prior to this step (i.e. no GUMMEI or MME code are indicated, or no MME is registered serving the selected PLMN identity), the MME with the smallest MME capacity ratio is chosen.
Unchanged with respect to previous OAI versions.
Calclation MME capacity ratio
Calclate capacity_rate from RMC and number of connected UE to that MME as following.
Weight per MME = ( Total RMC of all MME / RMC per MME )
MME capacity ratio = Weight per MME * ( numer of connected UE to that MME +1)