19.2.7 One-to-many ProSe direct communication/Pre-configured authorisation/Off-network / ProSe Direct Discovery for public safety use / Discoverer UE procedure for group member discovery

36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification

19.2.7.1 Test Purpose (TP)

(1)

with { ProSe-enabled public safety UE being authorized for performing ProSe Direct Communication being provisioned with Radio parameters for when the UE is "not served by E-UTRAN" associated with a geographical area, and, UE out of coverage on the frequency used for sidelink communication and within the pre-set geographical area }

ensure that {

when { When the UE is triggered by an upper layer application to solicit proximity of other UEs in a discovery group }

then { UE performs a Discoverer UE procedure for group member discovery applying full protection on the discovery messages over PC5 utilising DUSK), DUCK and DUIK }

}

19.2.7.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.334, clauses 5.1.1, 10A.2.1, 10A.2.1A, 10A.2.8.1, 10A.2.8.2, TS 33.303, clauses 6.6.3.1, 6.6.3.2, 6.6.7. Unless otherwise stated these are Rel-13 requirements.

[TS 24.334, clause 5.1.1]

The service authorisation for ProSe direct discovery and ProSe direct communication determines whether the UE is authorised to use ProSe direct discovery and ProSe direct communication, in a particular PLMN or when not served by E-UTRAN. In this release of the specification, ProSe direct communication is supported only for Public Safety ProSe-enabled UE. The service authorisation is either:

1) pre-configured in the UE. The pre-configured service authorisation may be stored in the ME, or in the USIM as specified in 3GPP TS 31.102 [17], or in both the ME and the USIM. If both the ME and the USIM contain the same parameters, the values stored in the USIM shall take precedence. The UE shall not use the pre-configured service authorisation if the contents of the USIM indicate that the UE is not authorised to use them (see 3GPP TS 31.102 [17]); or

[TS 24.334, clause 10A.2.1]

The following procedures are defined for the ProSe direct discovery for public safety use:

…

– discoverer UE procedure for group member discovery;

– discoveree UE procedure for group member discovery;

…

Each ProSe-enabled Public Safety UE needs to obtain the security parameters from the ProSe Key Management Function before participating in ProSe direct discovery for public safety use, as specified in 3GPP TS 33.303 [6]. For each given Relay Service Code in UE-to-network relay discovery or Discovery Group ID in group member discovery, the ProSe Key Management Function (PKMF) will provide the following in the security parameters:

– PSDK (Public Safety Discovery Key) and the associated Expiry Time for this PSDK;

– configurations to signal which combination of keys to be used for the discovery process; and

– optionally, if DUCK is to be used, an indication of which PC5_DISCOVERY message fields shall be protected by the DUCK.

After receiving the PSDK from the PKMF for the relay service or discovery group, the UE shall use it to derive specific DUIK, DUCK and DUSK needed to protect the ProSe direct discovery messages for the corresponding public safety use, as specified in 3GPP TS 33.303 [6].

[TS 24.334, clause 10A.2.1A]

The UE shall select the radio resource parameters to be used for ProSe direct discovery as follows:

…

– when the UE is not served by E-UTRAN or when the UE is served by E-UTRAN and intends to use the provisioned ProSe radio resources (i.e. carrier frequency):

1) if the UE can determine itself located in a geographical area, and the UE is provisioned with radio parameters for the geographical area, then the UE shall search for a cell with any PLMN operating the selected provisioned radio resources (i.e. carrier frequency) associated with that geographical area, and:

…

iii) if the UE does not find any such cell in any PLMN, then the UE shall use the provisioned radio resource parameters; or

2) else the UE shall not initiate ProSe direct discovery.

[TS 24.334, clause 10A.2.8.1]

The purpose of the discoverer UE procedure for group member discovery is to enable a ProSe-enabled public safety UE to solicit proximity of other ProSe-enabled public safety UEs in a discovery group, upon a request from upper layers as defined in 3GPP TS 23.303 [2].

[TS 24.334, clause 10A.2.8.2]

The UE is authorised to perform the discoverer UE procedure for group member discovery if:

a) the following is true:

1) the UE is not served by E-UTRAN, is authorised to perform ProSe direct discovery for public safety use discoverer operation when the UE is not served by E-UTRAN as specified in clause 5, and is configured with the radio parameters to be used for ProSe direct discovery for public safety use when not served by E-UTRAN;

…

Figure 10A.2.8.2.1 illustrates the interaction of the UEs in the discoverer UE procedure for group member discovery.

Figure 10A.2.8.2.1: Discoverer UE procedure for group member discovery

When the UE is triggered by an upper layer application to solicit proximity of other UEs in a discovery group, and if the UE is authorised to perform the discoverer UE procedure for group member discovery, then the UE:

…

b) shall obtain a valid UTC time for the discovery transmission from the lower layers and generate the UTC-based counter corresponding to this UTC time as specified in subclause 12.2.2.18;

c) shall generate a PC5_DISCOVERY message for Group Member Discovery Solicitation according to subclause 11.2.5.1. In the PC5_DISCOVERY message for Group Member Discovery Solicitation, the UE:

1) shall set the Discoverer Info parameter to the User Info ID for the group member discovery parameter, configured in clause 5;

2) shall set the Discovery Group ID parameter to the Discovery Group ID parameter identifying the discovery group to be solicited, configured in clause 5;

3) shall set either the Target User Info parameter or the Target Group Info parameter according to the target information provided by the upper layer application; and

4) shall set the UTC-based counter LSB parameter to include the eight least significant bits of the UTC-based counter;

d) shall apply the DUIK, DUSK, or DUCK with the associated Encrypted Bitmask, along with the UTC-based counter to the PC5_DISCOVERY message for whichever security mechanism(s) configured to be applied, e.g. integrity protection, message scrambling or confidentiality protection of one or more above parameters, as specified in 3GPP TS 33.303 [6]; and

e) shall pass the resulting PC5_DISCOVERY message for Group Member Discovery Solicitation to the lower layers for transmission over the PC5 interface with an indication that the message is for public safety use.

The UE shall ensure that it keeps on passing the same PC5_DISCOVERY message to the lower layers for transmission with an indication that the message is for public safety use until the UE is triggered by an upper layer application to stop soliciting proximity of other UEs in a discovery group, or until the UE stops being authorised to perform the discoverer UE procedure for group member discovery. How this is achieved is left up to UE implementation.

Upon reception of a PC5_DISCOVERY message for Group Member Discovery Response according to subclause 11.2.5.1, for the target Discovery Group ID of the discovery group to be discovered, the UE shall use the associated DUSK, if configured, and the UTC-based counter obtained during the monitoring operation to unscramble the PC5_DISCOVERY message as described in 3GPP TS 33.303 [6]. Then, if a DUCK is configured, the UE shall use the DUCK and the UTC-based counter to decrypt the configured message-specific confidentiality-protected portion, as described in 3GPP TS 33.303 [6]. Finally, if a DUIK is configured, the UE shall use the DUIK and UTC-based counter to verify the MIC field in the unscrambled PC5_DISCOVERY message for Group Member Discovery Response.

Then if the Discovery Group ID parameter of the PC5_DISCOVERY message for Group Member Discovery Response is the same as the Discovery Group ID parameter of the PC5_DISCOVERY message for Group Member Discovery Solicitation, the UE shall consider that other UE in the discovery group the UE seeks to discover has been discovered.

[TS 33.303, clause 6.6.3.1]

There are two types of ProSe Public Safety Discovery described in TS 23.303 [2]: Relay Discovery (including the additional Discovery messages) and Group Member Discovery. The security measures for both of these are identical and are reusing the following aspects:

– the key provisioning mechanism that ProSe one-to-many communication uses, whereby a root key is fetched (the PGK – see subclause 6.2.3.1 of the present specification) along with associated security information; and

– the mechanisms defined for restricted discovery in terms of protecting the discovery messages over the air (see subclause 6.1.3.4.3 of the present specification with the needed DUIK, DUCK and DUSKs derived from the root key). It is optional to support scrambling for Public Safety Discovery.

Like open and restricted discovery, ProSe Public Safety Discovery also uses a UTC-based counter (see step 9 in clause 6.1.3.3) to provide freshness for the protection of the restricted discovery message on the PC5 interface. The parameters CURRENT_TIME and MAX_OFFSET are also provided to the UE from the PKMF to ensure that the obtained UTC-based counter is sufficiently close to real time to protect against replays.

[TS 33.303, clause 6.6.3.2]

The Public Safety Discovery Key (PSDK) is the root key that is used for the protection of the Pubic Safety Discovery messages. It is identified by an 8-bit PSDK ID and each PSDK is associated with one or more Relay Service Codes and/or Discovery Group IDs. This association is achieved by allocating a 24-bit Key Type ID to the Relay Service Codes (RSCs) and Discovery Group IDs during the Key Request/Key Response procedure. The Key Type ID is also included in the MIKEY message, so a delivered PSDK can be associated with the correct RSCs and/or Discovery Group IDs.

NOTE: The allocation of RSC and/or Discovery Group ID to a particular Key Type ID is specific to a UE and does not need to be common across all UEs.

When the PSDKs are provided to the UE, they shall be provided with an Expiry Time. The Expiry Time of the PSDK needs to be set such that the keys for later periods have a longer expiration period. Each PSDKs for each Key Type ID shall be associated with a different Expiry Time value.

All expired PSDK, except the most recently expired of the PSDK(s), should be deleted.

Public Safety discovery also uses the PMK and PMK ID for the MIKEY messages as described in subclauses 6.2.3.1 and 6.2.3.2 of the present specification.

[TS 33.303, clause 6.6.7]

The protection of ProSe Public Safety Discovery Message over PC5 is very similar to that of Restricted Discovery. When sending and receiving a discovery message, the UE uses the PSDK that has not expired (using the time in the UTC based counter associated with the discovery slot to check expiry) and has the earliest expiration time to derive the needed subkeys for the security of that message.

In order to protect the discovery messages over PC5, the UE first calculates the necessary (as indicated in the security meta-data) DUSK, DUCK and DUIK for the particular discovery using the appropriate PSDK. To this end, a KDF is used to derive each of the keys indicated in the security meta-data, as follows:

– If the security meta-data indicates a DUSK should be used, then the UE derives the DUSK from the PSDK using a KDF as in Annex A.8.

– If the security meta-data indicates a DUCK should be used, and an Encrypted_bits_mask is included, then the UE derives the DUCK from the PSDK using a KDF as in Annex A.8

If the security meta-data indicates a DUIK should be used, then the UE derives the DUIK from the PSDK using a KDF as in Annex A.8.

…

A sending UE then follows subclause 6.1.3.4.3.2, while a receiving UE follows subclause 6.1.3.4.3.3 except that it never sends the discovery message to the ProSe Function for MIC checking.

19.2.7.3 Test description

19.2.7.3.1 Pre-test conditions

System Simulator:

SS-UE

– SS-UE1.

– As defined in TS 36.508 [18], configured for and operating as ProSe Direct Communication transmitting and receiving device.

GNSS simulator (optional).

NOTE: For operation in off-network environment, it shall be ensured that after the UE is powered up it considers the geographical area as being one of the geographical areas set in the USIM for operation when UE is "not served by E-UTRAN". This can be done by usage of a GNSS simulator, or some suitable MMI action.

UE:

– ProSe related configuration

– The UE is authorised to perform ProSe Direct Communication; The UE is equipped with a USIM containing values shown in Table 19.2.7.3.1-1, and, relevant to each of the supported services values as specified in TS 36.508 [18], section 4.9.3.1 (e.g. Direct Communication Radio Parameters and geographical area when UE is "not served by E-UTRAN", ProSe Layer-2 Group ID, etc.).

Table 19.2.7.3.1-1: USIM Configuration

USIM field	Value
EFUST	Service n°101 (ProSe) supported.
EFPST	Service n°3 (ProSe Direct Communication radio parameters) supported.
	Service n°6 (ProSe policy parameters) supported.
	Service n°7 (ProSe group counter) supported.
EFAD	b3=1: the ME is authorized to use the parameters stored in the USIM or in the ME for ProSe services for Public Safety usage.
EFPROSE_RADIO_ANN	FFS: b1=1 indicates that the UE is authorised to perform ProSe direct discovery model A announcing when not served by E-UTRAN. b2=0 indicates that the UE is not authorised to perform ProSe direct discovery model B discoverer operation when not served by E-UTRAN b2=1 indicates that the UE is authorised to perform ProSe direct discovery model B discoverer operation when not served by E-UTRAN.
EFPROSE_RADIO_MON	FFS: b1=1 indicates that the UE is authorised to perform ProSe direct discovery model A monitoring when not served by E-UTRAN. b2=0 indicates that the UE is not authorised to perform ProSe direct discovery model B discoveree operation when not served by E-UTRAN b2=1 indicates that the UE is authorised to perform ProSe direct discovery model B discoveree operation when not served by E-UTRAN.
EFPROSE_POLICY	FFS
EFPROSE_GC	FFS: ProSe Layer-2 Group ID PTK ID Counter
EFPROSE_RELAY_DISCOVERY	FFS: The UE is preconfigured with PSDK, Bitmask of keys: b1=1 indicates that DUSK is to be used b2=1 indicates that DUCK is to be used b3=1 indicates that DUIK is to be used and DUCK encryption bitmask
EFPROSE_GM_DISCOVERY	FFS

– The UE has a Public Safety Discovery Key (PSDK) with not expired validity timer allowing for the calculation of the various keys needed for applying protection on the discovery messages over PC5 (Discovery User Scrambling Key (DUSK), Discovery User Confidentiality Key (DUCK) and Discovery User Integrity Key (DUIK)).

– For operation in off-network environment, it shall be ensured that after the UE is powered up it considers the geographical area as being one of the geographical areas set in the USIM for operation when UE is "not served by E-UTRAN". If this is not done by using n GNSS simulator then the UE needs to be preconfigured via a suitable MMI action.

Preamble:

– The UE is in state Switched OFF (state 1) according to TS 36.508 [18].

19.2.7.3.2 Test procedure sequence

Table 19.2.7.3.2-1: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Power up the UE.	–	–	–	–
2	Force the UE upper layer application corresponding to ProSe Application ID px_ProSeAnnApplicationIdentity2 to solicit proximity of other UEs in a discovery group.	–	–	–	–
–	EXCEPTION: Step 3 is repeated 10 times.	–	–	–	–
3	Check: Does the UE transmit in the next transmission period a PC5_DISCOVERY message for Group Member Discovery Solicitation applying DUIK, DUSK, and DUCK with the associated Encrypted Bitmask, along with the UTC-based counter to the PC5_DISCOVERY message?	–>	PC5_DISCOVERY	1	P
4	SS-UE1 transmits a PC5_DISCOVERY message for Group Member Discovery Response applying DUIK, DUSK, and DUCK with the associated Encrypted Bitmask, along with the UTC-based counter to the PC5_DISCOVERY message and including the target Discovery Group ID of the discovery group to be discovered in step 3.	<–	PC5_DISCOVERY	–	–

19.2.7.3.3 Specific message contents

Table 19.2.7.3.3-1: PC5_DISCOVERY (step 3 Table 19.2.7.3.2-1)

Derivation path: 36.508 [18], Table 4.7F.1-5B.

Table 19.2.7.3.3-2: PC5_DISCOVERY (step 4 Table 19.2.7.3.2-1)

Derivation path: 36.508 [18], Table 4.7F.1-5C.