CALL FLOWS

Initial Access (RACH Procedure)

• once the UE has decided which gNB it wants to register then it initiates that process by RACH procedure

• (msg1) At the start of the initial process UE sends a preamble to gNB using PRACH (physical random access channel) .

• (msg2) then the cell responds with PDCCH and using PDCCH the cell assigns a PDSCH in the DL

• and on thisPDSCH there is the response of the cell to the preamble or random access response and in this response the cell assigns

  • A temp C-RNTI

  • A UL scheduling grant

  • Timing advance , will enable the UE to send its transmissions at a time that its UL transmission is synchronized with the UL transmissions of the other users

• (msg3) Once the UE receives this message the UE responds using the PUSCH

• In this response , the UE requests a RRC setup connection and this request will also contain the UE ID (no collision)

• (msg4) When msg3 is received by the cell , it will again use PDCCH to assign PDSCH

• In this PDSCH there will be RRC connection setup message , means RRC(radio resource connection) can now be set up

• UE then ACK it using PUCCH

• using RRC connection the UE registers itself with the cell

• For better understanding

REGISTRATION PROCEDURE

• INITIAL REGISTRATION : power on initiation

• PERIODIC REGISTRATION : to make sure device has not ran out of battery / broken

• MOBILITY REGISTRATION : if device moving to new location

• EMERGENCY REGISTRATION : where the device likes to access emergency calls

1. first step is registration request for eg(when device is turned on, mobile sends registration request to RAN)

2. RAN has to forward it to appropriate AMF but how will RAN know what is appropriate AMF

3. here there are 2 possibilities

   1. first if the device has already been communicating to the 5G network then it will have a temp ID assigned (5G-GUTI(5G global unique temporary identifier)assigned by AMF which is comprised of the GUAMI (Globally Unique AMF ID) and the 5G-TMSI (5G Temporary Mobile Subscriber Identity)., used when AMF region of UE is not known) so it can use this to see which AMF the device was previously been in communication with and RAN can forward request to corresponding AMF

1. if no previous identity available it means its the first power on procedure so RAN looks at the registration request and the registration request will have a slice identifier NSSAI , and then based on the slice identifier for this particular network slice the RAN sees which AMF supports that network slice and forwards the request to it (in case a Temp ID is not available, the NG-RAN uses the NSSAI provided by the UE at RRC connection establishment to select the appropriate AMF (the information is provided after MSG3 of the random access procedure))

1. once the request has been passed to the AMF we come to context transfer

1. for example let us assume the registration request is because of mobility so device has moved to a new region and trying to do a registration update ie. trying to connect to a new AMF but because it is mobility triggered the UE already have a UEcontext connection to old AMF

1. (2nd step)so in next step the NEW AMF contacts the OLD AMF for transferring the UE context Namf_Communication_UEcontextTransfer and the old AMF responds by transferring to the new AMF

1. (3rd step)in the next step for the to continue the authentication in carried out by 5G authentication and key agreement procedures(5G technology repo authentication procedure)

1. (4th step) in example of new AMF taking over , the new AMF will confirm to the old AMF that it has received UEcontext and now can handle Access and mobility mgmnt from now on so the old AMF can retire

1. (5th step) the new AMF will register itself to the UDM saying it is the new AMF so take care of my valid info

1. and then it speaks to the UDM to get the necessary subscription information and also subscribes for any further updates to the subscription info in the future to know subscription status of device

1. on the other hand the OLD AMF has to retire for this purpose the UDM will notify the old AMF that it needs to deregister , so the OLD AMF will unsubscribe to any subscription data that it has previously subscribed to

1. so now the transfer to new AMF is complete and OLD AMF retires

1. (6th step) next the AMF needs to know the necessary policies related to access and mobility management so it goes to the PCF and fetches the necessary policy info corresponding to the device undergoing registration and the PCF provides the corresponding response

1. (7th step) next if there is already an existing PDU session then the AMF speaks to the SMF to continue the PDU session using the UpdateSMcontext message on the other hand if there is some kind of mismatch in the understanding of what the PDU session state is then previous PDU session is terminated using the ReleaseSMcontext message and new PDU session created if necessary

1. (8th step) if the registration process is going smooth so far the AMF will notify the device that the registration has been accepted and optionally the device responds with confirmation message

1. (9th step) the AMF can contact the PCF for any device specific policies for eg device might have to decide that for a specific application if it has to create a new PDU session or not and if there are multiple wifi networks are supported which one should the device prioritize to use in support of 5G network

1. these types of policies can be fetched by the PCF if necessary

5G AKA procedure

• once the authentication procedure has been initiated then UDM has the SUPI and based on the SUPI , UDM decides whether it has to use 5G AKA procedure or EAP-AKA procedure(we are looking at AKA)

• the ARPF generates the 5G home environment authentication vector cause (AUSF and UDM are in home network)

• the expected response to the random number(XRES) is calculated using the MILENAGE FUNCTION and the input to the milenage function are sequence number , random number , Authentication management field and the master key (K)

• this milenage function has 5 subfunctions :- MAC(generates message authentication code) , XRES(response to random number) , IK , AK

• UDM derives XRES* as follows using HMAC-SHA-256 KDF function

• UDM derives K_AUSF as follows using HMAC-SHA-256(K,S) KDF(key derivation function) as below

• AUSF derives K_SEAF from K_AUSF by passing K=K_AUSF and S= 0x6C || serving network name || length of serving network name to KDF function

• this K_SEAF for the time being is stored in the AUSF

• AUSF uses the XRES* to calculate the HXRES*

• HXRES* calculation at AUSF : HXRES* is 128 bit MSB of the output of SHA-256 hash, calculated by passing RAND||XRES* as input to SHA-256 algorithm

• AUSF sends the 5G SE AV (serving environment authentication vector) to the AMF (SE cause AMF is located in the serving network of the UE)

• SEAF(AMF) stores the HXRES* and send random number (RAND) and authentication token (AUTN) to the ME (mobile equipment) which send it to USIM

• USIM verifies the AUTN and derives the RES and keys(CK,IK)

• UE uses milenage function to derive XMAC , RES , CK , IK as below

• if the XMAC and MAC are the same then it means its the genuine mobile network that this UE is connecting

• also verifies that sequence number(SQN) is in the correct range

• CK and IK are sent to ME and it calculates RES* and derive Kausf key , Kmac key , Kamf key

• then ME send RES* and MAC to the AMF(SEAF)

• SEAF(AMF) calculates the HRES* from RES* and compares it with HXRES* from the HXRES* it has already stored if they are the same it means it is good

• AUSF compares RES* with XRES* (AUSF stores XRES*) if it is the same then authentication is success

PDU SESSION ESTABLISHMENT

• (1st step) device sends the session establishment request to RAN which is forwarded to the AMF

• this request contains information like which data network this device is requesting a PDU session and what type of session type is it looking for (IP based or ethernet or unstructured) based on info like this there is one more necessary information , is this a new PDU session or a handover

  • in case of new PDU session the AMF will see what is the type of session that the device has requested , what data network is it trying to connect to , for eg if trying to connect to IMS(IP multimedia subsystem(call)) than the AMF will select an appropriate SMF to do the session handling on the other hand if it is connectivity towards internet then the AMF will select a corresponding SMF for doing the session management

• in case of session handover its not a new session so AMF can look into the device context and the context will already be associated with particular SMF so it can contact the corresponding SMF in that case

• (2nd step) the AMF contacts the SMF for creating the session management context and in addition contact the UDM to get the necessary subscription data and subscribes to further updates of the subscription data

• when the SMF agrees to the session management context creation it provides the corresponding positive acknowledgment as the response

• (3rd step) if authentication necessary that is taken care in this step

• (4th step) now SMF selects an appropriate PCF and creates a policy session so it can get the necessary PCC(The Policy and charging control rule (PCC rule) comprises the information that is required to enable the user plane detection of, the policy control and proper charging for a service data flow) rules from the PCF

• and also it selects an appropriate UPF to connect to the correct data network and creates a connectivity with the corresponding UPF

• At this point SMF selects an IP address for the device

• (5th step) at this point SMF sends an accept message towards the device together with info related to QoS and also the tunnel between the gNB and the UPF

• this message is sent via AMF which then forwards to RAN

• (6th step) at this point the QoS and tunnel info has reached the RAN which then creates connectivity towards the device and replies back to the AMF using the tunneling information at the end point of the RAN this means the setup is now complete for sending UL data from the device towards 5G network

• first UL data can now be sent

• (7th step) in this stage the AMF has previously received the RAN end of tunnel information from the RAN so it forwards this to SMF and SMF forwards to UPF

• so that the UPF know what is tunnel end point in the RAN end so it establishes connectivity from UPF to RAN

• so the UPF can forward the first DL data from data network towards device

• (8th step) now that UL and DL data in successful the AMF can go register itself to the UDM that this is the corresponding to the PDU session that was currently created

• For better understanding

DEREGISTRATION PROCEDURE

• (1st step) device forwards the deregistration request to the AMF by a RAN after receiving the request

• (2nd step) AMF starts to tear down any session related context so

• it first contacts the SMF to release the UE context associated with the ongoing PDU session

• SMF receives the request and asks the UPF to release any user plan resources related to this PDU session

• SMF forwards info back to AMF saying the user plane are now released meaning the UE context is also released

• based on this SMF also notifies the PCF that it no longer requires any policy associations that are associated with that PDU session and it also unsubscribes to the UDM that it no longer need any updates that it had previously requested from it

• SMF also deregisters with the UDM that this PDU session is no longer valid

• (3rd,4th step) the AMF notifies the PCF that the policy association related access management policies are no longer needed

• (5th step) once the PDU session is turned down and all the policy associations have been disconnected then the AMF confirms to the device the deregistration is accepted

• (6th step) AMF notifies RAN to release the Radio access related connection information