6.2.8 Match report procedure for open 5G ProSe direct discovery

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

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

6.2.8.1 General

The purpose of the match report procedure for open 5G ProSe direct discovery is to allow a UE to send a ProSe application code that was matched during the monitoring operation and receive the corresponding ProSe application ID or the updated metadata, if there is no such a mapping stored locally or the metadata index in the ProSe application code indicates the metadata is updated.

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

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

6.2.8.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 ProSe application ID, which resulted in the matched ProSe application code, is still in place;

b) the lower layers have provided a "Monitored PLMN ID" value and UTC time information, along with the discovery message containing a ProSe application code; and

c) the TTL timer T5064 associated with the discovery filter, which resulted in a match event of the ProSe application code, has not expired.

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

a) when there is a match event of one of the ProSe application codes received from the lower layers and the UE does not have a corresponding ProSe application ID already locally stored;

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

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

d) when there is a match event of one of the ProSe application codes received from the lower layers and the UE has a locally stored ProSe application code excluding the metadata index portion located by the locally stored metadata index mask; or

e) when there is a match event of one of the ProSe application codes received from the lower layer and the UE has not checked the MIC for the discovered ProSe application code previously.

The UE initiates the match report procedure for open 5G ProSe direct discovery by sending a MATCH_REPORT message with a new transaction ID and shall set the message contents as follows:

a) the UE shall include the entire PROSE PC5 DISCOVERY message which contains the ProSe application code for which there was a match event;

b) the UE shall set the UTC-based counter 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 application 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 shall be set to the 4 least significant bits of the UTC-based counter contained in the PROSE PC5 DISCOVERY message that contained the ProSe application 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

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 application code for which there was a match event, as specified in 3GPP TS 33.503 [34]; 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 application 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;

c) the UE shall set the monitored PLMN ID to the PLMN ID of the PLMN where the PROSE PC5 DISCOVERY message was received, as provided by the lower layers;

d) if the UE was roaming when the match event occurred, the UE shall set the VPLMN ID to the PLMN ID of the PLMN in which the UE was registered when the match event occurred; and

e) the UE shall set the metadata flag to indicate whether or not it wishes to receive metadata information associated with the ProSe application ID in the MATCH_REPORT_ACK message from the 5G DDNMF.

NOTE 1: A UE can include one or multiple transactions in one MATCH_REPORT message for different ProSe application codes and receive corresponding <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.

NOTE 2: The value of the metadata flag is determined through an indication from upper layers in the original request to monitor for a ProSe application ID.

When the 5G DDNMF receives the MATCH_REPORT message from the UE, the 5G DDNMF checks MIC for the received PROSE PC5 DISCOVERY message as specified in 3GPP TS 33.503 [34].

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

Figure 6.2.8.2.1: Match report procedure

6.2.8.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. If there is no associated UE context, the 5G DDNMF checks with the UDM whether the UE is authorized for open 5G ProSe direct discovery monitoring as described in 3GPP TS 29.503 [10].

The 5G DDNMF shall also check the PLMN ID in the ProSe application code received from the UE. If the PLMN ID in the ProSe application code is not the same of that of the PLMN to which the 5G DDNMF belongs, the 5G DDNMF shall execute the procedures defined in 3GPP TS 29.555 [9]. Otherwise, the 5G DDNMF shall check whether the received ProSe application code is authorized to be transmitted on the monitored PLMN indicated in the Monitored PLMN ID in the received message.

If the ProSe application code is PLMN-specific, the 5G DDNMF shall verify if the PLMN ID in the ProSe application code is the same as the PLMN of the 5G DDNMF. If so, the 5G DDNMF shall map the ProSe application code to the corresponding ProSe application ID from the PLMN-specific database. If the ProSe application code is country-specific, as specified in clause 24.3 of 3GPP TS 23.003 [4], the 5G DDNMF shall check whether the MCC of the PLMN ID part of the ProSe application code corresponds to the country of the 5G DDNMF. If so, the 5G DDNMF shall map the ProSe application code to the corresponding ProSe application ID from the country-specific database. If the ProSe application code is global as specified in clause 24.3 of 3GPP TS 23.003 [4], the 5G DDNMF shall map the ProSe application code to the corresponding ProSe application ID from the global database. If the ProSe application code contains a ProSe application code prefix, the 5G DDNMF maps the ProSe application code prefix to the corresponding ProSe application ID.

The 5G DDNMF shall analyze the ProSe application code received from the UE and determine the validity of the ProSe application code.

NOTE: This might require the 5G DDNMF to execute procedures defined in 3GPP TS 29.555 [9].

The 5G DDNMF shall check if the MIC value and its corresponding UTC-based counter are valid, as defined in 3GPP TS 33.503 [34].

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

If the outcome of above processing is successful, the 5G DDNMF shall send a MATCH_REPORT_ACK message containing a <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 ProSe application ID set to the ProSe application ID provided by the 5G DDNMF and corresponding to the ProSe application code contained in the MATCH_REPORT message;

c) the validity timer T5072 set to indicate for how long this ProSe application ID is valid;

d) the match report refresh timer T5074 set to indicate for how long the UE will wait before sending a new match report for this ProSe application code;

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

f) optionally, the metadata set to the metadata information associated with the ProSe application code received in the MATCH_REPORT message and set the metadata index mask to the metadata index mask allocated by the 5G DDNMF for the ProSe application code received in the MATCH_REPORT message, if the UE has set the metadata flag to indicate that it wishes to receive metadata information associated with the ProSe application ID.

6.2.8.4 Match report procedure completion by the UE

Upon receipt of the MATCH_REPORT_ACK message, if the transaction ID contained in the <match-ack> element matches the value sent by the UE in a MATCH_REPORT message, the UE shall store the mapping between the ProSe application code and ProSe application ID locally, start timers T5072 and T5074 and may inform the upper layers of this match of the ProSe application ID. If the metadata index mask is contained in the MATCH_REPORT_ACK message, the UE shall also store the metadata index mask with the ProSe application code and the ProSe application ID locally. If there is a locally stored mapping between the ProSe application ID and a ProSe application code, the UE shall delete the old mapping. 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.8.5, the UE shall stop timer T5072 if it is running.

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

NOTE 2: The UE can also inform the upper layers if a ProSe application ID is no longer matched, because the validity timer T5072 of the corresponding ProSe application code expires.

NOTE 3: The UE can also inform the upper layers if a ProSe application ID is no longer matched, because the validity timer T5072 of the corresponding ProSe application 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.8.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 the ProSe application code contained in the MATCH_REPORT message is unknown by the 5G DDNMF, the 5G DDNMF shall send the MATCH_REPORT_ACK message with a <match-reject> element with PC3a control protocol cause value #4 "Unknown ProSe application code".

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 open 5G ProSe direct discovery monitoring in the monitored PLMN contained in the MATCH_REPORT message, 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.8.6 Abnormal cases

6.2.8.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 T5064 associated with the 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.

c) Change of PLMN

If a PLMN change occurs before the match report procedure is completed, the procedure shall be aborted.