-
Notifications
You must be signed in to change notification settings - Fork 128
fix: AMF-UE-NGAP-ID shall be unique within an AMF Set as specified in TS 23.501 #168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes an interoperability issue where AMF UE NGAP IDs were being regenerated during handover procedures instead of maintaining the same ID as required by 3GPP specifications. The fix ensures that the AMF UE NGAP ID remains unique and consistent within an AMF Set during N2-based handovers.
- Creates new target RAN UE entities using the existing AMF UE NGAP ID from the source UE
- Introduces specialized lookup functions to distinguish between source and target UE contexts during handover
- Updates handover and path switch procedures to use appropriate UE lookup methods
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| internal/ngap/message/send.go | Modified handover request to reuse existing AMF UE NGAP ID |
| internal/ngap/handler.go | Updated UE lookup calls to use source/target-specific methods |
| internal/context/context.go | Added separate lookup functions for source and target UE contexts |
| internal/context/amf_ran.go | Added new method to create RAN UE with predefined AMF UE NGAP ID |
Comments suppressed due to low confidence (2)
internal/context/context.go:491
- [nitpick] The function name 'RanUeFindTargetByAmfUeNgapID' is ambiguous about what constitutes a 'target' UE. Consider a more descriptive name like 'RanUeFindByAmfUeNgapIDPreferTarget' to clarify that it returns the target UE if available, otherwise the base UE.
func (context *AMFContext) RanUeFindTargetByAmfUeNgapID(amfUeNgapID int64) *RanUe {
internal/context/context.go:480
- [nitpick] The function name 'RanUeFindSourceByAmfUeNgapID' is ambiguous about what constitutes a 'source' UE. Consider a more descriptive name like 'RanUeFindByAmfUeNgapIDPreferSource' to clarify that it returns the source UE if available, otherwise the base UE.
func (context *AMFContext) RanUeFindSourceByAmfUeNgapID(amfUeNgapID int64) *RanUe {
|
Hi, @louisroyer I've run the N2Handover test, it does not pass neither with removing It would get a lot errors at AMF's log. |
Hi @Alonza0314 |
|
Oh, sorry. It's typo. |
|
uh, that's probably why I set this as draft 2 month ago… and I forgot to run this test last week, and made only a test with UERANSIM using the handover pull request, which worked fine. |
According to TS 38.401:
According to TS 23 501, section 5.9.9 (AMF UE NGAP ID):
One of the main purpose of this ID is to ensure a proper coordination of UE-specific procedures (e.g., session setup, handovers, UE context release) between the AMF and RAN.
While implementing N2-based handover in UERANSIM, @Sid-Romero discovered the AMF was incrementing the AMF UE NGAP ID on reception of the "Handover Required" message despite this ID being theoretically unique for a given UE.
This pull request is intended to fix this interoperability issue.
Important: when merging this PR, the test
TestN2Handoveralso needs to be updated in https://github.com/free5gc/free5gc repository by removing the following line: https://github.com/free5gc/free5gc/blob/228ac5f7b8b0c3d160bccb3470901b3e87e756c9/test/registration_test.go#L1993