search

omec-project / amf

17 stars 38 forks source link

feat: use DRSM only when database is enabled #270

Closed dariofaccin closed 2 months ago

dariofaccin commented 5 months ago

This PR aims to fix #261 by initializing the DRSM library only when EnableDbStore config option is enabled. DRSM library is used to create mappings between an AMF instance and its owned resources (TMSI, UE NGAP IP, GUTI-UE, etc). This allows, in presence of multiple AMFs, to redirect messages between instances. Each AMF instance owns a chunk in a MongoDB sharded mongodb (cluster or instance). When EnableDbStore option is disabled, no mongoDB instance is expected to be deployed and available to AMF, therefore DRSM library should not be initialized in such scenario. This implies that only a single AMF instance can be used when EnableDbStore is disabled. Main changes:

thakurajayL commented 5 months ago

Could you please check search/find type of APIs as well. So far you have done changes correctly !

gab-arrobo commented 4 months ago

@dariofaccin, have you tested the changes for both scenarios (database enabled and database disabled)? I am asking this because I am currently trying to run an E2E test using your changes when the database is enabled but the test fails due to NG setup failure. Here is a snippet of the amf log:

...
2024-07-20T04:56:23Z [INFO][AMF][NGAP][10.154.48.197:48959] Handle NG Setup request
2024-07-20T04:56:23Z [WARN][AMF][NGAP][10.154.48.197:48959] NG-Setup failure: Cannot find Served TAI in AMF
2024-07-20T04:56:23Z [INFO][AMF][NGAP][10.154.48.197:48959] Send NG-Setup failure
2024/07/20 04:56:23 Send Response message body from client (amf-f847bc69-2m9df): Verbose - Message from AMF, MsgType AMF_MSG GnbId: 208:93:001001
...
dariofaccin commented 4 months ago

@gab-arrobo with EnableDbStore set to true I get this:

2024-07-22T08:00:29.108Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][NGAP] [AMF] SCTP Accept from: 10.1.142.72/192.168.251.5:9487
2024-07-22T08:00:29.110Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][NGAP] Create a new NG connection for: 10.1.142.72/192.168.251.5:9487
2024-07-22T08:00:29.110Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][NGAP][10.1.142.72/192.168.251.5:9487] Handle NG Setup request
2024-07-22T08:00:29.110Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][NGAP][10.1.142.72/192.168.251.5:9487] Supported Tai List in AMF Plmn: &{208 93}, Tac: 0x000001 Tac: 1
2024-07-22T08:00:29.110Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][NGAP][10.1.142.72/192.168.251.5:9487] Send NG-Setup response
2024-07-22T08:00:29.114Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][NGAP][10.1.142.72/192.168.251.5:9487] RanUe is not exist
2024-07-22T08:00:29.114Z [amf] 2024-07-22T08:00:29Z [ERRO][AMF][DRepo] DbFetchRanUeByRanUeNgapID: no document found for ranUeNgapID  1308622848
2024-07-22T08:00:29.114Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][NGAP][10.1.142.72/192.168.251.5:9487] Handle Initial UE Message
2024-07-22T08:00:29.114Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][NGAP][10.1.142.72/192.168.251.5:9487] RanUe is not exist
2024-07-22T08:00:29.115Z [amf] 2024-07-22T08:00:29Z [ERRO][AMF][DRepo] DbFetchRanUeByRanUeNgapID: no document found for ranUeNgapID  1308622848
2024-07-22T08:00:29.115Z [amf] 2024-07-22T08:00:29Z [DEBU][DRSM][App] Allocate new chunk
2024-07-22T08:00:29.115Z [amf] 2024-07-22T08:00:29Z [DEBU][DRSM][App] Found chunk Id block  9893
2024-07-22T08:00:29.116Z [amf] 2024/07/22 08:00:29 Adding chunk 9893 success 
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][Context] Allocate AmfUeNgapID : 10131431
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][DRSM][App] received Chunk Doc: &{chunkid-9893 chunkid-9893 amf-0 10.1.142.112 e8b83bbc-b000-46d4-8615-09a78b5846d3 0001-01-01 00:00:00 +0000 UTC chunk}
2024-07-22T08:00:29.116Z [amf] 2024/07/22 08:00:29 id received: chunkid-9893 value
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][DRSM][App] Chunk id 9893, podChunks map[9893:0xc00079c120]
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][Comm] Security header type: PlainNas Message
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][Context] Allocate TMSI : 10131430
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][NGAP][10.1.142.72/192.168.251.5:9487][AMF_UE_NGAP_ID:10131431] Antype from new RanUe : 3GPP_ACCESS
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][GMM][AMF_UE_NGAP_ID:10131431] New EventChannel created
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][GMM][AMF_UE_NGAP_ID:10131431] updated nashandler
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][GMM][AMF_UE_NGAP_ID:10131431] updated nashandler
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][NAS][AMF_UE_NGAP_ID:10131431] Handle Nas Message
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][LIB][FSM] Handle event[Gmm Message], transition from [Deregistered] to [Deregistered]
2024-07-22T08:00:29.116Z [amf] 2024-07-22T08:00:29Z [INFO][AMF][GMM][AMF_UE_NGAP_ID:10131431] Handle Registration Request
2024-07-22T08:00:29.117Z [amf] 2024-07-22T08:00:29Z [INFO][LIB][FSM] Handle event[Start Authentication], transition from [Deregistered] to [Authentication]

I am however getting errors afterwards:

2024-07-22T10:13:58.704Z [amf] 2024-07-22T10:13:58Z [INFO][AMF][GMM][AMF_UE_NGAP_ID:-1][SUCI:suci-0-208-93-0-0-0-0100007487] Authentication procedure
2024-07-22T10:13:58.715Z [amf] 2024-07-22T10:13:58Z [INFO][AMF][GMM][AMF_UE_NGAP_ID:-1][SUCI:suci-0-208-93-0-0-0-0100007487] Send Authentication Request
2024-07-22T10:13:58.715Z [amf] 2024-07-22T10:13:58Z [INFO][AMF][NGAP][10.1.142.72/192.168.251.5:9487][AMF_UE_NGAP_ID:-1] Send Downlink Nas Transport
2024-07-22T10:13:58.715Z [amf] 2024-07-22T10:13:58Z [ERRO][AMF][NGAP][10.1.142.72/192.168.251.5:9487][AMF_UE_NGAP_ID:-1] Build DownlinkNasTransport failed : INTEGER value is smaller than lowerbound

Under investigation.

gab-arrobo commented 3 months ago

@dariofaccin, are you planning to address @ghislainbourgeois's comments? or is your PR ready to review/merge?

dariofaccin commented 3 months ago

@gab-arrobo unfortunately the solution proposed by @ghislainbourgeois (using the type assertions) doesn't work. After discussing with @thakurajayL , we agreed that typecasting is the least impacting way of solving the int32/int64 inconsistency. Since the local generators are initialized with a max int32 range (https://github.com/omec-project/amf/blob/5279412c0cb62837ba083f2f9ba398c11d4ef84d/context/context.go#L47) there is not overflow risk.

gab-arrobo commented 3 months ago

@gab-arrobo unfortunately the solution proposed by @ghislainbourgeois (using the type assertions) doesn't work. After discussing with @thakurajayL , we agreed that typecasting is the least impacting way of solving the int32/int64 inconsistency. Since the local generators are initialized with a max int32 range (

https://github.com/omec-project/amf/blob/5279412c0cb62837ba083f2f9ba398c11d4ef84d/context/context.go#L47

) there is not overflow risk.

Ok, thanks for the clarification. So, I guess all conversations are resolved, correct? If so, please mark them as resolved.

Also, I am going to review your PR today.

gab-arrobo commented 3 months ago

@dariofaccin, there is still a comment that has not been addressed. Also, please address the few lint issues that now show up due to a newer golangci-lint version. There are 2 ways to address the linter issue as discussed here between @gatici and myself.

@dariofaccin, it looks like @gatici's PR #281 addresses the lint issues. So, please just address this comment and I think we would be good to finalize its review