Free5gc responded with "Registration reject (Protocol error, unspecified)" for "UplinkNASTransport, Security mode complete"

free5gc responded with “Registration reject (Protocol error, unspecified)” for “UplinkNASTransport, Security mode complete”.

Is this behavior correct?

UE has already context that is “070504” for amfid.
free5gc amfid is “071404”.
If amfid is the same for free5gc and UE’s context, the procedure will be successful.

AMF:192.168.45.25
RAN:192.168.45.3


Core_0202-1_amdif_071404.pcap (15.7 KB)
amfid_071404_console_log.zip (16.8 KB)

reason of “Registration reject(Protocol error, unspecified)”

I suspect that none “Registration_Request” in “NAS-PDU” caused free5gc to respond with “Registration reject (Protocol error, unspecified)”.

version

free5gc version is 3.0.6.

UE,RAN

UERANSIM is not used.
UE is Oneplus8.
I can’t answer the vendor of the RAN.(confidentiality)

Other CORE (not free5gc)

CORE simulator of RAN responded “InitialContextSetupRequest, Registration accept” for “UplinkNASTransport, Security mode complete”.
The context(amfid) of the UE is update when the UE/RAN receives “InitialContextSetupRequest, Registration accept”.

AMF:192.168.45.11
RAN:192.168.45.3

#Cause (please tell me if I’m wrong)

free5gc was unable to retrieve 5GMM data from the NAS-PDU.
free5gc returned a registration reject (Protocol error, unspecified).
(I think the cause is that I was not prepared for old amf.)

#soure code

free5gc/NFs/amf/gmm/handler.go

func HandleMobilityAndPeriodicRegistrationUpdating(ue *context.AmfUe, anType models.AccessType) error {
ue.GmmLog.Infoln(“Handle MobilityAndPeriodicRegistrationUpdating”)
amfSelf := context.AMF_Self()

    if ue.RegistrationRequest.UpdateType5GS != nil {
            if ue.RegistrationRequest.UpdateType5GS.GetNGRanRcu() == nasMessage.NGRanRadioCapabilityUpdateNeeded {
                    ue.UeRadioCapability = ""
                    ue.UeRadioCapabilityForPaging = nil
            }
    }

    // Registration with AMF re-allocation (TS 23.502 4.2.2.2.3)
    if len(ue.SubscribedNssai) == 0 {
            getSubscribedNssai(ue)
    }

    if err := handleRequestedNssai(ue, anType); err != nil {
            return err
    }

    if ue.RegistrationRequest.Capability5GMM != nil {
            ue.Capability5GMM = *ue.RegistrationRequest.Capability5GMM
    } else {
            if ue.RegistrationType5GS != nasMessage.RegistrationType5GSPeriodicRegistrationUpdating {
                    gmm_message.SendRegistrationReject(ue.RanUe[anType], nasMessage.Cause5GMMProtocolErrorUnspecified, "")
                    return fmt.Errorf("Capability5GMM is nil")
                 
            }
    }

free5gc/NFs/amf/context/amf_ue.go

    /* other */
    onGoing                       map[models.AccessType]*OnGoing
    UeRadioCapability             string // OCTET string
    Capability5GMM                nasType.Capability5GMM
    ConfigurationUpdateIndication nasType.ConfigurationUpdateIndication

#3gpp

TS 23.502 4.2.2.2.3
Registration with AMF re-allocation

Hi @yasu,

I’m not sure I get your point, please tell me if I misunderstand.

You mean UE has already recorded the old amfid as “070504”. Now UE wants to register to another AMF which is “071404”. And when doing so, the new AMF sends registration reject message due to error amfid in security mode complete.

Hi Jordan.

Thanks for the question.
Your point of view is correct.
It seems that once this UE receives “Registration reject”, it does not attach “Registration request” when sending “Security mode complete”.

I cannot determine if this is a problem specific to this UE or common behavior for all UEs. (I only have one UE…).

I confirmed that when AMF sends the “DownlinkNASTransport, Security mode command”, it is sending the “Retransmission of the initial NAS message requested” (to send a REGISTRATION REQUEST to the UE) and that the “Registration request” is sent to the UE. to have them) is 1.
So I was expecting the UE to send a “REGISTRATION REQUEST” with “UplinkNASTransport, Security mode complete”. (actually it did not).
“Retransmission of the initial NAS message requested” is optional.


After this investigation I verified with two AMFs.

AMF1’s amfid : 070504 (OLD AMF)
AMF2’s amfid : 071404 (NEW AMF)

This time the error handling part (Protocol error, unspecified) was passed.
As a result, the subsequent process failed and did not work.

However, I read the source code and determined the cause.
Later I will create a new question.