Can the nextepc binaries be deployed on separate machines? about open5gs HOT 9 CLOSED

Of course. Let me give you some example configuration.

Update /etc/nextepc/mme.conf

Sukchanui-MacBook-Pro:nextepc acetcom$ diff -u mme.conf.old mme.conf
--- mme.conf.old	2018-04-25 07:12:05.000000000 +0900
+++ mme.conf	2018-04-25 07:12:30.000000000 +0900
@@ -14,7 +14,9 @@
 mme:
     freeDiameter: mme.conf
     s1ap:
+      addr: 5.5.5.1
     gtpc:
+      addr: 5.5.5.1
     gummei: 
       plmn_id:
         mcc: 001
@@ -34,7 +36,7 @@
 
 sgw:
     gtpc:
-      addr: 127.0.0.2
+      addr: 5.5.5.2
 
 pgw:
     gtpc:

Update /etc/nextepc/sgw.conf

Sukchanui-MacBook-Pro:nextepc acetcom$ diff -u sgw.conf.old sgw.conf
--- sgw.conf.old	2018-04-25 07:12:35.000000000 +0900
+++ sgw.conf	2018-04-25 07:12:46.000000000 +0900
@@ -12,5 +12,6 @@
 
 sgw:
     gtpc:
-      addr: 127.0.0.2
+      addr: 5.5.5.2
     gtpu:
+      addr: 5.5.5.2

Thanks!

from open5gs.

Thank you very much for your help, I am trying to follow your instructions, although I'm not having any luck.
I'm trying to run

• MME, PGW, PCRF, HSS, mongodb on 5.5.5.1
• SGW on 5.5.5.2

I'm using a conf file (identical on 5.5.5.1 and 5.5.5.2) as such

`db_uri: mongodb://5.5.5.1/nextepc

logger:
file: [...]
trace:
app: 1
s1ap: 1
nas: 1
diameter: 1
gtpv2: 1
gtp: 1

parameter:
no_ipv6: true

mme:
freeDiameter: mme.conf
s1ap:
gtpc:
addr: 5.5.5.1
gummei:
plmn_id:
mcc: 001
mnc: 01
mme_gid: 2
mme_code: 1
tai:
plmn_id:
mcc: 001
mnc: 01
tac: 12345
security:
integrity_order : [ EIA1, EIA2, EIA0 ]
ciphering_order : [ EEA0, EEA1, EEA2 ]
network_name:
full: NextEPC

hss:
freeDiameter: hss.conf

sgw:
gtpc:
addr: 5.5.5.2
gtpu:
addr: 5.5.5.2

pgw:
freeDiameter: pgw.conf
gtpc:
addr:
- 5.5.5.1
gtpu:
- addr: 5.5.5.1
ue_pool:
- addr: 45.45.0.1/16
- addr: cafe::1/64
apn: internet
dns:
- 8.8.8.8
- 8.8.4.4
- 2001:4860:4860::8888
- 2001:4860:4860::8844

pcrf:
freeDiameter: pcrf.conf`

freeDiameter conf files ([...]/freeDiameter/xxx.conf) are left untouched (each component listens on 127.0.0.x and connects to peer 127.0.0.y)

The components seem to talk to each other fine, but on attachment I get

[04/25 18:06:53.228] ASSERT:  ! ( index ). Invalid Index (mme_context.c:2124)
[04/25 18:06:53.228] ASSERT:  ! ( mme_ue ). No UE Context(TEID:0) (mme_sm.c:503)
[04/25 18:06:56.271] ASSERT:  ! ( index ). Invalid Index (mme_context.c:2124)
[04/25 18:06:56.271] ASSERT:  ! ( mme_ue ). No UE Context(TEID:0) (mme_sm.c:503)
[04/25 18:06:59.274] ASSERT:  ! ( index ). Invalid Index (mme_context.c:2124)
[04/25 18:06:59.274] ASSERT:  ! ( mme_ue ). No UE Context(TEID:0) (mme_sm.c:503)

do you have any insight on what might be going wrong?
The single-file epcd version works fine.

from open5gs.

SGW seems to send the GTP message with TEID=0. I’m not sure whether your configuration is correct or not.

Please, change all trace level to 5.
And then, use wireshark to capture packets.
(ENB-MME, MME-SGW, SGW-PGW)

Give us the all log files and pcap files.

Thanks!

from open5gs.

nextepc.zip

Dear Acetcom:
As I'm having the same issue, I'd contribute my log here.
Please checkout the messages at timestamp 18:09:33 ~ 18:09:42 (nextepc.log)
The process is in the end of security mode, (enb.pcapng)
The error message is generated when the diameter protocol is processing something like 3GPP-Update-Location Request(316) and 3GPP-Update-Location Response(316) (epc.pcapng)

[08/03 18:09:33.771] mme_state_operational(): MME_EVT_S11_MESSAGE
[08/03 18:09:33.771] ASSERT: !(index). Invalid Index (mme_context.c:2032)
[08/03 18:09:33.771] ASSERT: !(mme_ue). No UE Context(TEID:0) (mme_sm.c:531)
[08/03 18:09:36.783] WARN: [1] REMOTE Request Duplicated. Discard! for step 1 type 32 peer [192.168.100.207]:2123 (gtp_xact.c:431)
[08/03 18:09:36.784] mme_state_operational(): MME_EVT_S11_MESSAGE
[08/03 18:09:36.784] ASSERT: !(index). Invalid Index (mme_context.c:2032)
[08/03 18:09:36.784] ASSERT: !(mme_ue). No UE Context(TEID:0) (mme_sm.c:531)
[08/03 18:09:39.785] mme_state_operational(): MME_EVT_S11_T3_RESPONSE
[08/03 18:09:39.786] sgw_state_operational(): SGW_EVT_T3_RESPONSE
[08/03 18:09:39.786] sgw_state_operational(): SGW_EVT_S11_MESSAGE
[08/03 18:09:39.786] mme_state_operational(): MME_EVT_S11_MESSAGE
[08/03 18:09:39.786] WARN: [1] REMOTE Request Duplicated. Discard! for step 1 type 32 peer [192.168.100.207]:2123 (gtp_xact.c:431)

I have followed the IP config suggestions to ensure there's no conflict in mme/sgw gtpu/gtpc. (enclosing nextepc.conf for your reference)

I have to admit that my USRP is not enabled with GPSDO.
I hope this is not the case that causes the location request to fail.

Any light is appreciated.

Yeats

from open5gs.

The problem is not related to GPSDO.

In your configuration, SGW GTPC is set to 127.0.0.2, and PGW GTPC is set to 127.0.0.3. In this case, the log should look like this:

[08/03 20:46:56.691] sgw_state_operational(): SGW_EVT_S11_MESSAGE
[08/03 20:46:56.691] gtp_client() [192.168.0.3]:2123
[08/03 20:46:56.691] [SGW] Create Session Reqeust
[08/03 20:46:56.692]     MME_S11_TEID[1] SGW_S11_TEID[1]
[08/03 20:46:56.692]     SGW_S5C_TEID[0x80000001] PGW_S5C_TEID[0x0]
[08/03 20:46:56.692]     SGW_S5U_TEID[2] PGW_S5U_TEID[0]
[08/03 20:46:56.692] gtp_client() [127.0.0.3]:2123
[08/03 20:46:56.692] pgw_state_operational(): PGW_EVT_S5C_MESSAGE
[08/03 20:46:56.693] gtp_client() [127.0.0.2]:2123

See the gtp_client() trace. If SGW receives the Create Session Request, SGW attempts to connect PGW GTPC(127.0.0.3). The PGW then attempts to connect the SGW GTPC(127.0.0.2) when the PGW receives the create session request.

When the SGW receives a session creation request from the MME, the SGW attempts to connect to the 192.168.100.207 from the log. Why is it 192.168.100.207? I do not think the configuration applies to your environment. Therefore, the session creation request is sent to the MME and an ASSERT occurs.

This is my observation.

from open5gs.

I'm a bit confused.
as in freediameter the ip settings can be concluded as
127.0.0.2 mme mme.localdomain
127.0.0.3 pgw pgw.localdomain
127.0.0.4 hss hss.localdomain
127.0.0.5 pcrf pcrf.localdomain

but in /etc/nextepc/nextepc.conf the proposed default setting is different,
mme becomes "127.0.0.1" and sgw takes "127.0.0.2", as shown below.
Running such setting will get the same error, invalid index.

/etc/nextepc/nextepc.conf
###############
mme:
freeDiameter: mme.conf
#S1AP Server(0.0.0.0:36412)
s1ap:

#GTP-C Server(127.0.0.1:2123, [::1]:2123) #mme is 127.0.0.2 in freediameter
gtpc:
###############
sgw:
#GTP-C Server(127.0.0.2:2123, [fe80::2%lo]:2123) #sgw conflicts mme's diameter address ?
gtpc:
addr: 127.0.0.2 #port 2123 is conflict with the mme default gtpc *:2123 ?

#GTP-U Server(all address avaiable)
gtpu:
################
pgw:
freeDiameter: pgw.conf

#On PGW, Same configuration(127.0.0.3:2123, [fe80::3%lo]:2123) as below.
gtpc:
addr: 127.0.0.3

#Same configuration(127.0.0.3:2152, [::1]:2152) as below.
gtpu:
addr: 127.0.0.3 Was port 2152 used in sgw gtpu ?

ue_pool:
  addr: 45.45.0.1/16
dns:
  - 8.8.8.8
  - 168.95.1.1

###############

Same error message, invalid index, and worse, no Response from *:2123

[08/03 23:45:34.140] gtp_client() [192.168.3.207]:2123
[08/03 23:45:34.140] [SGW] Create Session Reqeust
[08/03 23:45:34.140] MME_S11_TEID[1] SGW_S11_TEID[1]
[08/03 23:45:34.140] SGW_S5C_TEID[0x80000001] PGW_S5C_TEID[0x0]
[08/03 23:45:34.140] SGW_S5U_TEID[2] PGW_S5U_TEID[0]
[08/03 23:45:34.140] gtp_client() [192.168.100.207]:2123
[08/03 23:45:34.140] mme_state_operational(): MME_EVT_S11_MESSAGE
[08/03 23:45:34.141] ASSERT: !(index). Invalid Index (mme_context.c:2032)
[08/03 23:45:34.141] ASSERT: !(mme_ue). No UE Context(TEID:0) (mme_sm.c:531)
[08/03 23:45:37.145] sgw_state_operational(): SGW_EVT_T3_RESPONSE
[08/03 23:45:37.146] mme_state_operational(): MME_EVT_S11_MESSAGE
[08/03 23:45:37.146] ASSERT: !(index). Invalid Index (mme_context.c:2032)
[08/03 23:45:37.146] ASSERT: !(mme_ue). No UE Context(TEID:0) (mme_sm.c:531)
[08/03 23:45:37.181] mme_state_operational(): MME_EVT_S11_T3_RESPONSE
[08/03 23:45:37.181] sgw_state_operational(): SGW_EVT_S11_MESSAGE
[08/03 23:45:37.181] WARN: [1] REMOTE Request Duplicated. Discard! for step 1 type 32 peer [192.168.3.207]:2123 (gtp_xact.c:431)
[08/03 23:45:40.149] sgw_state_operational(): SGW_EVT_T3_RESPONSE
[08/03 23:45:40.149] mme_state_operational(): MME_EVT_S11_MESSAGE
[08/03 23:45:40.149] ASSERT: !(index). Invalid Index (mme_context.c:2032)
[08/03 23:45:40.149] ASSERT: !(mme_ue). No UE Context(TEID:0) (mme_sm.c:531)
[08/03 23:45:40.186] mme_state_operational(): MME_EVT_S11_T3_RESPONSE
[08/03 23:45:40.186] sgw_state_operational(): SGW_EVT_S11_MESSAGE
[08/03 23:45:40.186] WARN: [1] REMOTE Request Duplicated. Discard! for step 1 type 32 peer [192.168.3.207]:2123 (gtp_xact.c:431)
[08/03 23:45:43.142] sgw_state_operational(): SGW_EVT_T3_HOLDING
[08/03 23:45:43.152] sgw_state_operational(): SGW_EVT_T3_RESPONSE
[08/03 23:45:43.152] WARN: [1] LOCAL No Reponse. Give up! for step 1 type 32 peer [192.168.100.207]:2123 (gtp_xact.c:649)
[08/03 23:45:43.190] mme_state_operational(): MME_EVT_S11_T3_RESPONSE
[08/03 23:45:43.190] WARN: [1] LOCAL No Reponse. Give up! for step 1 type 32 peer [127.0.0.2]:2123 (gtp_xact.c:649)

from open5gs.

Thanks for the tips from acetcom,
I now passed the attach process and the eNB can surf the internet with 6MB speed.

The root cause is on gtpc listening on port 2123.
There are three gtpc to setup in nextepc.conf
From the log I found the procotol keeps trying to connect 192.168.100.207:2123 no matter how I did, so it must be the one among three gtpc settings. I tried it one by one. mme not working, sgw not working, and eventually pgw works.

Though it works, I don't understand why it is like this.
perhaps the devs want to change the listening ports for each gtpc in the future, in case confusion occurs.

mme:
gtpc:
addr: 127.0.0.1 (default: *:3123)
sgw:
gtpc:
addr: 127.0.0.2 (default: 127.0.0.2)
pgw:
gtpc:
- addr: 127.0.0.3 (default: only 127.0.0.3)
- addr: 192.168.100.207 (the key to success)

Enclosing the working config for your reference.
nextepc.conf.txt

from open5gs.

I don’t also understand why 192.168.100.207 is needed in pgw gtpc.

Anyway it is good starting!

Enjoy with nextepc!

from open5gs.

Indeed, as I understand about the protocol, only S1ap and gtpU requires real IP.
Perhaps the devs want to implement a futuristic feature such as multi-epc interconnections.

root@nextepc:# netstat -lpn|grep epc
tcp　　　127.0.0.2:5868　　　　　　0.0.0.0:*　　　 LISTEN 1642/nextepc-epcd
tcp　　　127.0.0.4:5868　　　 　　0.0.0.0:*　　　 LISTEN 1739/nextepc-epcd
tcp　　　127.0.0.3:5868　　　 　　0.0.0.0:*　　　 LISTEN 1697/nextepc-epcd
tcp　　　127.0.0.5:5868　　　 　　0.0.0.0:*　　　 LISTEN 1644/nextepc-epcd
tcp　　　127.0.0.2:3868　　　 　　0.0.0.0:*　　　 LISTEN 1642/nextepc-epcd
tcp　　　127.0.0.4:3868　　　 　　0.0.0.0:*　　　 LISTEN 1739/nextepc-epcd
tcp　　　127.0.0.3:3868　　　 　　0.0.0.0:*　　　 LISTEN 1697/nextepc-epcd
tcp　　　127.0.0.5:3868　　　 　　 0.0.0.0:*　　　 LISTEN 1644/nextepc-epcd
sctp 　 　192.168.100.207:36412　　　　　　　　　　 LISTEN 1642/nextepc-epcd
udp 　　127.0.0.1:2123　　　　　　0.0.0.0:*　　　　　　　　 1642/nextepc-epcd
udp 　　127.0.0.2:2123　　　　　　0.0.0.0:*　　　　　　　 1734/nextepc-epcd
udp 　 　192.168.100.207:2123 　　0.0.0.0:*　　　　　 　　 1697/nextepc-epcd
udp 　　127.0.0.3:2123　　　　　　0.0.0.0:*　　　　　 　　1697/nextepc-epcd
udp 　 　192.168.100.207:2152 　　0.0.0.0:*　　　　　　 　1734/nextepc-epcd
udp 　　127.0.0.3:2152　　　　　　0.0.0.0:*　　　　　　 　1697/nextepc-epcd
　

from open5gs.