 transfer of port management information containers PCO container SM PDU DN request containers (number of packet filters, and header compression configuration); the number of packet filters co-relates to the number of filters for the signaled QoS rules Hence, Steps 1 and 2 are used to relay the UE request to establish a PDU session and the related information to ascertain the type of request and the UEs capability, and SO on. The gNB transparently relays this message to the AMF. In Step 3, the AMF selects the SMF based on DNN, NSSAI, PLMN, TAI, request type, or based on local configuration, if available. After this, the AMF sends the SMF the Nsmf_PDUSession_ CreateSMContext request; this message relays to the SMF the information gathered by the AMF. This relates to PDU session creation, SO the AMF (with information such as the request type, DNN, PDU type, etc.) requests the SMF to create a session. Based on this information, the SMF decides whether it can accept the request by fulfilling all the criteria in the request or not. For example, the SMF can reject the message if the request is for an IPv6 PDN type and the SMF/UPF only supports IPv4. In Steps 4 and 5, the SMF registers itself to be mapped to this session with the UDM as its serving SMF. The UDM determines whether the SMF is authorized to be its consumer. It also uses the same to be implicitly notified if it is deregistered in the UDM. PDU session establishment in 5G In Steps 6 and 7, the subscription data pertaining to the UE is fetched. The UDM queries the UDR (as discussed in Chapter 3, Building Blocks - Cloud Native Infrastructure) by a key such as SUPI to retrieve this information. The following list contains some of the contents of the subscription data fetched by the SMF from the UDM: Subscribed UE-AMBR, which is the aggregation ID, the UL, and DL MBRs across all non-guaranteed QoS flows Subscribed S-NSSAIs Any restriction on the RAT type Forbidden areas, if any, and service area restrictions, if any CAG information DNN list Charging characteristi