Tag Archives: MME

How UEs get Time in LTE

EPC, LTE, Mobile Networks, , ,

You may have noticed in the settings on your phone the time source can be set to “Network”, but what does this actually entail and how is this information transferred?

The answer is actually quite simple,

In the NAS PDU of the Downlink NAS Transport message from the MME to the UE, is the Time Zone & Time field, which contains (unsuprisingly) the Timezone and Time.

Time is provided in UTC form with the current Timezone to show the offset.

This means that in the configuration for each TAC on your MME, you have to make sure that the eNBs in that TAC have the Timezone set for the location of the cells in that TAC, which is especially important when working across timezones.

There is no parameter for the date/time when Daylight savings time may change. But as soon as a UE goes Idle and then comes out of Idle mode, it’ll be given the updated timezone information, and during handovers the network time is also provided.
This means if you were using your phone at the moment when DST begins / ends you’d only see the updated time once the UE toggles into/out of Idle mode, or when performing a tracking-area update.

List of Open Source Evolved Packet Core (EPC) Implementations

EPC, LTE, Mobile Networks, Software, , , , , , ,

Open5Gs

Formerly NextEPC.

OpenAI Core Network

Related to / branched from OMEC.

Magma

Based on OMEC, with a focus on Fixed Wireless more than mobile.

Not fair to consider it just an EPC, Magma is highly scaleable and designed with a focus on Fixed Wireless offerings.

Supported by the Facebook Telecom Infra Project.

OMEC – Open Evolved Mobile Core

Supported by Open Networking Foundation, Sprint and several other large players.

OMEC has each Network Element in it’s own repo in GitHub and each is managed by a different team.

OpenMME – MME

In use by at least one commercial operator (in some capacity).

Next Generation Infrastructure Core (S-GW & P-GW)

Seems to only compile on 16.04 and not really

c3po – HSS / CDR / CTF

OpenCORD

srsEPC

(from the guys who produced srsLTE / srsENB / srsUE)

S1AP – Relative Capacity (87) on MME

EPC, EUTRAN, LTE, Mobile Networks, ,

In the S1-SETUP-RESPONSE and MME-CONFIGURATION-UPDATE there’s a RelativeMMECapacity (87) IE,

So what does it do?

Most eNBs support connections to multiple MMEs, for redundancy and scalability.

By returning a value from 0 to 255 the MME is able to indicate it’s available capacity to the eNB.

The eNB uses this information to determine which MME to dispatch to, for example:

MME PoolRelative Capacity
mme001.example.com20/255
mme002.example.com230/255
Example MME Pooling table

The eNB with the table above would likely dispatch any incoming traffic to MME002 as MME001 has very little at capacity.

If the capacity was at 1/255 then the MME would very rarely be used.

The exact mechanism for how the MME sets it’s relative capacity is up to the MME implementer, and may vary from MME to MME, but many MMEs support setting a base capacity (for example a less powerful MME you may want to set the relative capacity to make it look more utilised).

I looked to 3GPP to find what the spec says:

On S1, no specific procedure corresponds to the NAS node selection function.
The S1 interface supports the indication by the MME of its relative capacity to the eNB, in order to achieve loadbalanced MMEs within the pool area.

3GPP TS 36.410 – 5.9.2 NAS node selection function
Open5Gs Logo

Open5GS EPC: SGW selection by eNodeB ID / TAC

EPC, LTE, Mobile Networks, ,

Thanks to Kenny Barlee the Open5GS EPC MME now has the functionality to select which S-GW to send traffic to based on the Tracking Area Code of the eNodeB or the eNodeB ID.

This is a really useful Feature that allows you to break up your S-GW (And by extension P-GW) selection based on geographical areas.

This can be used to enable Local Breakout to a S/P-GW located at the same site as the tower, but controlled by a central MME / HSS.

After updating to the latest version the configuration is pretty straightforard,

P-GW Selection based on eNB ID

# o SGW selection by eNodeB ID (either single enb_id or multiple enb_ids, decimal or hex representation)
#
   selection_mode: enb_id
   gtpc:
     - addr: 127.0.2.3
       enb_id: [9413, 0x98765]

The above config will send any traffic from eNBs with the eNB ID 9413 (encoded as an intiger) or 0x98765 (Encoded as hex int equivilent 624485) to an S-GW at 127.0.2.3.

P-GW Selection based on TAC

# SGW selection by eNodeB TAC (either single TAC or multiple TACs)
#
selection_mode: tac
   gtpc:
     - addr: 127.0.2.2
       tac: [25000, 27000, 28000]

The above config will send any traffic from eNBs with TACs of 25000, 27000, 28000 to an S-GW at 127.0.2.2.

Connecting any 3rd Party HSS to Open5GS MME

EPC, LTE, Mobile Networks, , ,

You may want to connect Open5GS’ MME to a different Home Subscriber Server (HSS),

To do it we need a few bits of information:

  • The Domain Name of the HSS
  • The Realm of the HSS
  • The IP of the HSS
  • The Transport Used (TCP/SCTP)
  • If TLS is used

With these bits of information we can go about modifying the Open5GS MME config to talk to our different HSS.

Edit FreeDiameter Config

The config for the Open5GS MME’s Diameter peers is handled by the FreeDimaeter library,

You can find it’s config files in:

/etc/freediameter/mme.conf

We’ll start by changing the realm to match the realm of the HSS and the identity to match the identity configured as the MME peer on the HSS.

We’ll next set the ListenOn address to be a reachable IP address isntead of just a loopback address,

If you’re using TLS you’ll need to put your certificates and private key files into the TLS config,

Finally we’ll put our HSS details in the Peer Configuration;

Once all this is done we’ll need to restart our MME and you should see the Diameter Capabilities Exchange / Answer commands between the HSS and the MME if all was successful,

systemctl restart open5gs-mmed

In the /var/log/open5gs/mme.log I can now see:

05/11 23:25:46.896: [app] INFO: MME initialize…done (../src/mme/app-init.c:33)
05/11 23:25:46.898: [diam] INFO: CONNECTED TO 'hss.nickexamplenet' (SCTP,soc#15): (../lib/diameter/common/logger.c:108)

And that’s it! We’re connected to an external HSS.

Through the freeDiameter config file you can specify multiple ConnectPeer() entries to connect to multiple HSS (like a pool of them), and requests will be distributed evenly between them.

IMTx: NET02x (4G Network Essentials) – Mobility Management – 4. Changing MME and SGW

EPC, EUTRAN, LTE, Notes, RF, , ,

These are my lecture notes from IMT’s NET02x (4G Network Essentials) course, I thought I’d post them here as they may be useful to someone. You can find my complete notes here.

As we’ve seen earlier, the eNB needs a connection to an MME and a S-GW.

However different eNBs may connect to different S-GWs or different MMEs, and our UE may connect to any eNB, so we need a way to handover between S-GWs and MMEs.

Handover to new S-GW

Let’s take a look at a scenario where a UE is moving from one eNB to another, and each of the two eNBs is in a different S-GW.

At the start we have a connection from the MME to the S-GW, a GTP-C tunnel for control information and a GTP-U tunnel (called the S5/58 bearer) that carriers the user data over GTP-U between the P-GW and the S-GW.

As the UE moves to the eNB in TA2 we need the MME to modify the tunnel from the P-GW to the S-GW to change it from connecting the P-GW to the old S-GW and instead connecting the P-GW to the new S-GW.

The MME establishes a new tunnel for control to the new S-GW, and sends a message to the new S-GW to modify the tunnel from the P-GW to the old S-GW to point to the new S-GW.

Handover to new MME