6.2.9 Match report procedure for restricted 5G ProSe direct discovery model A

24.5543GPPProximity-services (ProSe) in 5G System (5GS) protocol aspectsRelease 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.2.9.1 General

The purpose of the match report procedure is to allow a UE to send a ProSe restricted code that was matched during the monitoring operation and receive the corresponding RPAUID, if there is no such a mapping stored locally.

The UE shall only initiate the match report procedure if it has been authorized for restricted 5G ProSe direct discovery monitoring model A in the monitored PLMN based on the service authorization procedure.

As a result of the match report procedure completing successfully, the UE obtains a RPAUID and potentially other information, which the UE may store locally and pass to the upper layers.

6.2.9.2 Match report procedure initiation

The UE shall meet the following pre-conditions before initiating this procedure:

a) a request from upper layers to monitor for the target RPAUID, which resulted in the matched ProSe restricted code, is still in place;

b) the lower layers have provided UTC time information, along with the discovery message containing the ProSe restricted code; and

c) the TTL timer T5066 associated with the Restricted discovery filter, whose use resulted in a match event of the ProSe restricted code, has not expired.

If the UE is authorized to perform restricted 5G ProSe direct discovery monitoring model A in the monitored PLMN, it should initiate a match report procedure:

a) when there is a match event after applying one of the Restricted discovery filter(s) to a ProSe restricted code received from the lower layers and the UE does not have a corresponding RPAUID already locally stored;

b) when the UE has a locally stored mapping for the ProSe restricted code that resulted in a match event, but the validity timer T5076 of the ProSe restricted code has expired;

c) when the UE has a locally stored mapping for the ProSe restricted code that resulted in a match event, but the match report refresh timer T5077 of the ProSe restricted code has expired;

d) when the UE desires to obtain the metadata associated with the discovered ProSe restricted code; or

e) when the UE has a locally stored mapping for the ProSe restricted code that resulted in a match event, but the UE does not have a running match report refresh timer T5077 for this ProSe restricted code and the UE is directed by the 5G DDNMF to perform the required MIC check via the match report procedure.

NOTE 1: The 5G DDNMF directs the UE to use the match report procedure to perform the MIC check by including the MIC Check Indicator parameter in the DISCOVERY_RESPONSE message.

The UE initiates the match report procedure by sending a MATCH_REPORT message with a new transaction ID and shall set the message contents as follows:

a) the RPAUID set to the UE’s RPAUID which has requested the corresponding monitoring operation that resulted this match event;

b) the discovery type set to "Restricted discovery";

c) the application identity set to the ProSe identifier of the upper layer application that triggered the monitoring operation as specified in clause 5.2.3;

d) if it is not required to check the MIC via the match report procedure, the ProSe restricted code set to the ProSe restricted code for which there was a match event;

e) if it is required to check the MIC via the match report procedure, the entire PROSE PC5 DISCOVERY message that contained the ProSe restricted code for which there was a match event;

f) if it is required to check the MIC via the match report procedure, the UTC-based counter set as follows:

1) the UE shall generate two UTC-based counters with:

i) the first counter composed of:

A) the 27 most significant bits of the UTC-based counter set to the 27 most significant bits of the UTC time provided by the lower layers for the PROSE PC5 DISCOVERY message that contained the ProSe restricted code for which there was a match event encoded as specified in clause 11.2.5;

B) the 28^th most significant bit of the UTC-based counter set to ‘0’; and

C) the 4 least significant bits of the UTC-based counter set to the 4 least significant bits of the UTC-based counter contained in the PROSE PC5 DISCOVERY message that contained the ProSe restricted code for which there was a match event, as specified in 3GPP TS 33.503 [34]; and

ii) the second counter composed of:

B) the 28^th most significant bit of the UTC-based counter set to ‘1’; and

2) then the UE shall select, among the two counters described above, the counter that is nearest to the UTC time provided by the lower layers for the PROSE PC5 DISCOVERY message that contained the ProSe restricted code for which there was a match event encoded as specified in clause 11.2.5 and set the UTC-based counter in the MATCH_REPORT message to that counter; and

g) the metadata flag set to indicate whether or not the UE wishes to receive the latest metadata information associated with the RPAUID in the MATCH_REPORT_ACK message from the 5G DDNMF.

NOTE 2: A UE can include one or multiple transactions in one MATCH_REPORT message for different ProSe restricted codes and receive a corresponding <restricted-match-ack> element or <match-reject> element in the MATCH_REPORT_ACK message for each respective transaction. In the following description of match report procedure, only one transaction is included.

If it is required to check the MIC via the match report procedure, the 5G DDNMF checks MIC for the received PROSE PC5 DISCOVERY message included in the MATCH_REPORT message as specified in 3GPP TS 33.503 [34].

Figure 6.2.9.2.1 illustrates the interaction between the UE and the 5G DDNMF in the match report procedure.

Figure 6.2.9.2.1: Match report procedure for restricted discovery model A

6.2.9.3 Match report procedure accepted by the 5G DDNMF

Upon receiving a MATCH_REPORT message, the 5G DDNMF shall check whether there is an existing context for the UE identified by its SUPI.

The 5G DDNMF shall analyze the ProSe restricted code received from the UE in the MATCH_REPORT message. If the MIC value and its corresponding UTC-based counter are included, the 5G DDNMF shall check whether the MIC value and the UTC-based counter are valid and within the acceptable range respectively as defined in 3GPP TS 33.503 [34]. The 5G DDNMF shall then check in the UE context if the ProSe restricted code matches any restricted discovery filter(s) allocated for the particular application identified by the ProSe identifier received in the MATCH_REPORT message. If such a discovery filter exists, the target RPAUID associated with the filter(s) shall be identified as the corresponding RPAUID for this code. Optionally, the 5G DDNMF may further invoke the procedure defined in 3GPP TS 29.503 [10] to verify if the target RPAUID is allowed to be discovered by the RPAUID of the requesting UE that has sent the MATCH_REPORT message, or to retrieve metadata associated for the target RPAUID if metadata flag is set to "True" in the MATCH_REPORT message and the 5G DDNMF does not have the latest metadata.

If the outcome of the above processing is successful, the 5G DDNMF shall send a MATCH_REPORT_ACK message containing a <restricted-match-ack> element with:

a) the transaction ID set to the value of the transaction ID received in the MATCH_REPORT message from the UE;

b) the RPAUID set to the target RPAUID retrieved from the UE context at the 5G DDNMF which corresponds to the ProSe restricted code contained in the MATCH_REPORT message;

c) the validity timer T5076 set to indicate for how long this ProSe restricted code is valid;

d) the match report refresh timer T5077 to indicate for how long the UE will wait before sending a new match report for this ProSe restricted code if the MIC value and the UTC-based counter are included in the MATCH_REPORT message;

e) the current time set to the current UTC-based time at the 5G DDNMF; and

f) the metadata set to the associated metadata information, if there exists metadata information associated with this target RPAUID and the metadata flag is set to "True" in the MATCH_REPORT message.

If the corresponding PDUID of the target RPAUID does not belong to the HPLMN of the requesting UE, the 5G DDNMF may optionally invoke the procedure defined in 3GPP TS 29.555 [9] to inform the 5G DDNMF of the announcing UE about the match event.

The 5G DDNMF uses the information (e.g. application identity) received from the UE in the MATCH_REPORT message, UE identity in GBA or AKMA information related to TLS tunnel transporting the MATCH_REPORT message, and other information for charging purposes as specified in 3GPP TS 32.277 [45].

6.2.9.4 Match report procedure completion by the UE

Upon receipt of the MATCH_REPORT_ACK message, if the transaction ID contained in the <restricted-match-ack> element matches the value sent by the UE in a MATCH_REPORT message, the UE shall store the mapping between the ProSe restricted code and RPAUID locally, start timers T5076 and T5077 and may inform the upper layers of this match of the RPAUID. Otherwise, the UE shall discard the MATCH_REPORT_ACK message. The UE shall update the ProSe clock (see 3GPP TS 33.503 [34]) to the value of the received current time parameter.

Upon receipt of the MATCH_REPORT_ACK message, if the transaction ID contained in the <match-reject> element matches the value sent by the UE in a MATCH_REPORT message and if the received PC3a control protocol cause value is #5 "Invalid MIC", as specified in clause 6.2.9.5, the UE shall stop timer T5016 if it is running.

NOTE 1: It is an implementation specific choice whether the UE informs the upper layers every time an RPAUID triggers a match event, or only the first time this match occurs.

NOTE 2: The UE can also inform the upper layers if an RPAUID is no longer matched, because the validity timer T5076 of the corresponding ProSe restricted code expires.

NOTE 3: The UE can also inform the upper layers if a ProSe restricted code is no longer matched, because the validity timer T5016 of the corresponding ProSe restricted code is stopped upon receiving MATCH_REPORT_ACK message with a <match-reject> element with PC3a control protocol cause value #5 "Invalid MIC".

6.2.9.5 Match report procedure not accepted by the 5G DDNMF

If the MATCH_REPORT message is not accepted by the 5G DDNMF, the 5G DDNMF sends a MATCH_REPORT_ACK message with a <match-reject> element to the UE including an appropriate PC3a control protocol cause value.

If there is no associated UE context for the SUPI of the UE, the 5G DDNMF shall send the MATCH_REPORT_ACK message with a <match-reject> element with PC3a control protocol cause value #16 "Invalid match event".

If the ProSe restricted code contained in the MATCH_REPORT message does not match any Restricted discovery filter(s) allocated for the requesting UE for the corresponding application, the 5G DDNMF shall send the MATCH_REPORT_ACK message with a <match-reject> element with PC3a control protocol cause value #16 "Invalid match event".

If the check of the MIC contained in the MATCH_REPORT message fails, the 5G DDNMF shall send the MATCH_REPORT_ACK message with a <match-reject> element with PC3a control protocol cause value #5 "Invalid MIC".

If the check of the UTC-based counter contained in the MATCH_REPORT message fails, the 5G DDNMF shall send the MATCH_REPORT_ACK message with a <match-reject> element with PC3a control protocol cause value #6 " Invalid UTC-based counter".

If the UE is not authorized for restricted 5G ProSe direct discovery monitoring, the 5G DDNMF shall send the MATCH_REPORT_ACK message with a <match-reject> element with PC3a control protocol cause value #3 "UE authorization failure".

6.2.9.6 Abnormal cases

6.2.9.6.1 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Indication from the transport layer of transmission failure of MATCH_REPORT message (e.g., after TCP retransmission timeout)

The UE shall close the existing secure connection to the 5G DDNMF, establish a new secure connection and then restart the match report procedure.

b) No response from the 5G DDNMF after the MATCH_REPORT message has been successfully delivered (e.g., TCP ACK has been received for the MATCH_REPORT message)

If the TTL timer T5066 associated with the restricted discovery filter which resulted in a match event has not expired, the UE shall retransmit the MATCH_REPORT message.

NOTE: The timer to trigger retransmission and the maximum number of allowed retransmissions are UE implementation specific.