Tech-invite3GPPspaceIETF RFCsSIP
index21222324252627282931323334353637384‑5x

Content for  TS 24.501  Word version:  18.1.0

Top   Top   Up   Prev   None
1…   3…   4…   4.4…   4.4.3…   4.5…   4.5.3…   4.6…   4.7…   4.9…   4.15…   5…   5.2…   5.3…   5.3.2…   5.3.7…   5.3.19…   5.4…   5.4.1.3…   5.4.2…   5.4.4…   5.4.5…   5.4.6…   5.5…   5.5.1.2.4   5.5.1.2.5…   5.5.1.3…   5.5.1.3.4   5.5.1.3.5…   5.5.2…   5.6…   5.6.2…   6…   6.1.4…   6.2…   6.3…   6.3.2…   6.3.3…   6.4…   6.4.1.4…   6.4.2…   6.5…   7…   8…   8.2.9…   8.3…   9…   9.11.2…   9.11.2.10…   9.11.3…   9.11.3.4…   9.11.3.8…   9.11.3.14…   9.11.3.18C…   9.11.3.29…   9.11.3.33…   9.11.3.39…   9.11.3.45…   9.11.3.50…   9.11.3.53A…   9.11.3.68…   9.11.3.75…   9.11.4…   9.11.4.10…   9.11.4.13…   9.11.4.16…   9.11.4.30…   9.12   10…   A…   B…   C…   D…   D.6…   D.6.3…

 

D.6.3  UE policy section management resultp. 961

The purpose of the UE policy section management result information element is to transfer from the UE to the PCF information about instructions for UE policy section management which the UE could not execute successfully.
The UE policy section management result information element is coded as shown in Figure D.6.3.1, Figure D.6.3.2, Figure D.6.3.3, Figure D.6.3.4, Figure D.6.3.5 and Table D.6.3.1.
The UE policy section management result information element has a minimum length of 12 octets and a maximum length of 65534 octets.
Reproduction of 3GPP TS 24.501, Fig. D.6.3.1: UE policy section management result information element
Up
Reproduction of 3GPP TS 24.501, Fig. D.6.3.2: UE policy section management result contents
Up
Reproduction of 3GPP TS 24.501, Fig. D.6.3.3: UE policy section management subresult
Up
Reproduction of 3GPP TS 24.501, Fig. D.6.3.4: UE policy section management subresult contents
Up
Reproduction of 3GPP TS 24.501, Fig. D.6.3.5: Result
Up
Value part of the UE policy section management result information element (octets 4 to z)
The value part of the UE policy section management result information element consists of one or several UE policy section management subresults.
UE policy section management subresult:
Number of results (octet d)
This field contains the binary encoding of number of results included in the UE policy section management subresult.
MCC, Mobile country code (octet d+1, and bits 4 to 1 of octet d+2)
The MCC field is coded as in ITU-T Recommendation E.212 [42], Annex A.
MNC, Mobile network code (bits 8 to 5 of octet d+2, and octet d+3)
The coding 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 coded as "1111".
UE policy section management subresult contents (octets d+4 to y)
The UE policy section management subresult contents consist of one or several results.
Result (octet f to f+4)
UPSC (octet f to f+1)
This field contains the binary encoding of the UPSC. The value of the UPSC is set by the PCF
Failed instruction order (octets f+2 to f+3)
This field contains the binary encoding of the order of the failed instruction in the UE policy section management sublist.
Cause (octet f+4)
Bits
8 7 6 5 4 3 2 1
0 1 1 0 1 1 1 1Protocol error, unspecified
The receiving entity shall treat any other value as 0110 1111, "protocol error, unspecified".
Up

D.6.4  UPSI listp. 963

The purpose of the UPSI list information element is to transfer from the UE to the PCF a list of UPSIs.
The UPSI list information element is coded as shown in Figure D.6.4.1, Figure D.6.4.2, and Table D.6.4.1.
The UPSI list information element has a minimum length of 10 octets and a maximum length of 65532 octets.
Reproduction of 3GPP TS 24.501, Fig. D.6.4.1: UPSI list information element
Up
Reproduction of 3GPP TS 24.501, Fig. D.6.4.2: UPSI sublist
Up
MCC, Mobile country code (octet d+2, and bits 4 to 1 of octet d+3)
The MCC field is coded as in ITU-T Recommendation E.212 [42], Annex A.
MNC, Mobile network code (bits 8 to 5 of octet d+3, and octet d+4)
The coding 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 coded as "1111".
UPSC (octets d+5 to d+6)
This field contains the binary encoding of the UPSC. The value of the UPSC is set by the PCF.
Up

D.6.5  UE policy classmarkp. 964

The purpose of the UE policy classmark information element is to provide the network with information about the policy aspects of the UE.
The UE policy classmark information element is coded as shown in Figure D.6.5.1 and Table D.6.5.1.
The UE policy classmark is a type 4 information element with a minimum length of 3 octets and a maximum length of 5 octets.
Reproduction of 3GPP TS 24.501, Fig. D.6.5.1: UE policy classmark information element
Up
Support of ANDSP by the UE (SupportANDSP) (octet 3, bit 1)
Bit
1
0ANDSP not supported by the UE
1ANDSP supported by the UE
All other bits in octet 3 to 5 are spare and shall be coded as zero, if the respective octet is included in the information element.
Up

D.6.6  UE OS Idp. 965

The purpose of the UE OS Id information element is to provide the network with information about the OS of the UE.
The UE OS Id information element is coded as shown in Figure D.6.6.1 and Table D.6.6.1.
The UE OS Id is a type 4 information element with a minimum length of 18 octet and a maximum length of 242 octets.
Reproduction of 3GPP TS 24.501, Fig. D.6.6.1: UE OS Id information element
Up
OS Id:
The OS Id is coded as a sequence of a sixteen octet OS Id value field. The OS Id value field is defined as Universally Unique IDentifier (UUID) as specified in RFC 4122.
Up

D.6.7  UE policy network classmark |R17|p. 965

The purpose of the UE policy network classmark information element is to provide the UE with information about the policy aspects of the network.
The UE policy network classmark information element is coded as shown in Figure D.6.7.1 and Table D.6.7.1.
The UE policy network classmark is a type 4 information element with a minimum length of 3 octets and a maximum length of 5 octets.
Spare
Reproduction of 3GPP TS 24.501, Fig. D.6.7.1: UE policy network classmark information element
Up
Non-subscribed SNPN signalled URSP handling indication (NSSUI) (octet 3, bit 1) (see NOTE)
Bit
1
0UE is allowed to accept URSP signalled by non-subscribed SNPNs
0UE is not allowed to accept URSP signalled by non-subscribed SNPNs
All other bits in octet 3 to 5 are spare and shall be coded as zero, if the respective octet is included in the information element.
NOTE:
Receiving entity shall ignore this bit, if received from the RPLMN which is not the HPLMN or from the RSNPN which is not the subscribed SNPN.
Up

D.7  Timers of UE policy delivery servicep. 966

Timers of UE policy delivery service are shown in Table D.7.1.
TIMER NUM. TIMER VALUE CAUSE OF START NORMAL STOP ON THE 1st, 2nd, 3rd, 4th EXPIRY (NOTE 1)
T3501NOTE 1Transmission of MANAGE UE POLICY COMMANDMANAGE UE POLICY COMMAND COMPLETE or MANAGE UE POLICY COMMAND REJECT message receivedRetransmission of MANAGE UE POLICY COMMAND message
NOTE 1:
The value of this timer is network dependent.
Up

D.8  Handling of unknown, unforeseen, and erroneous UPDS data |R16|p. 966

D.8.1  Generalp. 966

The procedures specified in the subclause apply to those messages which pass the checks described in this subclause.
This subclause also specifies procedures for the handling of unknown, unforeseen, and erroneous UPDS data by the receiving entity. These procedures are called "error handling procedures", but in addition to providing recovery mechanisms for error situations they define a compatibility mechanism for future extensions of the UPDS.
Subclause D.8.1 to Subclause D.8.8 shall be applied in order of precedence.
Detailed error handling procedures in the network are implementation dependent and may vary from PLMN to PLMN. However, when extensions of UPDS are developed, networks are assumed to have the error handling which is indicated in this subclause as mandatory ("shall") and that is indicated as strongly recommended ("should").
Also, the error handling of the network is only considered as mandatory or strongly recommended when certain thresholds for errors are not reached during a dedicated connection.
For definition of semantical and syntactical errors see TS 24.007, subclause 11.4.2.
Up

D.8.2  Message too short or too longp. 967

D.8.2.1  Message too shortp. 967

When a message is received that is too short to contain a complete message type information element, that message shall be ignored, c.f. TS 24.007.

D.8.2.2  Message too longp. 967

The maximum size of a UE policy delivery service message is 65535 octets.

D.8.3  Unknown or unforeseen procedure transaction identityp. 967

D.8.3.1  Procedure transaction identityp. 967

The following network procedures shall apply for handling an unknown, erroneous, or unforeseen PTI received in a UPDS message:
  1. In case the network receives a MANAGE UE POLICY COMPLETE message or MANAGE UE POLICY COMMAND REJECT message in which the PTI value is an assigned or unassigned value that does not match any PTI in use, the network shall ignore the UPDS message.
  2. In case the network receives a UPDS message in which the PTI value is a reserved value, the network shall ignore the UPDS message.
The following UE procedures shall apply for handling an unknown, erroneous, or unforeseen PTI received in a UPDS message:
  1. In case the UE receives a UPDS message in which the PTI value is a reserved value, the UE shall ignore the UPDS message.
Up

D.8.4  Unknown or unforeseen message typep. 967

If the UE or the network receives a UPDS message with message type not defined for the UPDS or not implemented by the receiver, it shall ignore the UPDS message.
If the UE receives a message not compatible with the UPDS state, the UE shall ignore the UPDS message.
If the network receives a message not compatible with the UPDS state, the network actions are implementation dependent.
Up

D.8.5  Non-semantical mandatory information element errorsp. 968

D.8.5.1  Common proceduresp. 968

When on receipt of a message,
  1. an "imperative message part" error; or
  2. a "missing mandatory IE" error
is diagnosed or when a message containing:
  1. a syntactically incorrect mandatory IE;
  2. an IE unknown in the message, but encoded as "comprehension required" (see TS 24.007); or
  3. an out of sequence IE encoded as "comprehension required" (see TS 24.007) is received,
the UE shall ignore the UPDS message;
the network shall proceed as follows:
the network shall:
  1. try to treat the message (the exact further actions are implementation dependent); or
  2. ignore the message.
Up

D.8.6  Unknown and unforeseen IEs in the non-imperative message partp. 968

D.8.6.1  IEIs unknown in the messagep. 968

The UE shall ignore all IEs unknown in a message which are not encoded as "comprehension required" (see TS 24.007).
The network shall take the same approach.

D.8.6.2  Out of sequence IEsp. 968

The UE shall ignore all out of sequence IEs in a message which are not encoded as "comprehension required" (see TS 24.007).
The network should take the same approach.

D.8.6.3  Repeated IEsp. 968

If an information element with format T, TV, TLV, or TLV-E is repeated in a message in which repetition of the information element is not specified in subclause D.5, the UE shall handle only the contents of the information element appearing first and shall ignore all subsequent repetitions of the information element. When repetition of information elements is specified, the UE shall handle only the contents of specified repeated information elements. If the limit on repetition of information elements is exceeded, the UE shall handle the contents of information elements appearing first up to the limit of repetitions and shall ignore all subsequent repetitions of the information element.
The network should follow the same procedures.
Up

D.8.7  Non-imperative message part errorsp. 969

This category includes:
  1. syntactically incorrect optional IEs; and
  2. conditional IE errors.

D.8.7.1  Syntactically incorrect optional IEsp. 969

The UE shall treat all optional IEs that are syntactically incorrect in a message as not present in the message.
The network shall take the same approach.

D.8.7.2  Conditional IE errorsp. 969

When upon receipt of a UPDS message the UE diagnoses a "missing conditional IE" error or an "unexpected conditional IE" error, or when it receives a UPDS message containing at least one syntactically incorrect conditional IE, the UE shall ignore the message.
When the network receives a message and diagnoses a "missing conditional IE" error or an "unexpected conditional IE" error or when it receives a message containing at least one syntactically incorrect conditional IE, the network shall either:
  1. try to treat the message (the exact further actions are implementation dependent); or
  2. ignore the message.
Up

D.8.8  Messages with semantically incorrect contentsp. 969

When a message with semantically incorrect contents is received, the UE shall perform the foreseen reactions of the procedural part of subclause D.2. If, however no such reactions are specified, the UE shall ignore the message.
The network should follow the same procedure.

EVoid

$  Change historyp. 971


Up   Top