RNTI stands for Radio Network Temporary Identifier. This is exactly same concept as LTE RNTI. So I would suggest you to read LTE RNTI part first and get the general understandings on how this works.

In short, you can think of RNTI is the CRC mask that is required to decode DCI message. Each of the DCI needs its own specific RNTI for UE to decode it. There are some common RNTI that is shared by every UE (e.g, SI-RNTI, P-RNTI etc), but most of the DCI requires a specific RNTI that is assigned to a specific UE.

• Is there any specific RNTI values for a specific UE and Specific DCI type?
• What kind of RNTI should be used ?
• What was added after the screenshots
• Reference

Is there any specific RNTI values for a specific UE  and Specific DCI type?

Some DCI uses (is masked by) a specific predefined RNTI that is common to every UE.  SI-RNTI, P-RNTI, MCCH-RNTI, PEI-RNTI belong to this category. These four have to work before the network knows the UE exists. Their values are fixed in the specification rather than assigned.

All other types of DCI uses (is masked by) a RNTI that is assigned to a specific individual UE or a specific group of UEs

<  38.321 v17.1 - Table 7.1-1: RNTI values. >

• Only a handful of values are fixed : 0000 is N/A, and FFFC to FFFF are PEI-RNTI, MCCH-RNTI, P-RNTI and SI-RNTI.
• One range holds everything that is assigned : 0001 to FFF2 covers every RNTI a network allocates, from RA-RNTI to the group and sidelink ones.
• A reserved block separates the two : the screenshot shows FFF3 to FFFB held back, which leaves room for values assigned later.
• The fixed values are the ones needed first : a UE reads system information and paging before the network has assigned it anything. SI-RNTI and P-RNTI therefore cannot be assigned.

<  38.321 v17.1 - Table 7.1-2: RNTI usage.. >

What kind of RNTI should be used ?

This is determined by the type of the DCI and Physical channel that a UE need to decode. These are well summarized by 3GPP specification as shown below.

<  38.202 v17.2 - Table 6.2-1: Downlink "Reception Types" >

Should a UE has to try all different types of RNTI listed in the table above all the time to decode necessary DCIs ? It would be OK for UE to try all the RNTI, but it would be too much overhead and energy consuming. Usually there are only a few RNTI candiates for a specific call status. What kind of candidate RNTI is likely to be used for specific RRC States are summarized in 3GPP specification as shown below.

NOTE : Since the decoding of DCI is related to various search space, the note on SearchSpace would give you further insight

<  38.202 v17.2 - Table 6.2-2: Downlink Reception Type Combinations >

• The table is organised by RRC state : RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED each get a block. The connected block is much the longest.
• Each block splits by cell role : PCell, PSCell and SCell have separate columns. What a UE monitors depends on the cell.
• Idle and inactive allow the same combination : both carry A + (B and/or (C1 or Q) and/or D0) + F0, with Note 1 attached.
• Two PDSCH at once is the stated bound : Note 1 says a UE is not required to decode more than two PDSCH simultaneously. Prioritisation beyond that is left to implementation.
• PS-RNTI is restricted twice over : Note 7 rules out monitoring it during Active time. Note 8 allows it only on the PCell and PSCell.

q : the number of downlink component carriers configured for the UE

j : the number of cell groups configured for the UE.

j=1 indicates non-DC(non-Dual Connectivity)

j=2 indicates NR-NR

What was added after the screenshots

Both tables above are screenshots, each labelled with the version it came from. The RNTI value table has moved on since, and a picture cannot show that.

The assigned range is still 0001 to FFF2, and the four fixed values are unchanged. What grew is the list of RNTI types inside that range. The current 38.321 names seven the screenshot does not, counting one rename.

One further change is easy to miss. The reserved block reads FFF3 to FFFA now, where the screenshot shows FFF3 to FFFB. One value has come out of reserve.

• The assigned range did not move : 0001 to FFF2 still holds every assigned RNTI. The new types were fitted inside it.
• The four fixed values are unchanged : FFFC is still PEI-RNTI, FFFD is MCCH-RNTI, FFFE is P-RNTI and FFFF is SI-RNTI.
• One RNTI was renamed rather than added : the screenshot reads SLCS-RNTI and the current table reads SL-CS-RNTI.
• Sidelink positioning brought two : SL-PRS-RNTI and SL-PRS-CS-RNTI are the pair DCI format 3_2 uses, one dynamic and one configured.
• Network energy saving brought two more : cellDTRX-RNTI arrived in Release 18 and adapt-SSB-PeriodicityIndication-RNTI in Release 19.
• The reserved block is one value shorter : it reads FFF3 to FFFA now rather than FFF3 to FFFB.

Reference

[1] 38.321 - 5G; NR; Medium Access Control (MAC) protocol specification. Clause 7.1 for the RNTI values and usage.

[2] 38.202 - 5G; NR; Services provided by the physical layer. Clause 6.2 for the downlink reception types.

[3] 38.331 - 5G; NR; Radio Resource Control (RRC); Protocol specification. The RNTI-Value fields that carry each assigned RNTI.