f the UE and network (i.e. the capabilities of a UE supporting Release 17 RRC can still be understood by network supporting only Release 15 RRC). The UE capabilities are typically only requested when it first registers in a network, for example, at power-up or upon return from flight mode to active usage. After the capabilities are known, they are stored in the AMF using the identity assigned to the UE at the registration. This allows the next gNB to fetch them based on the UE identity given at the RRC connection request when the NAS connection is established between the UE and the AMF. Once the capabilities are known, the network can configure the UE with the supported features. The UE capabilities involve rather simple signaling, mostly consisting of rather com- pressed bitmap-like strings whose positions indicate what the UE supports. They are encoded via ASN.1 to preserve backward and forward compatibility, and the basic prin- ciples are much the same as with LTE networks. However, because most UEs support CA with multiple bands, the amount of information can grow to be very large as many capabilities are dependent on the exact band combination. Several optimizations were done already in LTE to combat this problem, and to keep the UE capability size manage- able, the NR capabilities are requested and processed slightly differently than the LTE UE capabilities. First, the network always indicates for which frequency bands it wishes to obtain the UE capabilities: for example, assume that the UE supports CA between any two carriers from bands n77, n78, n80, and n81. This means that the UE supports a total of six CA band combinations. When requesting the UE capabilities, the network could indicate that it is only interested in the UE capabilities of bands n78 and n79, which would mean that the UE only indicates a single CA band combination between n78 and n79, thus reducing the size to 1/6th of the full capabilities. Second, heavy use of index-based referencing is used to avoid duplication of infor- mation. The s