5 Encoding of UE policies
24.5263GPPRelease 17Stage 3TSUser Equipment (UE) policies for 5G System (5GS)
5.1 Overview
The content of UE policies is included in the UE policy part contents defined in annex D.6.2 of 3GPP TS 24.501 [11].
The UE policy part contents include URSP or ANDSP.
For URSP definition, the encoding is defined in clause 5.2.
For ANDSP definition, it includes encoding of WLANSP and encoding of N3AN node configuration information. The encoding of WLANSP is defined in clause 5.3.2. The encoding of N3AN node configuration information is defined in clause 5.3.3.
5.2 Encoding of UE policy part type URSP
The UE policy part type URSP contains one or more URSP rules which may be included in the UE policy part contents as defined in annex D.6.2 of 3GPP TS 24.501 [11].
If the UE policy part contents includes one or more URSP rules (i.e. the UE policy part type field is set to "URSP"), the UE policy part contents including URSP rules is encoded as shown in figures 5.2.1 to 5.2.4 and table 5.2.1.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
URSP rule 1 |
octet q+3 octet s |
|||||||
URSP rule 2 |
octet s+1* octet t* |
|||||||
… |
octet t+1* octet u* |
|||||||
URSP rule n |
octet u+1* octet r* |
Figure 5.2.1: UE policy part contents including one or more URSP rules
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of URSP rule |
octet v octet v+1 |
|||||||
Precedence value of URSP rule |
octet v+2 |
|||||||
Length of traffic descriptor |
octet v+3 octet v+4 |
|||||||
Traffic descriptor |
octet v+5 octet w |
|||||||
Length of route selection descriptor list |
octet w+1 octet w+2 |
|||||||
Route selection descriptor list |
octet w+3 octet x |
Figure 5.2.2: URSP rule
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Route selection descriptor 1 |
octet w+3 octet y |
|||||||
Route selection descriptor 2 |
octet y+1* octet z* |
|||||||
… |
octet z+1* octet a* |
|||||||
Route selection descriptor m |
octet a+1* octet x* |
Figure 5.2.3: Route selection descriptor list
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of route selection descriptor |
octet b octet b+1 |
|||||||
Precedence value of route selection descriptor |
octet b+2 |
|||||||
Length of route selection descriptor contents |
octet b+3 octet b+4 |
|||||||
Route selection descriptor contents |
octet b+5 octet c |
Figure 5.2.4: Route selection descriptor
Table 5.2.1: UE policy part contents including a URSP rule
Precedence value of URSP rule (octet v+2) The precedence value of URSP rule field is used to specify the precedence of the URSP rule among all URSP rules in the URSP. This field includes the binary encoded value of the precedence value in the range from 0 to 255 (decimal). The higher the value of the precedence value field, the lower the precedence of the URP rule is. Multiple URSP rules in the URSP shall not have the same precedence value. |
||
Traffic descriptor (octets v+5 to w) The traffic descriptor field is of variable size and contains a variable number (at least one) of traffic descriptor components. Each traffic descriptor component shall be encoded as a sequence of one octet traffic descriptor component type identifier and a traffic descriptor component value field. The traffic descriptor component type identifier shall be transmitted first. |
||
Traffic descriptor component type identifier Bits 0 0 0 0 0 0 0 1 Match-all type 1 0 0 0 0 0 0 1 Destination MAC address type 1 0 0 0 1 0 0 0 DNN type (NOTE 3) 1 0 0 1 0 0 1 0 Regular expression 1 0 1 0 0 0 0 1 Destination MAC address range type |
||
For "match-all type", the traffic descriptor component shall not include the traffic descriptor component value field. The "match-all type" traffic descriptor component shall not appear more than once among all traffic descriptors of the whole URSP rules in the URSP. If the "match-all type" traffic descriptor component is included in a traffic descriptor, there shall be no traffic descriptor component with a type other than "match-all type" in the traffic descriptor. |
||
For "OS Id + OS App Id type", the traffic descriptor component value field shall be encoded as a sequence of a sixteen octet OS Id field, a one octet OS App Id length field, and an OS App Id field. The OS Id field shall be transmitted first. The OS Id field contains a Universally Unique IDentifier (UUID) as specified in IETF RFC 4122 [16]. |
||
For "IPv4 remote address type", the traffic descriptor component value field shall be encoded as a sequence of a four octet IPv4 address field and a four octet IPv4 address mask field. The IPv4 address field shall be transmitted first. |
||
For "IPv6 remote address/prefix length type", the traffic descriptor component value field shall be encoded as a sequence of a sixteen octet IPv6 address field and one octet prefix length field. The IPv6 address field shall be transmitted first. |
||
For "protocol identifier/next header type", the traffic descriptor component value field shall be encoded as one octet which specifies the IPv4 protocol identifier or IPv6 next header. |
||
For "single remote port type", the traffic descriptor component value field shall be encoded as two octets which specify a port number. |
||
For "remote port range type", the traffic descriptor component value field shall be encoded as a sequence of a two octet port range low limit field and a two octet port range high limit field. The port range low limit field shall be transmitted first. |
||
For "IP 3 tuple type", the traffic descriptor component value field shall be encoded as a sequence of a one octet IP 3 tuple information bitmap field where: – bit 1 set to zero indicates that the IPv4 address field is absent; – bit 1 set to one indicates that the IPv4 address field is present; – bit 2 set to zero indicates that the IPv6 remote address/prefix length field is absent; – bit 2 set to one indicates that the IPv6 remote address/prefix length field is present; – bit 3 set to zero indicates that the protocol identifier/next header field is absent; – bit 3 set to one indicates that the protocol identifier/next header field is present; – bit 4 set to zero indicates that the single remote port field is absent; – bit 4 set to one indicates that the single remote port field is present; – bit 5 set to zero indicates that the remote port range field is absent; – bit 5 set to one indicates that the remote port range field is present; and – bits 6,7, and 8 are spare bits; followed by a four octet IPv4 address field and a four octet IPv4 address mask field, if the IPv4 address field is present; followed by a sixteen octet IPv6 address field and one octet prefix length field, if the IPv6 remote address/prefix length field is present; followed by one octet which specifies the IPv4 protocol identifier or IPv6 next header, if the protocol identifier/next header field is present; followed by two octets which specify a port number, if the single remote port field is present; followed by a two octet port range low limit field and a two octet port range high limit field, if the remote port range field is present. The IP 3 tuple information bitmap field shall be transmitted first. The traffic descriptor component value field shall not contain both the IPv4 address field and the IPv6 remote address/prefix length field. If the traffic descriptor component value field contains both the IPv4 address field and the IPv6 remote address/prefix length field, the receiving entity shall ignore the URSP rule. The traffic descriptor component value field shall not contain both the single remote port field and the remote port range field. If the traffic descriptor component value field contains both the single remote port field and the remote port range field, the receiving entity shall ignore the URSP rule. The traffic descriptor component value field shall contain at least one of the IPv4 address field, IPv6 remote address/prefix length field, the protocol identifier/next header field, the single remote port field and the remote port range field, otherwise the receiving entity shall ignore the URSP rule. |
||
For "security parameter index type", the traffic descriptor component value field shall be encoded as four octets which specify the IPsec security parameter index. |
||
For "type of service/traffic class type", the traffic descriptor component value field shall be encoded as a sequence of a one octet type-of-service/traffic class field and a one octet type-of-service/traffic class mask field. The type-of-service/traffic class field shall be transmitted first. |
||
For "flow label type", the traffic descriptor component value field shall be encoded as three octets which specify the IPv6 flow label. The bits 8 through 5 of the first octet shall be spare whereas the remaining 20 bits shall contain the IPv6 flow label. |
||
For "destination MAC address type", the traffic descriptor component value field shall be encoded as 6 octets which specify a MAC address. |
||
For "802.1Q C-TAG VID type", the traffic descriptor component value field shall be encoded as two octets which specify the VID of the customer-VLAN tag (C-TAG) as specified in IEEE Std 802.1Q-2018 [20]. The bits 8 through 5 of the first octet shall be spare whereas the remaining 12 bits shall contain the VID. |
||
For "802.1Q S-TAG VID type", the traffic descriptor component value field shall be encoded as two octets which specify the VID of the service-VLAN tag (S-TAG) as specified in IEEE Std 802.1Q-2018 [20]. The bits 8 through 5 of the first octet shall be spare whereas the remaining 12 bits shall contain the VID. |
||
For "802.1Q C-TAG PCP/DEI type", the traffic descriptor component value field shall be encoded as one octet which specifies the 802.1Q C-TAG PCP and DEI as specified in IEEE Std 802.1Q-2018 [20]. The bits 8 through 5 of the octet shall be spare, and the bits 4 through 2 contain the PCP and bit 1 contains the DEI. |
||
For "802.1Q S-TAG PCP/DEI type", the traffic descriptor component value field shall be encoded as one octet which specifies the 802.1Q S-TAG PCP as specified in IEEE Std 802.1Q-2018 [20]. The bits 8 through 5 of the octet shall be spare, and the bits 4 through 2 contain the PCP and bit 1 contains the DEI. |
||
For "ethertype type", the traffic descriptor component value field shall be encoded as two octets which specify an ethertype. |
||
For "DNN type", the traffic descriptor component value field shall be encoded as a sequence of a one octet DNN length field and a DNN value field of a variable size. The DNN value contains an APN as defined in 3GPP TS 23.003 [4]. |
||
For "connection capabilities" type, the traffic descriptor component value field shall be encoded as a sequence of one octet for number of network capabilities followed by one or more octets, each containing a connection capability identifier encoded as follows: Bits 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 IMS 0 0 0 0 0 0 1 0 MMS 0 0 0 0 0 1 0 0 SUPL 0 0 0 0 1 0 0 0 Internet All other values are spare. If received they shall be interpreted as unknown. |
||
For "destination FQDN" type, the traffic descriptor component value field shall be encoded as a sequence of one octet destination FQDN length field and a destination FQDN value of variable size. The destination FQDN value field shall be encoded as defined in clause 28.3.2.1 in 3GPP TS 23.003 [4]. For "regular expression" type, the traffic descriptor component value field shall be encoded as a sequence of one octet regular expression length field and a regular expression value of variable size. The regular expression value field shall take the form of Extended Regular Expressions (ERE) as defined in chapter 9 in IEEE 1003.1-2004 Part 1 [19]. |
||
For "OS App Id type", the traffic descriptor component value field shall be encoded as a one octet OS App Id length field and an OS App Id field. |
||
Precedence value of route selection descriptor (octet b+2) The precedence value of route selection descriptor field is used to specify the precedence of the route selection descriptor among all route selection descriptors in the URSP rule. This field includes the binary encoded value of the precedence value in the range from 0 to 255 (decimal). The higher the value of the precedence value field, the lower the precedence of the route selection descriptor is. |
||
For "destination MAC address range type", the traffic descriptor component value field shall be encoded as a sequence of a 6 octet destination MAC address range low limit field and a 6 octet destination MAC address range high limit field. The destination MAC address range low limit field shall be transmitted first. Route selection descriptor contents (octets b+5 to c) The route selection descriptor contents field is of variable size and contains a variable number (at least one) of route selection descriptor components. Each route selection descriptor component shall be encoded as a sequence of a one octet route selection descriptor component type identifier and a route selection descriptor component value field. The route selection descriptor component type identifier shall be transmitted first. |
||
Route selection descriptor component type identifier Bits 0 0 0 0 0 0 0 1 SSC mode type 1 0 0 0 0 0 1 0 PDU session pair ID type (NOTE 5) 1 0 0 0 0 0 1 1 RSN type (NOTE 5) |
||
For "SSC mode type", the route selection descriptor component value field shall be encoded as a one octet SSC mode field. The bits 8 through 4 of the octet shall be spare, and the bits 3 through 1 shall be encoded as the value part of the SSC mode information element defined in clause 9.11.4.16 of 3GPP TS 24.501 [11]. The "SSC mode type" route selection descriptor component shall not appear more than once in the route selection descriptor. |
||
For "S-NSSAI type", the route selection descriptor component value field shall be encoded as a sequence of a one octet S-NSSAI length field and an S-NSSAI value field of a variable size. The S-NSSAI value shall be encoded as the value part of the S-NSSAI information element defined in clause 9.11.2.8 of 3GPP TS 24.501 [11]. |
||
For "DNN type", the route selection descriptor component value field shall be encoded as a sequence of a one octet DNN length field and a DNN value field of a variable size. The DNN value contains an APN as defined in 3GPP TS 23.003 [4]. |
||
For "PDU session type type", the route selection descriptor component value field shall be encoded as a one octet PDU session type field. The bits 8 through 4 of the octet shall be spare, and the bits 3 through 1 shall be encoded as the value part of the PDU session type information element defined in clause 9.11.4.11 of 3GPP TS 24.501 [11]. The "PDU session type type" route selection descriptor component shall not appear more than once in the route selection descriptor. |
||
For "preferred access type type", the route selection descriptor component value field shall be encoded as a one octet preferred access type field. The bits 8 through 3 shall be spare, and the bits 2 and 1 shall be encoded as the value part of the access type information element defined in clause 9.11.2.1A of 3GPP TS 24.501 [11]. The "preferred access type type" route selection descriptor component shall not appear more than once in the route selection descriptor. |
||
For "multi-access preference type", the route selection descriptor component value field shall be of zero length. The "multi-access preference type" route selection descriptor component shall not appear more than once in the route selection descriptor. The "multi-access preference type" route selection descriptor component in the route selection descriptor indicates the multi-access preference. |
||
For "non-seamless non-3GPP offload indication type", the route selection descriptor component shall not include the route selection descriptor component value field. The "non-seamless non-3GPP offload indication type" route selection descriptor component shall not appear more than once in the route selection descriptor. If the "non-seamless non-3GPP offload indication type" route selection descriptor component is included in a route selection descriptor, there shall be no route selection descriptor component with a type other than "non-seamless non-3GPP offload indication type" in the route selection descriptor. |
||
For "location criteria type", the route selection descriptor component value field may contain one or more types of location area and is encoded as shown in Figure 5.2.5 and Table 5.2.2. |
||
For "time window type", the route selection descriptor component value field shall be encoded as a sequence of a Starttime field and a Stoptime field. The Starttime field is represented by the number of seconds since 00:00:00 on 1 January 1970 and is encoded as the 64-bit NTP timestamp format defined in IETF RFC 5905 [17], where binary encoding of the integer part is in the first 32 bits and binary encoding of the fraction part in the last 32 bits. The encoding of the Stoptime field is the same as the Starttime field. |
||
For "5G ProSe layer-3 UE-to-network relay offload indication type", the route selection descriptor component shall not include the route selection descriptor component value field. The "5G ProSe layer-3 UE-to-network relay offload indication type" route selection descriptor component shall not appear more than once in the route selection descriptor. If the "5G ProSe layer-3 UE-to-network relay offload indication type" route selection descriptor component is included in a route selection descriptor, there shall be no route selection descriptor component with a type other than "5G ProSe layer-3 UE-to-network relay offload indication type" in the route selection descriptor. If "5G ProSe layer-3 UE-to-network relay offload indication type" is not present the traffic shall not be routed via a 5G ProSe layer-3 UE-to-network relay outside of a PDU Session. |
||
For "PDU session pair ID type", the route selection descriptor component value field shall be encoded as a one octet PDU session pair ID field. The PDU session pair ID value shall be encoded as defined in clause 9.11.4.y of 3GPP TS 24.501 [11]. |
||
For "RSN type", the route selection descriptor component value field shall be encoded as a one octet RSN field. The RSN value shall be encoded as the value part of the RSN information element defined in clause 9.11.4.x of 3GPP TS 24.501 [11]. |
||
NOTE 1: For "OS Id + OS App Id type", the traffic descriptor component value field does not specify the OS version number or the version number of the application. NOTE 2: The PCF does not include both the "preferred access type type" and the "multi-access preference type" route selection descriptor components in a single route selection descriptor. If there are both "preferred access type type" and "multi-access preference type" route selection descriptor components in a single route selection descriptor, the UE ignores the "preferred access type type" route selection descriptor component. NOTE 3: The W-AGF acting on behalf of the FN-RG shall interpret the value as unknown. NOTE 4: The traffic descriptor of a URSP rule cannot include more than one instance of this traffic component type. NOTE 5: Redundant PDU session is not applicable over non-3GPP access. The UE ignores any route selection descriptor which includes "PDU session pair ID type" or "RSN type" route selection descriptor component and also includes a "preferred access type type" route selection descriptor component set to "non-3GPP access" or a "multi-access preference type" route selection descriptor component. |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of location criteria Location area 1 |
octet d octet e=(d+1) octet f |
|||||||
Location area 2 |
octet f+1* octet g* |
|||||||
… |
octet g+1* octet h* |
|||||||
Location area m |
octet h+1* octet i* |
Figure 5.2.5: Location criteria
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Type of location area |
octet e |
|||||||
Location area contents |
octet e+1* octet f* |
Figure 5.2.6: Location area
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Number of E-UTRA cell identities |
octet e+1 |
|||||||
E-UTRA cell id 1 |
octet e+2 octet e+8 |
|||||||
E-UTRA cell id 2 |
octet e+9 octet e+15 |
|||||||
… |
octet e+16 octet j-1* |
|||||||
E-UTRA cell id n |
octet j* octet f=(j+6)* |
Figure 5.2.7: Location area contents {Type of location area = E-UTRA cell identities list}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Number of NR cell identities |
octet e+1 |
|||||||
NR cell id 1 |
octet e+2 octet e+9 |
|||||||
NR cell id 2 |
octet e+10 octet e+17 |
|||||||
… |
octet e+18 octet k-1* |
|||||||
NR cell id n |
octet k* octet f=(k+7)* |
Figure 5.2.8: Location area contents {Type of location area = NR cell identities list}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Number of Global gNB identities |
octet e+1 |
|||||||
Global gNB id 1 |
octet e+2 octet e+8 |
|||||||
Global gNB id 2 |
octet e+9 octet e+15 |
|||||||
… |
octet e+16 octet l-1* |
|||||||
Global gNB id n |
octet l* octet f=(l+6)* |
Figure 5.2.9: Location area contents {Type of location area = Global RAN node identities list}
Table 5.2.2: Location criteria
Length of location criteria (octect d) This field indicates the length of the included Location criteria contents. Type of location area is coded as follows. |
|||||||||
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
E-UTRA cell identities list |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
NR cell identities list |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
Global RAN node identities list |
|
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
TAI list |
|
All other values are spare. |
|||||||||
When the type of location area is "E-UTRA cell identities list", the location area contents shall be encoded as in Figure 5.2.7. Each E-UTRA cell id field is of 7 octet size and shall be encoded as specified in clause 9.3.1.9 of 3GPP TS 38.413 [14]. |
|||||||||
When the type of location area is "NR cell identities list", the location area contents shall be encoded as in Figure 5.2.8. Each NR cell id field is of 8 octet size shall be encoded as specified in clause 9.3.1.7 of 3GPP TS 38.413 [14]. |
|||||||||
When the type of location area is "Global RAN node identities list", the location area contents shall be encoded as in Figure 5.2.8. Each Global gNB id field is of 7 octet size shall be encoded as specified in clause 9.3.1.6 of 3GPP TS 38.413 [14]. |
|||||||||
When the type of location area is "TAI list", the location area contents shall be encoded as the 5GS tracking area identity list information element (starting with octet 2) defined in clause 9.11.3.9 of 3GPP TS 24.501 [11]. |
|||||||||
5.3 Encoding of UE policy part type ANDSP
5.3.1 General
The purpose of the ANDSP is to indicate the WLAN Selection Policy (WLANSP) and non-3GPP access network (N3AN) node configuration information related to access network discovery and selection and N3AN node selection for non-3GPP access network.
The ANDSP is encoded as shown in figures 5.3.1.1 to 5.3.1.3 and table 5.3.1.1 according to UE policy part top level format (see Annex D of 3GPP TS 24.501 [11]).
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
UE policy part contents length |
octet 1 octet 2 |
|||||||
0 |
0 |
0 |
0 |
UE policy part type={ANDSP} |
octet 3 |
|||
Spare |
||||||||
UE policy part contents={ANDSP contents} |
octet 4 octet x |
Figure 5.3.1.1: UE policy part when UE policy part type = {ANDSP}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
ANDSP info #1 |
octet 4 octet a |
|||||||
ANDSP info #2 |
octet a+1 octet b |
|||||||
… |
octet b+1 octet w |
|||||||
ANDSP info #n |
octet w+1 octet x |
Figure 5.3.1.2: ANDSP contents
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
0 |
0 |
0 |
0 |
ANDSP Info type |
octet k |
|||
Spare |
||||||||
Length of ANDSP info contents |
octet k+1 octet k+2 |
|||||||
ANDSP info contents |
octet k+3 octet l |
Figure 5.3.1.3: ANDSP Info
Table 5.3.1.1: ANDSP information format
UE policy part type field is set to ‘00000010’ (=ANDSP) as specified in 3GPP TS 24.501 [4] Annex D. |
|||||
UE policy part contents length field indicate the length of the ANDSP contents in octets. |
|||||
ANDSP contents (octets 4 to x) |
|||||
ANDSP contents consist of 1 or more ANDSP info (see figure 5.3.1.2). |
|||||
ANDSP Info type (bit 1 to 4 of octet k) shall be set according to the following: |
|||||
Bits |
|||||
4 |
3 |
2 |
1 |
||
0 |
0 |
0 |
0 |
Reserved |
|
0 |
0 |
0 |
1 |
WLANSP |
|
0 |
0 |
1 |
0 |
N3AN node configuration information |
|
All other values are reserved. |
|||||
Bits 8 to 5 of octet k are spare and shall be encoded as zero. |
|||||
Length of ANDSP info contents (octets k+1 to k+2) indicates the length of the ANDSP info contents field. |
|||||
ANDSP info contents (octets k+3 to l) can be WLANSP (see clause 5.3.2) or N3AN node configuration information (see clause 5.3.3). |
5.3.2 Encoding of WLANSP
The purpose of the WLANSP field is to indicate the rules related to selection and reselection of a WLAN.
The WLANSP field is encoded as shown in figures 5.3.2.1 to 5.3.2.20 and table 5.3.2.1.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
0 |
0 |
0 |
0 |
ANDSP Info type={WLANSP} |
octet 1 |
|||
Spare |
||||||||
Length of ANDSP info contents |
octet 2 octet 3 |
|||||||
ANDSP info contents={WLANSP contents } |
octet 4 octet x |
Figure 5.3.2.1: ANDSP Info = {WLANSP}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
WLANSP rule 1 |
octet 4 octet u |
|||||||
WLANSP rule 2 |
octet u+1* octet v* |
|||||||
… |
octet v+1* octet w* |
|||||||
WLANSP rule n |
octet w+1* octet x* |
Figure 5.3.2.2: WLANSP contents
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of WLANSP rule |
octet 4 octet 5 |
|||||||
Rule identifier |
octet 6 |
|||||||
Rule priority |
octet 7 |
|||||||
Roaming |
validity area ind |
3GPP loc ind |
WLAN loc ind |
Geo loc ind |
time of day ind |
0 spare |
0 spare |
octet 8 |
Selection criteria |
octet 9 octet r |
|||||||
Validity area |
octet r+1* octet s* |
|||||||
Time of day |
octet s+1* octet u* |
Figure 5.3.2.3: WLANSP rule
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of selection criteria |
octet 9 octet 10 |
|||||||
number of selection criteria entries |
octet 11 |
|||||||
Selection criteria entry 1 |
octet 12 octet a |
|||||||
Selection criteria entry 2 |
octet a+1* octet b* |
|||||||
… |
octet b+1* octet c* |
|||||||
Selection criteria entry n |
octet c+1* octet r* |
Figure 5.3.2.4: Selection criteria
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||||
Length of selection criteria entry |
octet 12 octet 13 |
||||||||||
Spare |
MaxBSSload ind |
Home network ind |
Criteria priority |
octet 14 |
|||||||
Maximum BSS load value |
octet 15 octet 16 |
||||||||||
Selection criteria set 1 |
octet 17 octet t* |
||||||||||
… |
octet t+1* octet y* |
||||||||||
Selection criteria set n (n <= 5) |
octet y+1* octet a* |
Figure 5.3.2.4a: Selection criteria entry
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
Length of selection criteria set |
octet 17 octet 18 |
||||||||
Selection criteria set type {preferred SSID list, preferred roaming partner list, required protocol port tuple, SP exclusion list, minimum backhaul threshold} |
Number of sub entries |
octet 19 |
|||||||
Sub entry 1 |
octet 20 octet aa |
||||||||
… |
octet aa+1 octet bb |
||||||||
Sub entry n |
octet cc+1 octet dd |
Figure 5.3.2.4b: Selection criteria set
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
Length of sub entry {set type = preferred SSID list} |
octet 20 |
|||||||||
WLAN priority |
octet 21 |
|||||||||
0 Spare |
HESSID ind |
SSID ind |
octet 22 |
|||||||
SSID length |
octet 23* |
|||||||||
SSID |
octet 24* octet ee* |
|||||||||
HESSID |
octet ee+1* octet ee+6* |
Figure 5.3.2.4c: Selection criteria sub entry {selection criteria set type = preferred SSID list}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of sub entry {set type = preferred roaming partner list} |
octet 20 |
|||||||
Priority |
octet 21 |
|||||||
FQDN_Match length |
octet 22 |
|||||||
FQDN_Match |
octet 23 octet ee* |
|||||||
Country length |
octet ee+1 |
|||||||
Country |
octet ee+2 octet ff* |
Figure 5.3.2.4d: Selection criteria sub entry {selection criteria set type = preferred roaming partner list}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of sub entry {set type = required protocol port tuple} |
octet 20 |
|||||||
IP protocol |
octet 21 |
|||||||
Length of port number |
octet 22 |
|||||||
Port number |
octet 23 octet ff |
Figure 5.3.2.4e: Selection criteria sub entry {selection criteria set type = required protocol port tuple}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of sub entry {set type = SP exclusion list} |
octet 20 |
|||||||
SSID |
octet 21 octet ff* |
Figure 5.3.2.4f: Selection criteria sub entry {selection criteria set type = SP exclusion list}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||||
Spare |
ULBI |
DLBI |
Network type |
octet 20 |
|||||||
Downlink bandwidth |
octet 21 octet 24 |
||||||||||
Uplink bandwidth |
octet 25 octet 28 |
Figure 5.3.2.4g: Selection criteria sub entry {selection criteria set type = minimum backhaul threshold}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
length of validity area |
octet r+1 octet r+2 |
|||||||
number of location entries |
octet r+3 |
|||||||
location entry 1 |
octet r+4 octet d |
|||||||
…. |
octet d+1* octet e* |
|||||||
location entry m |
octet e+1* octet s* |
Figure 5.3.2.5: Validity area
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of location entry |
octet r+4* octet r+5* |
|||||||
entry type {3GPP, WLAN, Geo} |
number of sub entries |
octet r+6* |
||||||
sub entry contents |
octet r+7* octet d* |
Figure 5.3.2.6: Location entry
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of location entry |
octet r+4* octet r+5* |
|||||||
entry type= {3GPP location} |
number of sub entries |
octet r+6* |
||||||
3GPP location sub entry 1 |
octet r+7 octet f |
|||||||
3GPP location sub entry 2 |
octet f+1* octet g* |
|||||||
… |
octet g+1* octet h* |
|||||||
3GPP location sub entry o |
octet h+1* octet d* |
Figure 5.3.2.7: Location entry {entry type =3GPP location}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of location entry |
octet r+4* octet r+5* |
|||||||
entry type= {WLAN location } |
number of sub entries |
octet r+6* |
||||||
WLAN location sub entry 1 |
octet r+7 octet f |
|||||||
WLAN location sub entry 2 |
octet f+1* octet g* |
|||||||
… |
octet g+1* octet h* |
|||||||
WLAN location sub entry p |
octet h+1* octet d* |
Figure 5.3.2.8: Location entry {entry type =WLAN location}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of location entry |
octet r+4* octet r+5* |
|||||||
entry type= {Geo location } |
number of sub entries |
octet r+6* |
||||||
Geo location sub entry 1 |
octet r+7 octet f |
|||||||
Geo location sub entry 2 |
octet f+1* octet g* |
|||||||
… |
octet g+1* octet h* |
|||||||
Geo location sub entry q |
octet h+1* octet d* |
Figure 5.3.2.9: Location entry {entry type =Geo location}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of 3GPP location sub entry |
octet r+7 octet r+8 |
|||||||
MCC digit 2 |
MCC digit 1 |
octet r+9 |
||||||
MNC digit 3 |
MCC digit 3 |
octet r+10 |
||||||
MNC digit 2 |
MNC digit 1 |
octet r+11 |
||||||
number of location fields |
octet r+12* |
|||||||
3GPP location field 1 |
octet r+13* octet l* |
|||||||
… |
octet l+1* octet m* |
|||||||
3GPP location field n |
octet m+1* octet f* |
Figure 5.3.2.10: Location sub entry {entry type= 3GPP location}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of location sub entry |
octet r+7 octet r+8 |
|||||||
number of location fields |
octet r+9* |
|||||||
WLAN or Geo location field 1 |
octet r+10* octet l* |
|||||||
… |
octet l+1* octet m* |
|||||||
WLAN or Geo location field n |
octet m+1* octet f* |
Figure 5.3.2.10a: Location sub entry {entry type= WLAN location or Geo location}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Anchor latitude |
octet r+10* octet r+13* |
|||||||
Anchor longitude |
octet r+14* octet r+17* |
|||||||
Radius |
octet r+18* octet r+19* |
Figure 5.3.2.11a: Location field {entry type= Geo location}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of 3GPP location field |
octet r+13* |
|||||||
3GPP location field type |
octet r+14 |
|||||||
3GPP location field contents |
octet r+15* octet l* |
Figure 5.3.2.11b: Location field {entry type= 3GPP location}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of WLAN location field |
octet r+10 |
|||||||
WLAN location field type |
octet r+11 |
|||||||
WLAN location field contents |
octet r+12* octet l* |
Figure 5.3.2.11c: Location field {entry type= WLAN location}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of 3GPP location field |
octet r+13* |
|||||||
field type = {TAC} |
octet r+14 |
|||||||
TAC |
octet r+15 |
Figure 5.3.2.12: 3GPP location field {field type = TAC}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of 3GPP location field |
octet r+13* |
|||||||
field type = {EUTRA CI} |
octet r+14 |
|||||||
EUTRA CI |
octet r+15 octet r+16 |
Figure 5.3.2.13: 3GPP location field {field type = EUTRA CI}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of 3GPP location field |
octet r+13* |
|||||||
field type = {NR CI} |
octet r+14 |
|||||||
NR CI |
octet r+15 octet r+17 |
Figure 5.3.2.14: 3GPP location field {field type = NR CI}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of WLAN location field |
octet r+10* |
|||||||
field type = {HESSID} |
octet r+11 |
|||||||
HESSID |
octet r+12 octet r+17 |
Figure 5.3.2.14a: WLAN location field {field type = HESSID}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of WLAN location field |
octet r+10* |
|||||||
field type = {SSID} |
octet r+11 |
|||||||
SSID |
octet r+12 octet l* |
Figure 5.3.2.14b: WLAN location field {field type = SSID}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of WLAN location field |
octet r+10* |
|||||||
field type = {BSSID} |
octet r+11 |
|||||||
BSSID |
octet r+12 octet r+17 |
Figure 5.3.2.14c: WLAN location field {field type = BSSID}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of time of day |
octet s+1 octet s+2 |
|||||||
number of time of day entries |
octet s+3 |
|||||||
Time of day entry 1 |
octet s+4 octet n1 |
|||||||
Time of day entry 2 |
octet n1+1* octet n2* |
|||||||
… |
octet n2+1* octet n3* |
|||||||
Time of day entry n |
octet n3+1* octet u* |
Figure 5.3.2.15: Time of day
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of time of day entry |
octet s+4 octet s+5 |
|||||||
number of sub fields |
octet s+6* |
|||||||
ToD sub field 1 |
octet s+7 octet z1 |
|||||||
ToD sub field 2 |
octet z1+1* octet z2* |
|||||||
… |
octet z2+1* octet z3* |
|||||||
ToD sub field y |
octet z3+1* octet n1* |
Figure 5.3.2.16: Time of day sub field
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of ToD sub field |
octet s+7* |
|||||||
ToD sub field type |
octet s+8* |
|||||||
ToD sub field contents |
octet s+9 octet f |
Figure 5.3.2.17: ToD sub field
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of ToD sub field |
octet s+7* |
|||||||
ToD sub field type ={time start, time stop} |
octet s+8* |
|||||||
ToD sub field contents |
octet s+9 octet f |
Figure 5.3.2.18: ToD sub field {field type = "time start" or "time stop"}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of ToD sub field |
octet s+7* |
|||||||
ToD sub field type ={ date start, date stop } |
octet s+8* |
|||||||
ToD sub field contents |
octet s+9 octet f |
Figure 5.3.2.19: ToD sub field {field type = "date start" or "date stop"}
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of ToD sub field |
octet s+7* |
|||||||
ToD sub field type ={ day of week} |
octet s+8* |
|||||||
1 |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
Sun |
octet s+9 |
Figure 5.3.2.20: ToD sub field {field type = "day of the week"}
Table 5.3.2.1: WLANSP information element
Value part of the WLANSP information element (octets 4 to x) |
|||||||||||||||
ANDSP Info type (bit 1 to 4 of octet 1) shall be set to "0001" (WLANSP) |
|||||||||||||||
Bits 8 to 5 of octet 1 are spare and shall be encoded as zero. |
|||||||||||||||
Length of WLANSP contents (octets 2 to 3) |
|||||||||||||||
Length of WLANSP rule (octets 4 to 5) |
|||||||||||||||
Rule Identifier (octet 6) |
|||||||||||||||
This field contains the binary encoding of the WLANSP rule identifier |
|||||||||||||||
Rule priority (octet 7) |
|||||||||||||||
This field contains the binary encoding of the WLANSP rule priority |
|||||||||||||||
Spare bits and shall be encoded as zero (bits 1 to 2 of octet 8) |
|||||||||||||||
Time of day index (bit 3 of octet 8) |
|||||||||||||||
Bit |
|||||||||||||||
|
|||||||||||||||
Geo location index (bit 4 of octet 8) |
|||||||||||||||
Bit |
|||||||||||||||
|
|||||||||||||||
WLAN location index (bit 5 of octet 8) |
|||||||||||||||
Bit |
|||||||||||||||
|
|||||||||||||||
3GPP location index (bit 6 of octet 8) |
|||||||||||||||
Bit |
|||||||||||||||
|
|||||||||||||||
Validity area index (bit 7 of octet 8) |
|||||||||||||||
Bit |
|||||||||||||||
|
|||||||||||||||
Roaming (bit 8 of octet 8) (NOTE 1) |
|||||||||||||||
Bit |
|||||||||||||||
8 |
|||||||||||||||
0 |
WLANSP rule is only valid when the UE is not roaming |
||||||||||||||
1 |
WLANSP rule is only valid when the UE is roaming |
||||||||||||||
Selection criteria (octets 9 to r) |
|||||||||||||||
This field contains the binary encoding of the selection criteria for a particular WLANSP rule. |
|||||||||||||||
Selection criteria entry (octets 12 to a) (NOTE 2) Length of selection criteria entry (octets 12 to 13) indicates length of subsequent fields in the selection criteria entry. Criteria priority (bits 1-5 of octet 14): the lower value indicates the selection criteria having the higher priority among the selection criteria in the WLANSP rule. Home network ind (bit 6 of octet 14): (NOTE 3) Bit 6 0 all WLANs could match this selection criteria entry. 1 only the WLANs that are operated by the home operator could match this selection criteria entry. MaxBSSload ind (bit 7 of octet 14): Bit 7 0 maximum BSS load value (octets 15 to 16) not present 1 maximum BSS load value (octets 15 to 16) present Maximum BSS load value (octets 15 to 16) is as the node PerProviderSubscription/<X+>/Policy/MaximumBSSLoadValue defined in Hotspot 2.0 (Release 2) Technical Specification [9]. |
|||||||||||||||
Selection criteria set (octets 17 to dd) contains the contents of a specific criteria set. In this release of specification there can be 5 types of criteria sets. Selection criteria set type (bits 5-8 of octet 19) is coded as follows. Bits 8 7 6 5 0 0 0 1 preferred SSID list (NOTE 4) 0 0 1 0 preferred roaming partner list (NOTE 5) 0 0 1 1 required protocol port tuple 0 1 0 0 SP exclusion list 0 1 0 1 minimum backhaul threshold All other values are reserved. |
|||||||||||||||
Selection criteria sub entry (octets 20 to ee+6) when set type is "preferred SSID list" is coded as follows. Length of sub entry (octet 20) indicates length of subsequent fields in the selection criteria sub entry. WLAN priority (octet 21): the lower WLAN priority value indicates the WLAN having the higher priority among the WLANs in the preferred SSID list. SSID ind (bit 1 of octet 22): Bit 5 0 SSID field (octets 24 to ee) is not present. 1 SSID field (octets 24 to ee) is present. HESSID ind (bit 2 of octet 22): Bit 6 0 HESSID field (octets ee+1 to ee+6) is not present. 1 HESSID field (octet ee+1 to ee+6) is present. SSID length (octet 23) indicates the length of the SSID field. SSID field (octets 24 to ee) is an Octet String which shall have a maximum length of 32 octets (see IEEE Std 802.11 [8]). HESSID field (octets ee+1 to ee+6) is a 6 octet MAC address that identifies the homogeneous ESS (see IEEE Std 802.11 [8]). |
|||||||||||||||
Selection criteria sub entry (octets 20 to ff) when set type is "preferred roaming partner list" is coded as follows. Length of sub entry (octet 20) indicates length of subsequent fields in the selection criteria sub entry. Priority (octet 21): the lower priority value indicates the higher priority in the preferred roaming partner list. FQDN_Match length (octet 22) indicates the length of the FQDN_Match field. FQDN_Match field (octets 23 to ee) is as the node PerProviderSubscription/<X+>/Policy/PreferredRoamingPartnerList/<X+>/FQDN_Match defined in Hotspot 2.0 (Release 2) Technical Specification [9]. Country length (octet ee+1) indicates the length of the country field. Country field (octets ee+2 to ff) is as the node PerProviderSubscription/<X+>/Policy/PreferredRoamingPartnerList/<X+>/Country defined in Hotspot 2.0 (Release 2) Technical Specification [9]. Selection criteria sub entry (octets 20 to ff) when set type is "required protocol port tuple" is coded as follows. Length of sub entry (octet 20) indicates length of subsequent fields in the selection criteria sub entry. IP protocol field (octet 21) shall be present in the sub entry and refers to IP protocol field in IPv4 packets or the next header field in IPv6 packets. It is required by operator-supported application(s) on UE as specified in Hotspot 2.0 (Release 2) Technical Specification [9]. Length of port number (octet 22) indicates the length of port number field. Port number field (octets 23 to ff) is as the node PerProviderSubscription/<X+>/Policy/RequiredProtoPortTuple/<X+>/PortNumber defined in Hotspot 2.0 (Release 2) Technical Specification [9]. |
|||||||||||||||
Selection criteria sub entry (octets 20 to ff) when set type is "SP exclusion list" is coded as follows. Length of sub entry (octet 20) indicates length of subsequent fields in the selection criteria sub entry, i.e. the length of SSID field. SSID field (octets 21 to ff) is as the node PerProviderSubscription/<X+>/Policy/SPExclusionList/<X+>SSID defined in Hotspot 2.0 (Release 2) Technical Specification [9]. |
|||||||||||||||
Selection criteria sub entry (octets 20 to 28) when set type is "minmum backhaul threshold" is coded as follows. Network type (bit 1-2 of octet 20) is coded as follows according to the definition of the node PerProviderSubscription/<X+>/Policy/MinBackhaulThreshold/<X+>/NetworkType in Hotspot 2.0 (Release 2) Technical Specification [9]. Bits 2 1 0 0 home 0 1 roaming All other values are reserved. DLBI (bit 3 of octet 20): Bit 3 0 Downlink bandwidth field (octets 21 to 24) is not present. 1 Downlink bandwidth field (octets 21 to 24) is present. ULBI (bit 4 of octet 20): Bit 4 0 Uplink bandwidth field (octets 25 to 28) is not present. 1 Uplink bandwidth field (octets 25 to 28) is present. |
|||||||||||||||
Downlink bandwidth field (octets 21 to 24) is as the node PerProviderSubscription/<X+>/Policy/MinBackhaulThreshold/<X+>/DLBandwidth defined in Hotspot 2.0 (Release 2) Technical Specification [9]. Uplink bandwidth field (octets 25 to 28) is as the node PerProviderSubscription/<X+>/Policy/MinBackhaulThreshold/<X+>/ULBandwidth defined in Hotspot 2.0 (Release 2) Technical Specification [9]. |
|||||||||||||||
Validity area (octets r+1 to s) |
|||||||||||||||
This field contains the binary encoding of the validity area for a particular WLANSP rule. |
|||||||||||||||
Entry type (bits 7-8 of octet r+6) is coded as follows: Bits 8 7 0 1 3GPP location |
|||||||||||||||
Length of 3GPP location sub entry (octets r+7 to r+8) |
|||||||||||||||
This field contains the length of the location entry when the WLANSP rule is for validity area of a 3GPP location. |
|||||||||||||||
MCC, Mobile country code (octet r+9, and bits 4 to 1 of octet r+10) |
|||||||||||||||
The MCC field is coded as in ITU-T Recommendation E.212 [10], annex A. |
|||||||||||||||
MNC, Mobile network code (bits 8 to 5 of octet r+10, and octet r+11) |
|||||||||||||||
The encoding of this field is the responsibility of each administration but BCD encoding shall be used. The MNC shall consist of 2 or 3 digits. If a network operator may decide to use only two digits in the MNC over the radio interface, MNC digit 3 shall be encoded as "1111". |
|||||||||||||||
When the location entry type is "geo location", the location field in this entry has fixed length as shown in figure 5.3.2.11a. Anchor latitude (octets r+10 to r+13) is defined in clause 6.1 of 3GPP TS 23.032 [7]. Anchor longitude (octets r+14 to r+17) is defined in clause 6.1 of 3GPP TS 23.032 [7]. Radius (octets r+18 to r+19) is given in meters and is defined in clause 6.6 of 3GPP TS 23.032 [7]. |
|||||||||||||||
Location field type (octet r+14) when entry type is 3GPP location, or Location field type (octet r+11) when entry type is WLAN location. This field indicates the type of location field. Bits 0 0 0 0 0 0 0 1 TAC |
|||||||||||||||
When 3GPP location field type is set to "TAC", the TAC field is as defined in 3GPP TS 23.003 [4]. When 3GPP location field type is set to "EUTRA CI", the EUTRA CI field is set to the cell identity part of the Evolved Cell Global Identifier, as described in 3GPP TS 36.331 [6]. When 3GPP location field type is set to "NR CI", the NR CI field is set to the NR cell identity part of the NR Cell Global Identifier as defined in 3GPP TS 38.413 [14]. When WLAN location field type is set to "HESSID", the HESSID field is set to a 6 octet MAC address that identifies the homogeneous ESS (see IEEE Std 802.11 [8]). When WLAN location field type is set to "SSID", the SSID field is set to an Octet String which shall have a maximum length of 32 octets (see IEEE Std 802.11 [8]). When WLAN location field type is set to "BSSID", the BSSID field is set to an Octet String which shall be 6 octets long (see IEEE Std 802.11 [8]). |
|||||||||||||||
Time of day (octets s+1 to u) |
|||||||||||||||
This field contains the binary encoding of the time of day condition for a particular WLANSP rule. |
|||||||||||||||
ToD sub field type ={time start, time stop, date start, date stop, day of week} (octet s+8) Bits 0 0 0 0 0 0 0 1 time start All other values are reserved. when field type is set to "time start" or "time stop", the value of this ToD sub field contents is time of the day represented in string format, as defined in ISO 8601:2004 [13] When field type is set to "date start" or "date stop", the value of this ToD sub field contents is a date represented in string format, as defined in ISO 8601:2004 [13]. When field type is set to "day of the week", the value of this ToD sub field contents is an 8-bit integer formatted as a bitmap representing days of the week. The most significant bit is set to one. The remaining bits represent days of the week. |
|||||||||||||||
NOTE 1: The value of roaming is valid only if the WLANSP rule is provided by the H-PCF. NOTE 2: The group of selection criteria as described in clause 4.3.2.1 is encoded as selection criteria entry. NOTE 3: The home network indication shall not be set by V-PCF. NOTE 4: If the home network indication bit is set to "1", the preferred SSID list shall not be present. NOTE 5: If the home network indication bit is set to "1", the preferred roaming partner list shall not be present. The preferred roaming partner list is provided by H-PCF only. |
5.3.3 Encoding of N3AN node configuration information
5.3.3.1 General
The purpose of the N3AN node configuration information is to indicate the non-3GPP access network (N3AN) node configuration information to the UE for selection of either N3IWF or ePDG for accessing 5GCN or EPC respectively via non-3GPP access.
The N3AN node configuration information is encoded as shown in figure 5.3.3.1.1, table 5.3.3.1.1, figure 5.3.3.1.2, table 5.3.3.1.2.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
0 |
0 |
0 |
0 |
ANDSP Info type={N3AN-node-configuration-information} |
octet x |
|||
Spare |
||||||||
Length of ANDSP info contents |
octet x+1 octet x+2 |
|||||||
ANDSP info contents={N3AN node configuration information contents} |
octet x+3 octet z |
Figure 5.3.3.1.1: ANDSP info containing N3AN node configuration information, where x=k
Table 5.3.3.1.1: N3AN node configuration information
ANDSP Info type (bit 1 to 4 of octet x) shall be set to "0010" (N3AN node configuration information) |
||
Bits 8 to 5 of octet x are spare and shall be encoded as zero. |
||
Length of ANDSP info contents (octets x+1 to x+2) indicates the length of the N3AN node configuration information contents. |
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Length of N3AN node selection information |
octet x+3 octet x+4 |
|||||||
Content of N3AN node selection information |
octet x+5 octet v |
|||||||
N3AN node configuration information type (type = home N3IWF identifier configuration) |
octet v+1* |
|||||||
Length of home N3IWF identifier configuration |
octet v+2* octet v+3* |
|||||||
Content of home N3IWF identifier configuration |
octet v+4* octet w* |
|||||||
N3AN node configuration information type (type = home ePDG identifier configuration) |
octet w+1* |
|||||||
Length of home ePDG identifier configuration |
octet w+2* octet w+3* |
|||||||
Content of home ePDG identifier configuration |
octet w+4* octet z* |
Figure 5.3.3.1.2: N3AN node configuration information contents
Table 5.3.3.1.2: Content of N3AN node configuration information
N3AN node configuration information type is coded as follows. |
|||||||||
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
Home N3IWF identifier configuration |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
Home ePDG identifier configuration |
|
All other values are reserved. |
|||||||||
N3AN node selection information field (octet x+5 to v) shall be present and the content is as encoded in clause 5.3.3.2. |
|||||||||
Home N3IWF identifier configuration field (octet v+1 to w) may be present and the content is as encoded in clause 5.3.3.3. |
|||||||||
Home ePDG identifier configuration field (octet w+1 to z) may be present and the content is is as encoded in clause 5.3.3.4. |
|||||||||
5.3.3.2 N3AN node selection information
The content of N3AN node selection information contains a sequence of the N3AN node selection information entries. Each N3AN node selection information entry contains a PLMN ID and information for the PLMN ID. The content of N3AN node selection information contains at least an N3AN node selection information entry with information for the HPLMN and an N3AN node selection information entry for "any_PLMN".
NOTE: If N3AN node selection information does not contain at least:
– an N3AN node selection information entry with information for the HPLMN; and
– an N3AN node selection information entry for "any_PLMN";
the N3AN node selection information is handled as a syntactically incorrect IE according to 3GPP TS 24.501 [11].
The content is encoded according to figure 5.3.3.2.1, figure 5.3.3.2.2 and table 5.3.3.2.1.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
N3AN node selection information entry 1 |
octet x+5 |
|||||||
octet y |
||||||||
N3AN node selection information entry 2 |
octet y+1 octet t |
|||||||
… |
||||||||
N3AN node selection information entry n |
octet u octet v |
Figure 5.3.3.2.1: Content of N3AN node selection information
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|||
Length of N3AN node selection information entry |
octet x+5 |
|||||||||
MCC digit 2 |
MCC digit 1 |
octet x+6 |
||||||||
MNC digit 3 |
MCC digit 3 |
octet x+7 |
||||||||
MNC digit 2 |
MNC digit 1 |
octet x+8 |
||||||||
FQDN format |
Preference |
Priority |
octet x+9 |
Figure 5.3.3.2.2: N3AN node selection information entry
Table 5.3.3.2.1: N3AN node selection information
Length of N3AN node selection information entry (octet x+5) contains length of subsequent fields in the N3AN node selection information entry. |
||
PLMN ID (octet x+6 to x+8) field shall be set to zero if it indicates "any_PLMN". Otherwise, |
||
MCC, Mobile country code (octet x+6, and bits 4 to 1 of octet x+7) |
||
The MCC field is encoded as in ITU-T Recommendation E.212 [10], annex A. |
||
MNC, Mobile network code (bits 8 to 5 of octet x+7, and octet x+8) |
||
The encoding of this field is the responsibility of each administration but BCD coding shall be used. The MNC shall consist of 2 or 3 digits. If a network operator decides to use only two digits in the MNC, MNC digit 3 shall be encoded as "1111". |
||
Priority (bits 5 to 1 of octet x+9) indicates the preference order given to N3AN nodes of a PLMN. The lower value indicates higher priority. If the PLMN is the UE’s HPLMN or the PLMN ID indicates "any_PLMN", this priority filed shall be ignored. |
||
Preference (bit 6 of octet x+9) indicates which N3AN node type is preferred in this PLMN and is encoded as follows. |
||
6 |
||
0 |
N3IWF is preferred |
|
1 |
ePDG is preferred |
|
FQDN format (bits 8 to 7 of octet x+9) indicates format to be used when the FQDN is constructed by the UE. This field is encoded as follows. |
||
8 |
7 |
|
0 |
0 |
Operator identifier based ePDG FQDN format or operator identifier based N3IWF FQDN. |
0 |
1 |
Tracking/location area identity based ePDG FQDN format or tracking area identity based N3IWF FQDN format. |
All other values are reserved. |
||
5.3.3.3 Home N3IWF identifier configuration
The content of home N3IWF identifier configuration contains a list of home N3IWF identifier entries.
The content of home N3IWF identifier configuration is encoded according to figure 5.3.3.3.1.
The content of each home N3IWF identifier entry is coded according to figure 5.3.3.3.2, table 5.3.3.3.1, figure 5.3.3.3.3 and table 5.3.3.3.2.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Home N3IWF identifier entry 1 |
octet v+4 |
|||||||
octet u |
||||||||
Home N3IWF identifier entry 2 |
octet u+1 octet m |
|||||||
… |
||||||||
Home N3IWF identifier entry n |
octet w |
Figure 5.3.3.3.1: Content of home N3IWF identifier configuration
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Home N3IWF identifier type (= IP address type) |
octet 1 |
|||||||
Home N3IWF IP addresses |
octet 2 octet z |
Figure 5.3.3.3.2: Home N3IWF identifier entry (type = IP address type)
Table 5.3.3.3.1: Home N3IWF identifier entry (type = IP address type)
Home N3IWF identifier type (octet 1) is set as follows when the type is IP address. |
|||||||||
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
IPv4 |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
IPv6 |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
IPv4IPv6 |
|
If the home N3IWF identifier type indicates IPv4, then the home N3IWF IP addresses field contains an IPv4 address in octet 2 to octet 5. |
|||||||||
If the home N3IWF identifier type indicates IPv6, then the home N3IWF IP addresses field contains an IPv6 address in octet 2 to octet 17. |
|||||||||
If the home N3IWF identifier type indicates IPv4IPv6, then the home N3IWF IP addresses field contains two IP addresses. The first IP address is an IPv4 address in octet 2 to octet 5. The second IP address is an IPv6 address in octet 6 to octet 21. |
|||||||||
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Home N3IWF identifier type (= FQDN) |
octet 1 |
|||||||
Length of home N3IWF FQDN |
octet 2 |
|||||||
Home N3IWF FQDN |
octet 3 octet m |
Figure 5.3.3.3.3: Home N3IWF identifier entry (type = FQDN)
Table 5.3.3.3.2: Home N3IWF identifier entry (type = FQDN)
Home N3IWF identifier type (octet 1) is set as follows when the type is FQDN. |
|||||||||
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
FQDN |
|
Length of home N3IWF FQDN field (octet 2) indicates the length of home N3IWF FQDN. |
|||||||||
Home N3IWF FQDN field (octet 3 to octet m) is encoded as defined in clause 28.3.2.2.2 in 3GPP TS 23.003 [4]. |
|||||||||
5.3.3.4 Home ePDG identifier configuration
The content of home ePDG identifier configuration contains a list of home ePDG identifier entries.
The content of home ePDG identifier configuration is encoded according to figure 5.3.3.4.1.
The content of each home ePDG identifier entry is encoded according to figure 5.3.3.4.2, table 5.3.3.4.1, figure 5.3.3.4.3 and table 5.3.3.4.2.
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Home ePDG identifier entry 1 |
octet w+4 |
|||||||
octet u |
||||||||
Home ePDG identifier entry 2 |
octet u+1 octet m |
|||||||
… |
||||||||
Home ePDG identifier entry n |
octet p |
Figure 5.3.3.4.1: Content of home ePDG identifier configuration
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Home ePDG identifier type (= IP address type) |
octet 1 |
|||||||
Home ePDG IP addresses |
octet 2 octet e |
Figure 5.3.3.4.2: Home ePDG identifier entry (type = IP address type)
Table 5.3.3.4.1: Home ePDG identifier entry (type = IP address type)
Home ePDG identifier type (octet 1) is set as follows when the type is IP address. |
|||||||||
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
IPv4 |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
IPv6 |
|
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
IPv4IPv6 |
|
If the home ePDG identifier type indicates IPv4, then the home ePDG IP addresses field contains an IPv4 address in octet 2 to octet 5. |
|||||||||
If the home ePDG identifier type indicates IPv6, then the home ePDG IP addresses field contains an IPv6 address in octet 2 to octet 17. |
|||||||||
If the home ePDG identifier type indicates IPv4IPv6, then the home ePDG IP addresses field contains two IP addresses. The first IP address is an IPv4 address in octet 2 to octet 5. The second IP address is an IPv6 address in octet 6 to octet 21. |
|||||||||
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
|
Home ePDG identifier type (= FQDN) |
octet 1 |
|||||||
Length of home ePDG FQDN |
octet 2 |
|||||||
Home ePDG FQDN |
octet 4 octet f |
Figure 5.3.3.4.3: Home ePDG identifier entry (type = FQDN)
Table 5.3.3.4.2: Home ePDG identifier entry (type = FQDN)
Home ePDG identifier type (octet 1) is set as follows when the type is FQDN. |
|||||||||
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
FQDN |
|
Length of home ePDG FQDN field (octet 2) indicates the length of home ePDG FQDN. |
|||||||||
Home ePDG FQDN field (octet 3 to octet f) is encoded as defined in clause 19.4.2.9.2 in 3GPP TS 23.003 [4]. |
|||||||||
Annex A (informative):
Change history
Change history |
|||||||
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
2018-04 |
CT1#110 |
TS skeleton is provided by C1-182823. C1-182793, C1-182795, C1-182798, C1-182821, C1-182822 are implemented as Annex A. |
0.0.0 |
||||
2018-05 |
CT1#111 |
Includes the following contributions agreed by CT1 at CT#111: C1-183550, C1-183551, C1-183552, C1-183553, C1-183555, C1-183556, C1-183862, C1-183863. |
0.1.0 |
||||
2018-06 |
CT-80 |
version 1.0.0 created for presentation for information |
1.0.0 |
||||
2018-07 |
CT1#111bis |
Includes the following contributions agreed by CT1 at CT#111bis: C1-184345, C1-184627, C1-184691, C1-184859, C1-184927, C1-184945, C1-184948. |
1.1.0 |
||||
2018-08 |
CT1#112 |
Includes the following contributions agreed by CT1 at CT#112: C1-185149, C1-185630, C1-185636, C1-185641, C1-185679. |
1.2.0 |
||||
2018-09 |
CT-81 |
CP-182112 |
version 2.0.0 created for presentation for approval |
2.0.0 |
|||
2018-09 |
CT-81 |
version 15.0.0 created after approval |
15.0.0 |
||||
2018-12 |
CT-82 |
CP-183043 |
0001 |
2 |
F |
Modifications to ANDSP |
15.1.0 |
2018-12 |
CT-82 |
CP-183043 |
0002 |
2 |
F |
Aligning the clauses and correcting the reference and requirements |
15.1.0 |
2018-12 |
CT-82 |
CP-183043 |
0003 |
2 |
B |
Adding connection capabilities in URSP rules |
15.1.0 |
2018-12 |
CT-82 |
CP-183043 |
0004 |
2 |
F |
Editorial and other changes |
15.1.0 |
2018-12 |
CT-82 |
CP-183043 |
0005 |
1 |
B |
Coding of WLAN selection criteria entry |
15.1.0 |
2018-12 |
CT-82 |
CP-183043 |
0006 |
2 |
B |
Complete location entry definition |
15.1.0 |
2018-12 |
CT-82 |
CP-183043 |
0011 |
2 |
F |
Clarification on PDU session selection |
15.1.0 |
2018-12 |
CT-82 |
CP-183043 |
0013 |
2 |
F |
Clarification on URSP traffic descriptor and SSC mode |
15.1.0 |
2018-12 |
CT-82 |
CP-183043 |
0015 |
2 |
F |
OS App Id with a variable length |
15.1.0 |
2019-03 |
CT-83 |
CP-190090 |
0012 |
7 |
F |
Clarification on UE local configuration and URSP preference |
15.2.0 |
2019-03 |
CT-83 |
CP-190210 |
0016 |
6 |
F |
PCF does not send OS Id to UE |
15.2.0 |
2019-03 |
CT-83 |
CP-190090 |
0017 |
1 |
F |
The formats of OS Id |
15.2.0 |
2019-03 |
CT-83 |
CP-190090 |
0018 |
2 |
F |
Add destination FQDN as additional traffic descriptor |
15.2.0 |
2019-03 |
CT-83 |
CP-190090 |
0019 |
1 |
D |
Update abbreviations |
15.2.0 |
2019-03 |
CT-83 |
CP-190090 |
0020 |
3 |
F |
Correcting the name of ITU-T Recommendation E.212 |
15.2.0 |
2019-03 |
CT-83 |
CP-190090 |
0021 |
2 |
F |
Correction on WLANSP rules description |
15.2.0 |
2019-03 |
CT-83 |
CP-190090 |
0022 |
2 |
F |
Correction to Length of URSP rule and Length of route selection descriptor |
15.2.0 |
2019-03 |
CT-83 |
CP-190090 |
0024 |
1 |
F |
Clarification on OS Id + OS App Id field of URSP |
15.2.0 |
2019-03 |
CT-83 |
CP-190211 |
0026 |
2 |
F |
UE with multiple OS Ids |
15.2.0 |
2019-03 |
CT-83 |
CP-190090 |
0027 |
1 |
F |
Correction to length of location sub entry in WLANSP rule |
15.2.0 |
2019-03 |
CT-83 |
CP-190090 |
0028 |
2 |
F |
Unknown or unexpected URSP rules |
15.2.0 |
2019-06 |
CT-84 |
CP-191125 |
0030 |
F |
Update of association between application and existing PDU session |
15.3.0 |
|
2019-06 |
CT-84 |
CP-191125 |
0034 |
2 |
F |
Correction to Encoding of WLANSP |
15.3.0 |
2019-06 |
CT-84 |
CP-191125 |
0039 |
2 |
F |
Correction to UE Policy evaluation |
15.3.0 |
2019-06 |
CT-84 |
CP-191138 |
0029 |
1 |
B |
Multi-access access type preference |
16.0.0 |
2019-06 |
CT-84 |
CP-191131 |
0031 |
F |
Handling of unsupported PDU session type in route selection descriptor |
16.0.0 |
|
2019-06 |
CT-84 |
CP-191131 |
0032 |
1 |
F |
Changing "user preferences" to "UE local configuration" |
16.0.0 |
2019-06 |
CT-84 |
CP-191131 |
0033 |
1 |
F |
Handling of PDU session type |
16.0.0 |
2019-06 |
CT-84 |
CP-191131 |
0036 |
2 |
F |
Correction on coding of "all other values are spare" |
16.0.0 |
2019-06 |
CT-84 |
CP-191136 |
0037 |
1 |
F |
Correction to Encoding of WLANSP |
16.0.0 |
2019-06 |
CT-84 |
CP-191136 |
0038 |
2 |
F |
Reference to IEEE Std 802.11 |
16.0.0 |
2019-06 |
CT-84 |
CP-191131 |
0041 |
1 |
D |
Correction on the route selection descriptor component type identifier of URSP |
16.0.0 |
2019-09 |
CT-85 |
CP-192059 |
0042 |
1 |
5G-RG usage of ANDSP |
16.1.0 |
|
2019-09 |
CT-85 |
CP-192074 |
0043 |
1 |
B |
Introduction of background data transfer policy information in URSP |
16.1.0 |
2019-09 |
CT-85 |
CP-192055 |
0045 |
F |
Clarification on application information matching |
16.1.0 |
|
2019-09 |
CT-85 |
CP-192055 |
0046 |
1 |
F |
Clarification on PDU session association |
16.1.0 |
2019-09 |
CT-85 |
CP-192071 |
0047 |
3 |
F |
Use of the URSP rules in EPS |
16.1.0 |
2019-09 |
CT-85 |
CP-192059 |
0051 |
2 |
F |
URSP and ANDP information for wireline 5G access network |
16.1.0 |
2019-09 |
CT-85 |
CP-192063 |
0052 |
1 |
B |
Specifying and adding reference for V2X Policy |
16.1.0 |
2019-09 |
CT-85 |
CP-192060 |
0053 |
1 |
F |
Usage of access type preference |
16.1.0 |
2019-09 |
CT-85 |
CP-192060 |
0054 |
1 |
F |
Occurrence of Preferred access type and Multi-access preference |
16.1.0 |
2019-09 |
CT-85 |
CP-192055 |
0055 |
F |
Handling of S-NSSAI in RSD descriptor but not in the allowed NSSAI |
16.1.0 |
|
2019-12 |
CT-86 |
CP-193092 |
0056 |
1 |
F |
Handling of unsupported SSC mode in route selection descriptor |
16.2.0 |
2019-12 |
CT-86 |
CP-193092 |
0057 |
1 |
F |
Clarification on the DNN in the route selection descriptor |
16.2.0 |
2019-12 |
CT-86 |
CP-193092 |
0058 |
2 |
F |
Correction on using URSP in EPS |
16.2.0 |
2019-12 |
CT-86 |
CP-193092 |
0059 |
3 |
F |
Clarification for URSP evaluation |
16.2.0 |
2019-12 |
CT-86 |
CP-193092 |
0061 |
1 |
F |
Correction to association between an application and an existing PDU session |
16.2.0 |
2019-12 |
CT-86 |
CP-193101 |
0063 |
F |
Correct the reference of access type IE |
16.2.0 |
|
2019-12 |
CT-86 |
CP-193100 |
0065 |
1 |
B |
5G-RG and W-AGF acting on behalf of FN-RG usage of URSP |
16.2.0 |
2019-12 |
CT-86 |
CP-193092 |
0066 |
F |
Correction to S-NSSAI RSD component encoding |
16.2.0 |
|
2019-12 |
CT-86 |
CP-193092 |
0067 |
1 |
F |
Pre-configured URSP rules in USIM |
16.2.0 |
2020-03 |
CT-87e |
CP-200110 |
0069 |
1 |
F |
Matching of SSC mode for association between an application and a PDU session |
16.3.0 |
2020-03 |
CT-87e |
CP-200113 |
0070 |
F |
LADN service does not apply for RG connected to 5GC via wireline access |
16.3.0 |
|
2020-06 |
CT-88e |
CP-201101 |
0071 |
F |
Reference correction in URSP encoding |
16.4.0 |
|
2020-06 |
CT-88e |
CP-201101 |
0073 |
1 |
F |
Clarification on URSP in EPS |
16.4.0 |
2020-06 |
CT-88e |
CP-201101 |
0075 |
1 |
F |
Allowed SSC mode for association between an application and a PDU session |
16.4.0 |
2020-06 |
CT-88e |
CP-201101 |
0077 |
1 |
F |
Correction to the URSP encoding |
16.4.0 |
2020-06 |
CT-88e |
CP-201101 |
0079 |
2 |
F |
Specify UE behavior when pre-configured policy is syntactically incorrect |
16.4.0 |
2020-06 |
CT-88e |
CP-201101 |
0081 |
1 |
F |
Domain descriptors in URSP |
16.4.0 |
2020-06 |
CT-88e |
CP-201108 |
0082 |
1 |
D |
URSP for RGs editorial fix |
16.4.0 |
2020-06 |
CT-88e |
CP-201101 |
0084 |
1 |
F |
Corrections to UE policies specification |
16.4.0 |
2020-09 |
CT-89e |
CP-202149 |
0087r1 |
1 |
F |
Removal of Editor’s Notes for URSP related capability indications |
16.5.0 |
2020-09 |
CT-89e |
CP-202174 |
0085r1 |
1 |
F |
Optimization of handling unknown or unexpected URSP rules |
17.0.0 |
2020-12 |
CT-90e |
CP-203177 |
0091 |
A |
Correction on association between an application and a PDU session for RG |
17.1.0 |
|
2020-12 |
CT-90e |
CP-203175 |
0092 |
1 |
F |
Clarification on traffic descriptor component type of VLAN tag control information |
17.1.0 |
2020-12 |
CT-90e |
CP-203167 |
0094 |
1 |
A |
EN resolution on domain descriptors in URSP |
17.1.0 |
2020-12 |
CT-90e |
CP-203175 |
0095 |
1 |
F |
The correction on the process of URSP handling |
17.1.0 |
2020-12 |
CT-90e |
CP-203175 |
0097 |
1 |
F |
Optional fields of N3AN node configuration information |
17.1.0 |
2020-12 |
CT-90e |
CP-203176 |
0100 |
1 |
A |
Lack of bit encoding of the location entry type in the WLANSP IE |
17.1.0 |
2020-12 |
CT-90e |
CP-203175 |
0102 |
1 |
F |
UE behaviour on SNPN URSP stored in ME |
17.1.0 |
2020-12 |
CT-90e |
CP-203205 |
0103 |
1 |
F |
DNN setting in the upper layers for PAP/CHAP |
17.1.0 |
2020-12 |
CT-90e |
CP-203175 |
0105 |
1 |
F |
Referring to TS 23.003 for FQDN format |
17.1.0 |
2021-03 |
CT-91e |
CP-210116 |
0108 |
1 |
F |
Re-use of existing connection to WLAN access when applying URSP |
17.2.0 |
2021-03 |
CT-91e |
CP-210116 |
0110 |
F |
Avoid unnecessary new PDU session with the same attributes |
17.2.0 |
|
2021-03 |
CT-91e |
CP-210244 |
0111 |
3 |
A |
Encoding of Location Criteria Type |
17.2.0 |
2021-03 |
CT-91e |
CP-210116 |
0112 |
1 |
F |
Clarifications on PLMN and SNPN URSP storage – 24.526 part |
17.2.0 |
2021-03 |
CT-91e |
CP-210116 |
0113 |
1 |
F |
Clarifications on PLMN URSP stored in USIM |
17.2.0 |
2021-06 |
CT-92e |
CP-211142 |
0115 |
2 |
B |
UE policies for 5G ProSe policy |
17.3.0 |
2021-06 |
CT-92e |
CP-211145 |
0118 |
– |
F |
Correction on term SNPN access mode |
17.3.0 |
2021-06 |
CT-92e |
CP-211145 |
0120 |
– |
F |
URSP evaluation upon configured NSSAI update |
17.3.0 |
2021-06 |
CT-92e |
CP-211146 |
0117 |
1 |
F |
PDU session type for URSP association |
17.3.0 |
2021-09 |
CT-93e |
CP-212154 |
0121 |
1 |
F |
Introduction of MAC address range traffic descriptor component type in URSP rule |
17.4.0 |
2021-09 |
CT-93e |
CP-212134 |
0122 |
2 |
B |
Adding the 5G ProSe UE-to-network relay support to the URSP |
17.4.0 |
2021-09 |
CT-93e |
CP-212134 |
0123 |
1 |
B |
Mapping of 5G ProSe Layer-3 UE-to-Network Relay offload when moving from N1 mode to S1 mode |
17.4.0 |
2021-12 |
CT-94e |
CP-213045 |
0128 |
1 |
F |
5G ProSe Layer-3 UE-to-Network Relay Offload indication for the UEs capable to act as Remote UEs |
17.5.0 |
2021-12 |
CT-94e |
CP-213048 |
0131 |
1 |
F |
DNN in URSP traffic descriptor and route selection descriptor |
17.5.0 |
2021-12 |
CT-94e |
CP-213054 |
0127 |
1 |
B |
URSP amendment for redundant PDU session |
17.5.0 |