Osmocom Analog » Osmo-CC

h1. Open5GS-Traces

{{>toc}}

h2. Setup of this example

* Ericsson RBS 6402 (eNodeB)

* Open5GS (4G network elements)

* OsmoHLR with OsmoDia2GSUP (HSS)

* OsmoMSC (SMS)

h2. Wireshark trace

This trace was used in this example. It includes attachment and detachment.

* attachment:attach_detach.pcapng

h2. Idle

When all phones are Idle, one will see the following trace with Wireshark on the link between eNodeB (Ericsson RBS) and MME (Open5GS).

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_idle.png, size=600)}}

The eNodeB (IP 10.0.15.117) is connected to MME (IP 10.0.15.1) via SCTP. Also the eNodeB syncs its clock to NTP server (IP 10.0.15.1).

The network 10.0.15.0/24 is the RAN network in this example.

h2. 4G Attachment

!enb_attach.png!

The phone is turned on and ready to attach to 4G network. The filter of Wireshark is set to "s1ap", so that only packages between eNodeB and MME are shown.

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_attach.png, size=1000)}}

A 4G phone is attached to the network, using SIM cards that is registered in the HSS. The APN name used is "internet".

Lets go into detail:

h3. Attach request

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_attach_attach_request.png, size=1000)}}

The UE sends an "Attach request". It is the message type of the "NAS-PDU" information element of the "initiatingMessage". The "NAS-PDU" message type is highlighted blue in the picture above.

Also within the "NAS-PDU" is the "EPS mobile identity". In this case the UE has the mobile country code "999" and the mobile network code "10". The IMSI is not shown. Because the UE was attached before, a TMSI is used. 

If the mobile station was not registered to the MME, the MME will request identity and authentication and send "Attach Request" again after enabling encryption

h3. "Identity request" and "Identity response"

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_attach_identity_request.png, size=1000)}}

Because identity is not know, the MME requests IMSI, as . (The MME was restartet before this trace, so that the TMSI is unknown.)

The MME sends an "Identity request" to the UE. The "NAS-PDU" message type is highlighted blue in the picture above. The identity type requested is highlighted light blue in the picture above.

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_attach_identity_response.png, size=1000)}}

The MME receives the response with IMSI. Again, the "NAS-PDU" message type is highlighted blue in the picture above. The mobile identity is highlighted light blue in the picture above. The IMSI is now known to the MME.

h3. "Authentication request" and "Authentication response"

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_attach_authentication_request.png, size=1000)}}

The MME sends an "Authentication request" to the UE. The "NAS-PDU" message type is highlighted blue in the picture above.

A random value "RAND" and authentication parameters "AUTN" are used to request authentication from UE.

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_attach_authentication_response.png, size=1000)}}

The UE sends an "Authentication response" to the UE. The "NAS-PDU" message type is highlighted blue in the picture above.

The result "RES" is returned to the MME. (Highlighted light blue in the picture above.)

The subsequent “Security mode command” and “Security mode complete” messages are not depicted. The latter message is sent after encryption between UE and eNodeB is enabled. The message also carries the Attach request again.

h3. "ESM information request" and "ESM information response"

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_attach_ESM_infomation_request.png, size=1000)}}

The MME sends an "ESM information request" to the UE, to request APN name. The "NAS-PDU" message type is highlighted blue in the picture above.

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_attach_ESM_infomation_response.png, size=1000)}}

The UE send an "ESM information response." The UE uses the APN name "internet". The "NAS-PDU" message type is highlighted blue in the picture above.

This is the default configuration in the example setup. It can be configured in the configuration file for OsmoHLR. (osmo-hlr.cfg)

h3. "Attach accept"

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_attach_attach_accept.png, size=1000)}}

The MME sends an "Attach accept" to the UE. The "NAS-PDU" message type is highlighted blue in the picture above.

Also within the “NAS-PDU” is an “ESM message container” with an “EPS session management message” to activate the default EPS bearer context. (Highlighted light blue in the picture above.)

The subsequent “InitialContextSetupResponse” and “UECapabilityInfoIndication” messages are not depicted. The latter message contains capabilities of the UE.

h3. "Attach complete"

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_attach_attach_complete.png, size=1000)}}

Finally the UE sends an "Attach complete". The "NAS-PDU" message type is highlighted blue in the picture above.

Also within the “NAS-PDU” is an “ESM message container” with an “Activate default EPS bearer context accept”. (Highlighted light blue in the picture above.)

h2. Packet transfer

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_gtp_1.png, size=1000)}}

The "GPRS Tunneling Protocol" (GTP) is used to tunnel packet traffic of the user plane. between eNodeB and SGW.

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_gtp_2.png, size=1000)}}

As depicted above, the GTP packet transmitted from the eNodeB (IP 10.0.15.117) to the SGW (IP 10.0.15.3).

The carried packet is transmitted from the UE (IP 10.0.6.2) to the destination in the Internet (IP 104.26.15.42)

h2. 4G Detachment

!enb_detach.png!

The 4G phone is turned off or the airplane mode is turned on. The phone detaches from network.

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_detach.png, size=1000)}}

Lets go into detail:

h3. "Detach Request"

p{border: solid 1px #000; padding: 0.5em;}. {{thumbnail(wireshark_enb_detach_detach_request.png, size=1000)}}

Similar to the "Attach request", described above, the UE sends an "Detach request". It is the message type of the "NAS-PDU" information element of the "initiatingMessage". The "NAS-PDU" message type is highlighted blue in the picture above.

Also within the "NAS-PDU" is the "EPS mobile identity". This is also similar to the "Attach request".

The subsequent “UEContextReleaseCommand” message (sent from EMM) and “UEContextREleaseComplete” messages (sent from UE) are not depicted.

h2. Attachment inside EPC

!epc_attach.png!

After authentication is done and after receiving ESM information (e.g. APN), a session is created between network elements inside the Envolved Packet Code (EPC).

{{thumbnail(wireshark_epc_attach.png, size=1000)}}

h3. MME -> SGWc

As depicted in the Wireshark picture above, the MME sends "Create Session Request" towards the control plane of the SGW. The GPRS tunneling protocol (GTP) is used. The request is depicted at frame number 254, the response at frame number 266.

h3. SGWc -> SGWu

After receiving the "Create Session Request" from the MME, the control plane of the SGW sends a "PFCP Session Establishment Request" to the user plane of the SGW. The packet forwarding control protocol (PFCP) is used. The request is depicted at frame number 255, the response at frame number 257.

h3. SGWc -> PGWc

The control plane of the SGW also sends a "Create Session Request" to the control plane of the PGW. The GPRS tunneling protocol (GTP) is used here again. The request is depicted at frame number 258, the response at frame number 263.

h3. PGWc -> PCRF

The control plane of the PGW sends a "Credit-Control Request" to the PCRF. The Diameter protocol is used. The request is depicted at frame number 259, the answer at frame number 260.

h3. PGWc -> PGWu

After receiving the "Credit-Control Answer" from the PCRF, the control plane of the PGW sends a "PFCP Session Establishment Request" to the user plane of the PGW. The packet forwarding control protocol (PFCP) is used here again. The request is depicted at frame number 261, the response at frame number 262.

h3. SGWc -> SGWu

After receiving the "Create Session Response" from the control plane of the PGW, the control plane of the SGW sends a "PFCP Session Modification Request" to the user plane of the SGW. The packet forwarding control protocol (PFCP) is used here again. The request is depicted at frame number 264, the response at frame number 265.