SD value in NSSAI not standard-compliant in CN SBI interfaces
Issue
According to TS 29.571 the definition of the SD value in the SNSSAI data type is as follows:
3-octet string, representing the Slice Differentiator, in
hexadecimal representation. Each character in the
string shall take a value of "0" to "9", "a" to "f" or "A"
to "F" and shall represent 4 bits. The most significant
character representing the 4 most significant bits of
the SD shall appear first in the string, and the
character representing the 4 least significant bit of
the SD shall appear last in the string.
This is an optional parameter that complements the
Slice/Service type(s) to allow to differentiate
amongst multiple Network Slices of the same
Slice/Service type. This IE shall be absent if no SD
value is associated with the SST.
Pattern: '^[A-Fa-f0-9]{6}$'
Current situation
Currently, we only support decimal values in SMF. MR !159 (merged) solves this by expecting "0x" leading the hex value, but this is not standard-compliant. Our CN components take the values configured by the user and puts them 1:1 in the SBI APIs but we should verify the values and send it standard-compliant in the API.
Solution
We should have standard-compliant SD values over the whole CN, including AMF and UPF. Additionally, NRF should verify the data in its API
Edited by Stefan Spettel