10 ProSe direct communication

24.3343GPPProximity-services (ProSe) User Equipment (UE) to ProSe function protocol aspectsRelease 17Stage 3TS

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

10.1 General

This clause describes the procedures at the UE, and between UEs, for ProSe direct communication over the PC5 interface.

When served by E-UTRAN, the UE shall be authorised for ProSe direct communication in the registered PLMN based on the service authorisation procedure as specified in clause 5, before initiating ProSe direct communication.

When not served by E-UTRAN, the UE shall be authorised for ProSe direct communication for "not served by E-UTRAN" based on the service authorisation procedure as specified in subclause 5, before initiating ProSe direct communication.

10.2 One-to-many ProSe direct communication

10.2.1 General

One-to-many ProSe direct communication is applicable only to ProSe-enabled Public Safety UEs. One-to-many ProSe direct communication can only apply when the UE is:

a) served by E-UTRAN and authorised for ProSe direct communication in the registered PLMN;

b) not served by E-UTRAN, and authorised for ProSe direct communication for "not served by E-UTRAN"; or

c) in EMM-IDLE mode and in limited service state as specified in 3GPP TS 23.122 [24] and authorised for ProSe direct communication when "not served by E-UTRAN", if the reason for the UE being in limited service state is one of the following:

i) the UE is unable to find a suitable cell in the selected PLMN as specified in 3GPP TS 36.304 [23];

ii) the UE received an ATTACH REJECT message or a TRACKING AREA UPDATE REJECT message or a SERVICE REJECT message with the EMM cause #11 "PLMN not allowed" as specified in 3GPP TS 24.301 [11] or a LOCATION UPDATING REJECT message or a GPRS ATTACH REJECT message or ROUTING AREA UPDATE REJECT message or SERVICE REJECT message with cause #11 "PLMN not allowed" as specified in 3GPP TS 24.008 [30]; or

iii) the UE received an ATTACH REJECT message or a TRACKING AREA UPDATE REJECT message or a SERVICE REJECT message with the EMM cause #7 "EPS services not allowed" as specified in 3GPP TS 24.301 [11] or a LOCATION UPDATING REJECT message or a GPRS ATTACH REJECT message or ROUTING AREA UPDATE REJECT message or SERVICE REJECT message with cause #7 "GPRS services not allowed" as specified in 3GPP TS 24.008 [30].

Upon receiving a request from upper layers to send or receive data for ProSe direct communication in a given group, the UE shall initiate the procedure for ProSe direct communication. For case a, the UE shall perform ProSe direct communication procedures specified in subclause 10.2.2. For case b and c, the UE shall perform ProSe direct communication procedures specified in subclause 10.2.3.

If the UE is camped on an E-UTRAN cell not operating on the carrier frequency provisioned for ProSe direct communication which indicates that ProSe direct communication is supported by the network, the UE can perform either ProSe direct communication procedures specified in subclause 10.2.2 or ProSe direct communication procedures specified in subclause 10.2.3.

The UE shall obtain the ProSe direct communication policy parameters for that group as specified in subclause 5, except for the eMBMS content to be relayed by one-to-many ProSe direct communication as specified in subclause 10.2.4.2.

If the ProSe direct communication policy parameters indicate that the UE is configured to use IPv6 for that group, the UE shall auto-configures a link local IPv6 Address following procedures defined in RFC 4862 [15]. This address can only be used as the source IP address for one-to-many ProSe direct communication.

If the ProSe Direct communication policy parameters group indicate that the UE is configured to use IPv4 for that group, then the UE shall:

– use the configured IPv4 address for that group as source address; or

– if there is no configured IPv4 address for that group, use Dynamic Configuration of IPv4 Link-Local Addresses as specified in IETF RFC 3927 [16].

10.2.2 ProSe direct communication facilitated by serving E-UTRAN

When the UE is served by E-UTRAN and intends to use the ProSe radio resources (i.e. carrier frequency) provided by an E-UTRAN cell, the UE requests the parameters from the lower layers for transmitting or receiving ProSe direct communication (see 3GPP TS 36.331 [12]). When requesting the parameters from the lower layers for transmitting or receiving ProSe direct communication, the UE shall indicate to lower layers the ProSe Per-Packet Reliability (PPPR) value, if received from the upper layers. The UE shall perform direct communication only if the lower layers indicate that ProSe direct communication is supported by the network. If the UE in EMM-IDLE mode has to request resources for ProSe direct communication as specified in 3GPP TS 36.331 [12], the UE shall perform a service request procedure or tracking area update procedure as specified in 3GPP TS 24.301 [11]. Once the radio resources for transmitting or receiving ProSe direct communication are provided by eNodeB as specified in 3GPP TS 36.331 [12], the UE shall start ProSe direct communication.

10.2.3 Procedure for UE to use provisioned radio resources

When the UE is not served by E-UTRAN, the UE shall select the radio parameters to be used for ProSe direct communication as follows:

– if the UE can determine itself located in a geographical area, and the UE is provisioned with radio parameters for the geographical area, the UE shall select the radio parameters associated with that geographical area; or

– in all other cases, the UE shall not initiate ProSe direct communication.

NOTE 1: It is out of scope of the present specification to define how the UE can locate itself in a specific Geographical Area. When the UE is in coverage of a 3GPP RAT it can for example use information derived from the serving PLMN. When the UE is not in coverage of a 3GPP RAT it can use other techniques as determined by local regulations.

Before initiating ProSe direct communication, the UE shall check with lower layers whether the selected radio parameters can be used in the current location without causing interference to other cells as specified in 3GPP TS 36.331 [12], and:

– if the lower layers indicate that the usage would not cause any interference, the UE shall initiate ProSe direct communication; or

NOTE 2: If the lower layers find that there exists a cell operating the provisioned radio resources (i.e., carrier frequency), and the cell belongs to the registered PLMN or a PLMN equivalent to the registered PLMN, and the UE is authorized for ProSe direct communication in this PLMN, the UE can use the radio parameters indicated by the cell as specified in 3GPP TS 36.331 [12].

– else if the lower layers report that one or more PLMNs operate in the provisioned radio resources (i.e. carrier frequency) then:

a) if the following conditions are met:

1) none of the PLMNs reported by the lower layers is the registered PLMN or equivalent to the registered PLMN; and

2) at least one of the PLMNs reported by the lower layers is in the list of authorised PLMNs for ProSe direct communication and provides radio resources for ProSe direct communication as specified in 3GPP TS 36.331 [12];

then the UE shall:

1) if in EMM-IDLE mode, perform PLMN selection triggered by ProSe direct communication as specified in 3GPP TS 23.122 [24]; or

2) else if in EMM-CONNECTED mode, either:

i) perform a detach procedure as specified in 3GPP TS 24.301 [11] and then perform PLMN selection triggered by ProSe direct communication as specified in 3GPP TS 23.122 [24]; or

ii) not initiate ProSe direct communication.

Whether the UE performs i) or ii) above is left up to UE implementation; or

b) else the UE shall not initiate ProSe direct communication.

If the registration to the selected PLMN is successful, the UE shall proceed with the procedure to initiate ProSe direct communication as specified in subclause 10.2.2.

If the UE is performing ProSe direct communication using radio parameters associated with a geographical area and moves out of that geographical area, the UE shall stop performing ProSe direct communication and then:

– if the UE is not served by E-UTRAN or the UE intends to use radio resources for ProSe other than those operated by the serving E-UTRAN cell, the UE shall select appropriate radio parameters for the new geographical area as specified above; or

– if the UE is served by E-UTRAN and intends to use radio resources for ProSe operated by the serving E-UTRAN cell, the UE shall proceed with the procedure to initiate ProSe direct communication when served by E-UTRAN.

10.2.4 One-to-many ProSe direct communication transmission

10.2.4.1 General

When receiving user data from upper layers to be sent to a given group, the transmitting UE shall tag each outgoing protocol data unit with the following information before passing it to the lower layers for transmission:

– a Layer-3 protocol data unit type (see 3GPP TS 36.323 [37]) set to:

a) IP packet; or

b) Address Resolution Protocol packet;

– the Source Layer-2 ID set to the ProSe UE ID assigned from the ProSe Key Management Function or self-assigned by the UE;

– the Destination Layer-2 ID set to the ProSe Layer-2 Group ID;

– the ProSe Per-Packet Priority associated with the protocol data unit; and

– the ProSe Per-Packet Reliability (PPPR), if received from the upper layers.

The UE shall choose from a range of eight possible values to indicate the required ProSe Per-Packet Priority related to the lower layer handling of this packet data unit. The ProSe Per-Packet Priority is selected by the application layer based on criteria that are outside the scope of this specification, and is independent of the ProSe Layer-2 Group ID, which is used as the Layer 2 destination address for this packet data unit.

10.2.4.2 eMBMS traffic relay

A ProSe UE-to-network relay UE acting as an eMBMS traffic relay shall use one-to-many ProSe direct communication to broadcast the eMBMS traffic received from the network only if the following conditions are met:

– the ProSe UE-to-network relay UE has detected the TMGI value which it has been requested to monitor during the TMGI monitoring request procedure as specified in subclause 10.5; and

– the ProSe UE-to-network relay UE has announced the PC5_DISCOVERY message for Relay Discovery Additional Information, which includes the detected TMGI value and the corresponding ProSe Layer 2 Group ID to be used for the one-to-many communication packets carrying the relayed eMBMS traffic associated with this TMGI value.

For eMBMS traffic relayed by the ProSe UE-to-network relay UE, the ProSe UE-to-network relay UE uses the ProSe Per-Packet Priority that is included in TMGI_MONITORING_REQUEST message to determine the ProSe Per-Packet Priority value to be applied for the one-to-many communication packets corresponding to that TMGI when they are relayed over PC5.

NOTE: It is assumed that the remote UE receives the QCI associated with the TMGI at the application layer along with an associated priority value that the application layer in the remote UE maps into a ProSe Per-Packet Priority.

For eMBMS traffic relayed by the ProSe UE-to-network relay UE, bearer-level security mechanisms specified in 3GPP TS 33.303 [6] shall not be applied.

The ProSe UE-to-network relay UE acting as an eMBMS traffic relay shall stop the one-to-many ProSe direct communication, if any of the following conditions is met:

– the TMGI value corresponding to the relayed eMBMS traffic can no longer be detected by the ProSe UE-to-network relay UE; or

– There is no longer any remote UE requesting to monitor the TMGI value corresponding to the relayed eMBMS traffic, i.e., the T4105 timer for this TMGI (see subclause 10.5) expires.

10.3 PC3ch Control Protocol for ProSe direct communication

10.3.1 Transport protocol for PC3ch Control Protocol for ProSe direct communication

The UE and ProSe Function CTF (ADF) shall use HTTP 1.1 as specified in IETF RFC 7230 [18] and IETF RFC 7231 [19] as the transport protocol for messages transmitted over the PC3ch interface. The ProSe messages described here shall be included in the body of either an HTTP request message or an HTTP response message. The following rules apply:

a) The UE initiates ProSe transactions with an HTTP request message containing the PC3ch request(s).

b) The ProSe Function CTF (ADF) responds to the requests with an HTTP response message containing the PC3ch response(s) for the PC3ch request(s); and

c) HTTP POST methods are used for PC3ch procedures.

Optionally, the operator can configure the UE with configuration parameters for establishment of the PDN connection for reaching the HPLMN ProSe Function. If the UE is configured with the configuration parameter for establishment of the PDN connection for reaching the HPLMN ProSe Function (see 3GPP TS 24.333 [9]):

a) if a PDN connection for reaching the HPLMN ProSe Function is not established yet, the UE shall establish the PDN connection for reaching the HPLMN ProSe Function according to the UE configuration and shall send the HTTP request message via the PDN connection for reaching the HPLMN ProSe Function; and

b) if a PDN connection for reaching the HPLMN ProSe Function is already established (e.g. either due to other ProSe feature or due to other application), the UE shall send the HTTP request message via the PDN connection for reaching the HPLMN ProSe Function;

10.3.2 Procedures for PC3ch Control Protocol for ProSe direct communication

10.3.2.1 Usage information report list sending procedure

10.3.2.1.1 General

The purpose of the usage information report list sending procedure is to enable a ProSe-enabled Public Safety UE to provide information necessary for composing of charging events related to the ProSe direct communication as defined in 3GPP TS 32.277 [27].

The UE shall perform the usage information report list sending procedure with the Accounting Data Forwarding (ADF) function block of the Charging Trigger Function (CTF) in the ProSe Function (ProSe Function CTF (ADF)) residing in the HPLMN.

The UE shall construct the usage information report based on the policy described in subclause 5.1.3.

10.3.2.1.2 Usage information report list sending procedure initiation

The UE shall perform the usage information report list sending procedure if the UE is in E-UTRAN coverage and if:

a) the following is true:

1) if a usage information report list sending procedure was already performed after beginning of ProSe direct communication, the configured collection period has elapsed since the end of the previous usage information report list sending procedure;

2) if a usage information report list sending procedure was not performed yet after beginning of ProSe direct communication, the configured collection period has elapsed since beginning of ProSe direct communication;

3) the configured reporting window has not elapsed after the configured collection period elapsed;

4) the UE is in the RRC CONNECTED mode; and

5) the UE has usage information for at least one collection period; or

b) the following is true:

3) the configured reporting window has elapsed after the configured collection period elapsed; and

4) the UE has usage information for at least one collection period.

The UE shall initiate the usage information report list sending procedure by sending a USAGE_INFORMATION_REPORT_LIST message to the ProSe Function CTF (ADF).

If the UE is configured with the IP address of the ProSe Function CTF (ADF), the UE shall send the USAGE_INFORMATION_REPORT_LIST message to the configured IP address of the ProSe Function CTF (ADF). If the UE is not configured with the IP address of the ProSe Function CTF (ADF), the UE shall send the USAGE_INFORMATION_REPORT_LIST message to the IP address of the ProSe Function discovered as described in subclause 5.1.2.

In the USAGE_INFORMATION_REPORT_LIST message, the UE:

a) shall include a new transaction ID;

b) shall include the UE identity set to the UE’s IMSI;

c) for each collection period:

1) shall include a sequence number of the usage information report;

2) if the UE is configured to report the time stamps when it went in and out of E-UTRAN coverage during the collection period in the usage information, for each going in or out of E-UTRAN coverage:

A) shall include information whether the UE was in or out of E-UTRAN coverage;

B) shall include the time stamp of the move; and

C) if the UE was in E-UTRAN coverage and the UE is configured to report the list of locations of the UE when in E-UTRAN coverage during the collection period in the usage information, for each camping on a cell or usage of a cell in the EMM-CONNECTED mode:

i) shall include the E-UTRAN cell global identification of the cell; and

ii) shall include the time stamp of beginning of the camping on the cell or of beginning of the usage of the cell in the EMM-CONNECTED mode;

3) if the UE is configured to report the group parameters in the usage information, for each group:

A) shall include the ProSe Layer-2 Group ID;

B) shall include the ProSe Group IP multicast address;

C) if the UE transmitted data during the collection period and the UE is configured to report the time stamps of the first transmission/reception during the collection period in the usage information, shall include the time stamp of the first transmission to the ProSe Group IP multicast address in the collection period;

D) if the UE received data during the collection period and the UE is configured to report the time stamps of the first transmission/reception during the collection period in the usage information, shall include the time stamp of the first reception from the ProSe Group IP multicast address in the collection period;

E) shall include an IP address used by the UE as a source address;

F) shall include the ProSe UE ID;

G) for each transmitter in one-to-many ProSe direct communication, shall include the Source L2 ID and IP address of the transmitter;

H) if the UE is configured to report the amount of data transmitted during the collection period with location information in the usage information, per each in or out of E-UTRAN coverage period and per each E-UTRAN cell used when in E-UTRAN coverage:

i) shall indicate whether the data are sent in or out of E-UTRAN coverage;

ii) if the UE transmitted data in an E-UTRAN cell during an in E-UTRAN coverage period:

– shall include the E-UTRAN cell global identification of the E-UTRAN cell;

– shall include amount of the data transmitted in the E-UTRAN cell;

– if the UE is configured to report the time stamps of the first transmission/reception during the collection period in the usage information, shall include time stamp of the first transmission in the E-UTRAN cell; and

– if the UE is configured to report the radio parameters used for ProSe direct communication (i.e. indicator of which radio resources used and radio frequency used) during the reporting period in the usage information, shall include the indicator of which radio resources were used;

iii) if the UE transmitted data during out of E-UTRAN coverage period:

– shall include amount of the data transmitted during the out of E-UTRAN coverage period; and

iv) if the UE is configured to report the radio parameters used for ProSe direct communication (i.e. indicator of which radio resources used and radio frequency used) during the reporting period in the usage information, shall include the used radio frequency; and

I) if the UE is configured to report the amount of data transmitted during the collection period without location information in the usage information, per each in or out of E-UTRAN coverage period:

i) shall indicate whether the data are sent in or out of E-UTRAN coverage;

ii) if the UE transmitted data during in E-UTRAN coverage period:

– shall include amount of the data transmitted during the in E-UTRAN coverage period;

iii) if the UE transmitted data during out of E-UTRAN coverage period:

– shall include amount of the data transmitted during the out of E-UTRAN coverage period; and

J) if the UE is configured to report the amount of data received during the collection period with location information in the usage information, per each in or out of E-UTRAN coverage period and per each E-UTRAN cell used when in E-UTRAN coverage:

i) shall indicate whether the data are sent in or out of E-UTRAN coverage;

ii) if the UE received data in an E-UTRAN cell during an in E-UTRAN coverage period:

– shall include the E-UTRAN cell global identification of the E-UTRAN cell;

– shall include amount of the data received in the E-UTRAN cell;

iii) if the UE received data during out of E-UTRAN coverage period:

– shall include amount of the data received during the out of E-UTRAN coverage period; and

K) if the UE is configured to report the amount of data received during the collection period without location information in the usage information, per each in or out of E-UTRAN coverage period:

i) shall indicate whether the data are sent in or out of E-UTRAN coverage;

ii) if the UE received data during in E-UTRAN coverage period:

– shall include amount of the data received during the in E-UTRAN coverage period;

iii) if the UE received data during out of E-UTRAN coverage period:

– shall include amount of the data received during the out of E-UTRAN coverage period; and

4) if configured radio parameters for the ProSe direct communication applicable in the geographical area of the UE were used during the collection period, shall include the configured radio parameters for the ProSe direct communication applicable in the geographical area of the UE; and

d) for each application specific data received from upper layers during the collection period, shall include the received application specific data.

Figure 10.3.2.1.2.1 illustrates the interaction of the UE and the ProSe Function CTF (ADF) in the usage information report list sending procedure.

Figure 10.3.2.1.2.1: Usage information report list sending procedure

10.3.2.1.3 Usage information report list sending procedure accepted by the ProSe Function

Upon receiving a USAGE_INFORMATION_REPORT_LIST message from UE, the ProSe Function CTF (ADF) triggers one or more charging data requests according to 3GPP TS 32.277 [27].

If the USAGE_INFORMATION_REPORT_LIST message is accepted by the ProSe Function CTF (ADF), the ProSe Function CTF (ADF) shall send a USAGE_INFORMATION_REPORT_LIST_RESPONSE message to the UE, containing a <response-accept> element with transaction ID set to the value of the transaction ID included in the USAGE_INFORMATION_REPORT_LIST message.

10.3.2.1.4 Usage information report list sending procedure successful completion by the UE

Upon receipt of the USAGE_INFORMATION_REPORT_LIST_RESPONSE message containing a <response-accept> element with transaction ID set to the value of the transaction ID included in the USAGE_INFORMATION_REPORT_LIST message, the usage information report list sending procedure is successfully completed.

10.3.2.1.5 Usage information report list sending procedure not accepted by the ProSe Function

If the USAGE_INFORMATION_REPORT_LIST message is not accepted by the ProSe Function CTF (ADF), the ProSe Function CTF (ADF) shall send a USAGE_INFORMATION_REPORT_LIST_RESPONSE message to the UE. In the USAGE_INFORMATION_REPORT_LIST_RESPONSE message, the ProSe Function CTF (ADF):

1) shall include a <response-reject> element with transaction ID set to the value of the transaction ID included in the USAGE_INFORMATION_REPORT_LIST message; and

2) shall include appropriate cause value.

10.3.2.1.6 Usage information report list sending procedure unsuccessful completion by the UE

Upon receipt of the USAGE_INFORMATION_REPORT_LIST_RESPONSE message containing a <response-reject> element with transaction ID set to the value of the transaction ID included in the USAGE_INFORMATION_REPORT_LIST message, the usage information report list sending procedure is unsuccessfully completed.

If the USAGE_INFORMATION_REPORT_LIST_RESPONSE message contains the cause value set to #3 "Invalid Message Format", the UE shall not perform the usage information report list sending procedure until the UE powers off and powers on again or the USIM is removed.

10.4 One-to-one ProSe direct communication

10.4.1 Overview

This clause describes the PC5 Signalling Protocol procedures between two ProSe-enabled UEs for one-to-one ProSe direct communication.The following PC5 Signalling Protocol procedures are defined:

– direct link setup;

– direct link keepalive;

– direct link release; and

– direct link authentication.

10.4.1A Radio resource selection

The UE shall be authorised for one-to-one ProSe direct communication and obtain the ProSe direct communication policy parameters based on the service authorisation procedure as specified in clause 5 before initiating or participating in any PC5 Signalling Protocol procedures for one-to-one ProSe direct communication.

The UE shall select the radio resources for one-to-one ProSe direct communication as described for one-to-many ProSe direct communication in subclauses 10.2.1, 10.2.2 and 10.2.3.

For one-to-one communication between a remote UE and a ProSe UE-to-network relay UE, if the remote UE receives a lower layers indication that using radio resources for relay communication is not allowed as specified in 3GPP TS 36.331 [12], the remote UE shall abort any ongoing procedures involving a relay (i.e., PC5 signalling Protocol procedures and data transmission/reception) and start an implementation specific timer with value T. While this timer is running, the remote UE shall not initiate any procedures involving a relay. If the remote UE receives lower layers indication that using radio resources for relay communication is allowed as specified in 3GPP TS 36.331 [12], the remote UE shall stop the implementation specific timer and can resume any procedures involving a relay. Otherwise, after the implementation specific timer expires, the remote UE shall release all direct links used for communication with relay(s) locally.

NOTE: The length of T is UE implementation specific.

10.4.2 Direct link setup procedure

10.4.2.1 General

The direct link setup procedure is used to establish a secure direct link between two ProSe-enabled UEs. The UE sending the request message is called the "initiating UE"and the other UE is called the "target UE".

If the direct link setup is for isolated one-to-one ProSe direct communication, i.e. when none of the two UEs is a ProSe UE-to-network relay, both UEs are required to have fetched in advance the public key of the KMS (Key Management Server), and a set of credentials associated with the UE’s identity (as defined in IETF RFC 6507 [39] and IETF RFC 6508 [40]), as specified by 3GPP TS 33.303 [6].

10.4.2.2 Direct link setup procedure initiation by initiating UE

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

– a request from upper layers to establish a direct link with the target UE is received and there is no existing link between the initiating UE and that target UE;

– the link layer identifier for the initiating UE (i.e., Layer 2 ID used for unicast communication) is available (e.g.,pre-configured or self-assigned);

– the link layer identifier for the target UE (i.e., Layer 2 ID used for unicast communication) is available to the initiating UE (e.g., pre-configured or obtained via ProSe direct discovery); and

– the initiating UE is either authorised for ProSe direct communication in the serving PLMN, or has a valid authorization for ProSe direct communication when not served by E-UTRAN.

The initiating UE initiates the direct link setup procedure by generating a DIRECT_COMMUNICATION_REQUEST message with:

– the User Info set to:

– the initiating UE’s User Info received from upper layers if the target UE is not a ProSe UE-to-network relay UE;

– the PRUK ID received from the PKMF if the target UE is a ProSe UE-to-network relay UE, the initiating UE has received a PRUK from the PKMF for this relay, and an attempt to connect to this relay has not been rejected due to the PRUK ID not being recognised;

– the initiating UE’s IMSI if the target UE is a ProSe UE-to-network relay UE and the initiating UE has not received a PRUK from the PKMF for this relay; or

– the initiating UE’s IMSI if the target UE is a ProSe UE-to-network relay UE and the initiating UE has received a PRUK from the PKMF for this relay but an attempt to connect to this relay has been rejected due to the PRUK ID not being recognised;

– an IP Address Config IE set to one of the following values:

– "DHCPv4 Server" if only IPv4 address allocation mechanism is supported by the initiating UE, i.e., acting as a DHCPv4 Server;

– "IPv6 Router" if only IPv6 address allocation mechanism is supported by the initiating UE, i.e., acting as an IPv6 Router;

– "DHCPv4 Server & IPv6 Router" if both IPv4 and IPv6 address allocation mechanisms are supported by the initiating UE; or

– "address allocation not supported" if neither IPv4 nor IPv6 address allocation mechanism is supported by the initiating UE;

– a Link Local IPv6 Address IE formed locally based on IETF RFC 4862 [15] if the IP Address Config IE is set to "address allocation not supported" and the link is setup for isolated one-to-one communication;

NOTE 1: the UE can reuse a Link Local IPv6 IP address for multiple isolated one-to-one communication links.

– a Maximum Inactivity Period IE to indicate the maximum inactivity period of the requesting UE over this direct link;

NOTE 2: The value of Maximum Inactivity Period IE can be calculated based on UE’s local settings, such as keepalive timer T4102 (see 10.4.3), retransmission timer T4101 (see 10.4.3), and maximum number of allowed retransmissions for DIRECT_COMMUNICATION_KEEPALIVE message.

– a Nonce_1 IE set to the 128-bit nonce value generated by the initiating UE for the purpose of session key establishment over this direct link;

– a UE Security Capabilities IE set to indicate the list of algorithms that the initiating UE supports for the security establishment of this direct link;

– an MSB of K_D-sess ID IE set to the most significant 8 bits of the K_D-sessID; and

– Optionally, a K_D ID IE set to the known ID of K_D which was previously established if the initiating UE has an existing K_D with the target UE.

If the direct link setup is for isolated one-to-one ProSe direct communication, the DIRECT_COMMUNICATION_REQUEST message shall also include the following parameters:

– the Signature IE set to the ECCSI signature calculated with the following information elements, as specified in 3GPP TS 33.303 [6]:

– User Info; and

– Nonce_1.

Else if the link setup for remote UE to ProSe UE-to-network relay ProSe direct communication, the DIRECT_COMMUNICATION_REQUEST message shall also include the Relay Service Code IE set to the Relay Service Code of the target relay.

After the DIRECT_COMMUNICATION_REQUEST message is generated, the initiating UE shall pass this message to the lower layers for transmission along with the initiating UE’s Layer 2 ID (for unicast communication) and the target UE’s Layer 2 ID (for unicast communication), and start timer T4100. The UE shall not send a new DIRECT_COMMUNICATION_REQUEST message to the same target UE while timer T4100 is running.

Figure 10.4.2.2.1: Direct link setup procedure

10.4.2.3 Direct link setup procedure accepted by the target UE

Upon receiving a DIRECT_COMMUNICATION_REQUEST message, the target UE shall store the pair of Layer 2 IDs (for unicast communication) used in the transport of this message provided by the lower layers and associate them with a direct link context.

The target UE then checks the User Info IE included in the DIRECT_COMMUNICATION_REQUEST message and determines whether this request can be accepted or not. Then, the target UE examines the IP Address Config IE to see whether there is at least one common IP address configuration option supported by both the initiating UE and the target UE. If the above check is successful, the target UE shall invoke the direct security mode control procedure as specified in subclause 10.4.5 to establish a security association between the target UE and the initiating UE. Only after the completion of link authentication procedure and a successful establishment of the security association, the target UE shall send a DIRECT_COMMUNICATION_ACCEPT message to the initiating UE.

The target UE shall include an IP Address Config IE set to one of the following values:

– "DHCPv4 Server" if only IPv4 address allocation mechanism is supported by the target UE and the target UE is able to act as DHCP server;

– "IPv6 Router" if only IPv6 address allocation mechanism is supported by the target UE and the target UE is able to act as IPv6 Router;

– "DHCPv4 Server & IPv6 Router" if both IPv4 and IPv6 address allocation mechanisms are supported by the target UE; or

– "address allocation not supported" if neither IPv4 nor IPv6 address allocation is supported by the target UE.

If the IP Address Config IE is set to "address allocation not supported" and the received DIRECT_COMMUNICATION_REQUEST message included a Link Local IPv6 Address IE, the target UE shall include a Link Local IPv6 Address IE set to the link-local IPv6 address formed locally.

NOTE: the UE can reuse a Link Local IPv6 IP address for multiple isolated one-to-one communication links.

A ProSe UE-to-network relay UE shall support at least one of the IP address allocation mechanisms.

If the target UE acts as a ProSe UE-to-network relay UE and PDN connection for relaying associated with the ProSe relay UE ID is not established yet or additional PDN connection used for relaying is needed when the ProSe UE-to-network relay UE sends the DIRECT_COMMUNICATION_ACCEPT message to the remote UE, the ProSe UE-to-network relay UE shall initiate the UE requested PDN connectivity procedure by sending the PDN CONNECTIVITY REQUEST message including the APN which is associated with the ProSe Relay UE ID as specified in 3GPP TS 24.301 [11].

If the target UE is a ProSe-UE-to-network relay UE, the target UE shall create an inactivity timer T4108 with the value provided in the Maximum Inactivity Period IE included in the DIRECT_COMMUNICATION_REQUEST message, and start the timer T4108 when it has no more messages to send over the link to be established. Once the timer T4108 is started, if any communication activity occurs before the timer T4108 expires, the UE shall stop the timer T4108 and reset it with the initial value, unless a new value is provided in a Maximum Inactivity Period IE in a DIRECT_COMMUNICATION_KEEPALIVE message.

If the target UE is a ProSe-UE-to-network relay UE, and it has been configured by the serving PLMN to report the IMEI or IMEISV of the remote UE(s) served by the relay based on the service authorisation procedure as specified in clause 5, the ProSe UE-to-network relay UE shall initiate a remote UE information request procedure (as specified in subclause 10.7.2) to request the IMEI or IMEISV of the remote UE upon successful direct link establishment.

10.4.2.4 Direct link setup procedure completion by the initiating UE

Upon receipt of the DIRECT_COMMUNICATION_ACCEPT message, the initiating UE shall stop timer T4100. From this time onward the initiating UE shall use the established link for all one-to-one communication (including additional PC5 Signalling messages) to the target UE.

10.4.2.5 Direct link setup procedure not accepted by the target UE

If the direct link setup request cannot be accepted, the target UE shall send a DIRECT_COMMUNICATION_REJECT message. The DIRECT_COMMUNICATION_REJECT message contains a PC5 Signalling Protocol cause value set to one of the following cause values:

#1 Direct communication to target UE not allowed;

#2 Authentication failure;

#3 Conflict of Layer 2 ID for unicast communication is detected;

#4 Lack of resources for proposed link;

#5 IP version mismatch; or.

#6 Link setup failure due to other errors.

If the target UE is not allowed to accept this request.e.g. based on operator policy or service authorisation provisioning, the target UE shall send a DIRECT_COMMUNICATION_REJECT message containing PC5 Signalling Protocol cause value #1 "Direct communication to target UE not allowed".

If verification of the signature parameter included in the DIRECT_COMMUNICATION_REQUEST message fails at the target UE (see subclause 10.4.5), the target UE shall send a DIRECT_COMMUNICATION_REJECT message containing PC5 Signalling Protocol cause value #2 "Authentication failure".

If the direct link setup fails due to the problems in direct link authentication procedure (see 10.4.5), the target UE shall send a DIRECT_COMMUNICATION_REJECT message containing PC5 Signalling Protocol cause value #2 "Authentication failure".

For a received DIRECT_COMMUNICATION_REQUEST message from a Layer 2 ID (for unicast communication), if the target UE already has an existing link established to the UE known to use this Layer 2 ID or is currently processing a DIRECT_COMMUNICATION_REQUEST message from the same Layer 2 ID, but with User Info different from the User Info IE included in this new incoming message, the target UE shall send a DIRECT_COMMUNICATION_REJECT message containing PC5 Signalling Protocol cause value #3 "Conflict of Layer 2 ID for unicast communication is detected".

If the direct link setup fails due to the congestion problems or other temporary lower layer problems causing resource constraints, the target UE shall send a DIRECT_COMMUNICATION_REJECT message containing PC5 Signalling Protocol cause value #4 "Lack of resources for proposed link".

In case of ProSe UE-to-network relay UE, if the remote UE intends to use the ProSe UE-to-network relay UE for mission critical communication (e.g. MCPTT), but the ProSe UE-to-network relay UE does not support IPv6 address allocation scheme as a router, the target UE (i.e. ProSe UE-to-network relay UE) shall reject the request with DIRECT_COMMUNICATION_REJECT message containing PC5 Signalling Protocol cause value #5 "IP version mismatch".

NOTE 1: To determine if remote UE intends to use the ProSe UE-to-network relay UE for mission critical communication (e.g. MCPTT), the target UE can examine the Layer 2 destination address of the transport of DIRECT_COMMUNICATION_REQUEST message to check whether it matches the ProSe Relay UE ID which has been associated to mission critical communication (e.g. MCPTT) or examine the User Info included in the DIRECT_COMMUNICATION_REQUEST message.

For other reasons that causing the failure of link establishment, the target UE shall send a DIRECT_COMMUNICATION_REJECT message containing PC5 Signalling Protocol cause value #6 "Link setup failure due to other errors".

Upon receipt of the DIRECT_COMMUNICATION_REJECT message, the initiating UE shall stop timer T4100 and abort the direct link setup procedure. If the cause value in the DIRECT_COMMUNICATION_REJECT message is #1 "Direct communication to target UE not allowed" or #4 "Lack of resources for proposed link", then the UE shall not attempt to start direct link setup with the same target UE at least for a time period T, and if the initiating UE is a remote UE requesting link setup to a ProSe UE-to-network relay UE, it shall initiate the relay reselection procedure as specified in subclause 10A.2.13.

NOTE 2: The length of time period T is UE implementation specific and can be different for the case when the UE receives PC5 Signalling Protocol cause value #1 "Direct communication to target UE not allowed" or when the UE receives cause value #4 "Lack of resources for proposed link".

10.4.2.6 Abnormal cases

10.4.2.6.1 Abnormal cases at the initiating UE

If timer T4100 expires, the initiating UE shall retransmit the DIRECT_COMMUNICATION_REQUEST message and restart timer T4100. After reaching the maximum number of allowed retransmissions, the initiating UE shall abort the direct link setup procedure, may notify the upper layer that the target UE is unreachable, and if the initiating UE is a remote UE requesting link setup to a ProSe UE-to-network relay UE, it shall initiate the relay reselection procedure as specified in subclause 10A.2.4.

NOTE: The maximum number of allowed retransmissions is UE implementation specific.

If the need to establish a link no longer exists before the procedure is completed, the initiating UE shall abort the procedure.

10.4.2.6.2 Abnormal cases at the target UE

For a received DIRECT_COMMUNICATION_REQUEST message from a Layer 2 ID (for unicast communication), if the target UE already has an existing link established to the UE known to use this Layer 2 ID and the new request contains an identical User Info as the known user, the UE shall process the new request. However, the target UE shall only delete the existing link context after the new link setup procedure succeeds, or the link keepalive procedure as described in subclause 10.4.3 fails.

If the inactivity timer T4108 expires, if the target UE is a ProSe UE-to-network relay UE, it shall initiate the direct link release procedure specified in subclause 10.4.4 with the release reason #3 "Direct connection is not available any more". Otherwise, the target UE may:

A) initiate is own keepalive procedure to check the link; or

B) initiate the direct link release procedure specified in subclause 10.4.4 with the release reason #3 "Direct connection is not available any more".

Whether the UE chooses A or B is left to UE implementation.

10.4.3 Direct link keepalive procedure

10.4.3.1 General

The direct link keepalive procedure is used to maintain the direct link between two ProSe-enabled UEs, i.e., check that the link between the two UEs is still viable. The procedure can be initiated by only one UE or both of the UEs in the established direct link. If the direct link is used for one-to-one communication between a remote UE and a ProSe UE-to-network relay UE, only the remote UE shall initiate the link keepalive procedure.

In this procedure, the UE sending the DIRECT_COMMUNICATION_KEEPALIVE message is called the "requesting UE" and the other UE is called the "peer UE".

10.4.3.2 Direct link keepalive procedure initiation by the requesting UE

The requesting UE manages a keepalive timer T4102 and a keepalive counter for this procedure. The keepalive timer T4102 is used to trigger the periodic initiation of the procedure. It is started or restarted whenever the UE receives a PC5 Signalling message or PC5 user plane data from the peer UE over this link. The keepalive counter is set to an initial value of zero after link establishment.

The requesting UE may initiate the procedure if:

– a request from upper layers to check the viability of the direct link is received; or

– the keepalive timer T4102 for this link expires.

The requesting UE initiates the procedure by stopping timer T4102 if it is still running and generating a DIRECT_COMMUNICATION_KEEPALIVE message with a Keepalive Counter IE that contains the value of the keepalive counter for this link. Optionally, the initiating UE may include a Maximum Inactivity Period IE to indicate the maximum inactivity period of the requesting UE over this direct link. When a remote UE sends DIRECT_COMMUNICATION_KEEPALIVE message to the ProSe UE-to-network relay UE, this IE shall be included.

After the DIRECT_COMMUNICATION_KEEPALIVE message is generated, the requesting UE shall pass this message to the lower layers for transmission along with the requesting UE’s Layer 2 ID (for unicast communication) and the peer UE’s Layer 2 ID (for unicast communication), and start retransmission timer T4101.

Figure 10.4.3.2.1: Direct link keepalive procedure

10.4.3.3 Direct link keepalive procedure accepted by the peer UE

Upon receiving a DIRECT_COMMUNICATION_KEEPALIVE message, the peer UE shall respond with a DIRECT_COMMUNICATION_KEEPALIVE_ACK message including the Keepalive Counter IE set to the same value as that received in the DIRECT_COMMUNICATION_KEEPALIVE message.

If a Maximum Inactivity Period IE is included in the DIRECT_COMMUNICATION_KEEPALIVE message, the peer UE shall stop the inactivity timer T4108 if it is running, and restart the timer T4108 with the value provided in the IE, If any communication activity occurs in this direct link before the timer T4108 expires, the UE shall stop the timer T4108 and reset it with the initial value.

10.4.3.4 Direct link keepalive procedure completed by the requesting UE

Upon receiving a DIRECT_COMMUNICATION_KEEPALIVE_ACK message, the requesting UE shall stop retransmission timer T4101, start keepalive timer T4102 and increment the keepalive counter for this link.

10.4.3.5 Abnormal cases

10.4.3.5.1 Abnormal cases at the requesting UE

If retransmission timer T4101 expires, the requesting UE shall initiate the transmission of the DIRECT_COMMUNICATION_KEEPALIVE message again with the last used keepalive counter value and restart timer T4101. If no response is received from the peer UE after reaching the maximum number of allowed retransmissions, the requesting UE shall abort the link keepalive procedure and initiate the direct link release procedure (see subclasue 10.4.4) instead, and if the requesting UE is a remote UE, it shall initiate the relay reselection procedure as specified in subclause 10A.2.13.

NOTE: The maximum number of allowed retransmissions is UE implementation specific.

If the need to use this direct link no longer exists before the direct link keepalive procedure is completed, the requesting UE shall abort the procedure and start a direct link release procedure (see subcaluse 10.4.4) instead.

10.4.3.5.2 Abnormal cases at the peer UE

If the inactivity timer T4108 expires, if the peer UE is a ProSe UE-to-network relay UE, it shall initiate the direct link release procedure specified in 10.4.4 with the release reason #3 "Direct connection is not available any more". Otherwise, the peer UE may:

A) initiate is own keepalive procedure to check the link; or

B) initiate the direct link release procedure specified in 10.4.4 with the release reason #3 "Direct connection is not available any more".

Whether the UE chooses A or B is left to UE implementation.

10.4.4 Direct link release procedure

10.4.4.1 General

The Direct link release procedure is used to release a secure direct link between two ProSe-enabled UEs. The link can be released from either end points. The UE sending the DIRECT_COMMUNICATION_RELEASE message is called the "releasing UE"and the other UE is called the "peer UE".

When the direct link between a remote UE and a ProSe UE-to-network relay UE is released, the ProSe-UE-to-network relay UE shall perform the Remote UE report procedure as specified in 3GPP TS 24.301 [11].

10.4.4.2 Direct link release procedure initiation by the releasing UE

The releasing UE shall initiate the procedure if:

– a request from upper layers to release a direct link with the peer UE which uses a known Layer 2 ID (for unicast communication) is received and there is an existing link between those two UEs; or

– the peer UE has been non-responsive, e.g., unable to complete the direct link keepalive procedure.

The releasing UE initiates the direct link release procedure by generating a DIRECT_COMMUNICATION_RELEASE message with a Release Reason IE indicating one of the following cause values:

#1 Direct Communication to peer UE no longer needed;

#2 Direct communication with the peer UE is no longer allowed; or

#3 Direct connection is not available any more.

After the DIRECT_COMMUNICATION_RELEASE message is generated, the releasing UE shall pass this message to the lower layers for transmission along with the releasing UE’s Layer 2 ID (for unicast communication) and the peer UE’s Layer 2 ID (for unicast communication). The releasing UE shall release the direct link locally if the release reason is #3 "Direct connection is not available any more". Otherwise, the releasing UE shall start timer T4103.

Figure 10.4.4.2.1: Direct link release procedure

10.4.4.3 Direct link release procedure accepted by the peer UE

Upon receiving a DIRECT_COMMUNICATION_RELEASE message, the peer UE shall stop timer T4101, timer T4102, timer T4103 or timer T4108 for this link, if any of those timers is running, and abort any other ongoing PC5 Signalling Protocol procedures on this link. The peer UE shall respond with a DIRECT_COMMUNICATION_RELEASE_ACCEPT message. After the message is sent, the peer UE shall remove the context of this direct link and no longer send or receive any messages via this link.

If the cause value in the DIRECT_COMMUNICATION_RELEASE message is "Direct communication with the peer UE is no longer allowed", then the UE shall not attempt to start direct link setup with the releasing UE at least for the time period T and if the peer UE is a remote UE requesting link setup to a ProSe UE-to-network relay UE, it shall initiate the relay reselection procedure as specified in subclause 10A.2.13.

NOTE: The length of time period T is UE implementation specific.

10.4.4.4 Direct link release procedure completion by the releasing UE

Upon receipt of the DIRECT_COMMUNICATION_RELEASE_ACCEPT message, the releasing UE shall stop timer T4103. From this time onward the releasing UE shall no longer send or receive any messages via this link.

10.4.4.5 Abnormal cases

10.4.4.5.1 Abnormal cases at the releasing UE

If retransmission timer T4103 expires, the releasing UE shall initiate the transmission of the DIRECT_COMMUNICATION_RELEASE message again and restart timer T4103. If no response is received from the peer UE after reaching the maximum number of allowed retransmissions, the releasing UE shall release the direct link locally. From this time onward the releasing UE shall no longer send or receive any messages via this link.

NOTE: The maximum number of allowed retransmissions is UE implementation specific.

10.4.5 Direct security mode control procedure

10.4.5.1 General

Security association for a direct link between two ProSe-Enabled UEs is established during the direct link setup procedure or direct link rekeying procedure with the exchange of message contents related to direct security mode establishment. After successful completion of the direct security mode control procedure, the selected security algorithms and keys are used to integrity protect and cipher all PC5 Signalling messages exchanged between the UEs; and are also used to cipher all data plane traffic exchanged between the UEs.

In the rest of this subclause, the UE sending the DIRECT_SECURITY_MODE_COMMAND message is called the "commanding UE"and the other UE is called the "peer UE".

10.4.5.2 Direct security mode control procedure initiation by the commanding UE

A commanding UE may initiate the direct security mode control procedure in response to receiving a DIRECT_COMMUNICATION_REQUEST or a DIRECT_REKEYING_REQUEST message.

If the procedure takes place between a remote UE and a ProSe UE-to-network relay UE and is triggered by a DIRECT_REKEYING_REQUEST to only refresh K_D-sessbut not K_D, then either the ProSe UE-to-network relay UE or the remote UE can act as the commanding UE. Otherwise, if both keys are to be refreshed, the ProSe UE-to-network relay UE shall act as the commanding UE.

To initiate this procedure, the commanding UE shall either identify an existing K_D based on the K_D ID included in the DIRECT_COMMUNICATION_REQUEST or DIRECT_REKEYING_REQUEST message, or derive a new K_D if it either does not share a known K_D with the peer UE or wishes to derive a new K_D, as specified in 3GPP TS 33.303 [6]. In the latter case, the commanding UE shall generate the MSB of K_D ID to ensure that the resultant K_D ID will be unique in the commanding UE. Then, it shall generate a LSB of K_D-sess ID such that the K_D-sess ID formed by combining with the MSB of K_D-sess ID (received in the DIRECT_COMMUNICATION_REQUEST or DIRECT_REKEYING_REQUEST that triggered the direct security mode procedure) is unique within the commanding UE.

Following this, the commanding UE shall generate a 128-bit Nonce_2 value. With K_D, Nonce_2 and Nonce_1 received in the DIRECT_COMMUNICATION_REQUEST or DIRECT_REKEYING_REQUEST message, the commanding UE shall derive K_{D- sess} as specified in 3GPP TS 33.303 [6].

Then, the UE shall construct a DIRECT_SECURITY_MODE_COMMAND message with the following:

– Nonce_2 IE set to Nonce_2;

– the LSB of K_D-sess ID IE set to indicate the least significant 8-bits of K_D-sess ID;

– the UE Security Capabilities IE set to the UE Security Capabilities received in the DIRECT_COMMUNICATION_REQUEST message or DIRECT_REKEYING_REQUEST; and

– the Chosen Algorithms IE set to the algorithms to be used for ciphering and integrity protection.

If the DIRECT_SECURITY_MODE_COMMAND message is used between a remote UE and a ProSe UE-to-network relay UE and the ProSe UE-to-network relay UE received the K_D Freshness parameter from the PKMF, then the ProSe UE-to-network relay UE shall include the following additional parameters in the DIRECT_SECURITY_MODE_COMMAND message to create a new K_D:

– the GPI IE containing the GPI payload if it was received from the ProSe Key Management Function (PKMF);

– the K_D Freshness IE set to the K_D Freshness parameter received from the PKMF; and

– the MSB of K_D ID IE set to the MSB of K_D ID of the new K_D.

If the DIRECT_SECURITY_MODE_COMMAND message is used for isolated one-to-one ProSe direct communication, then the commanding UE shall include the following additional parameters in the DIRECT_SECURITY_MODE_COMMAND message in order to create a new K_D:

– the User Info IE set to the User Info received from upper layers;

– the MSB of K_D ID IE set to the MSB of K_D ID of the new K_D; and

– the Signature IE set to the ECCSI signature value calculated with the following information elements, as specified in 3GPP TS 33.303 [6]:

– User Info;

– Nonce_1; and

– the Encrypted Payload IE set to the SAKKE payload generated as specified in 3GPP TS 33.303 [6].

The commanding UE shall select the integrity protection and ciphering algorithms that will be used and include these choices in the Chosen algorithms IE in the DIRECT SECURITY MODE COMMAND message. The UE shall include the received UE security capabilities that was present in the DIRECT_COMMUNICATION_REQUEST or a DIRECT_REKEYING_REQUEST message that triggered the DIRECT SECURITY MODE COMMAND message.

The commanding UE shall send the DIRECT SECURITY MODE COMMAND message unciphered, but shall integrity protect the message with the new security context. After sending the DIRECT_SECURITY_MODE_COMMAND message, the commanding UE shall start timer T4111 (see figure 10.4.5.2.1).

Figure 10.4.5.2.1: Direct Security mode control procedure

10.4.5.3 Direct security mode control procedure accepted by the peer UE

Upon receipt of the DIRECT_SECURITY_MODE_COMMAND message, the peer UE shall check whether the security mode command can be accepted or not. This is done by performing the integrity check of the message and by checking that the received UE security capabilities have not been altered compared to the latest values that the peer UE sent to the commanding UE in the DIRECT_COMMUNICATION_REQUEST or DIRECT_REKEYING_REQUEST message.

In order to check the integrity, the peer UE needs to create the security context as described in 3GPP TS 33.303 [6]. If the MSB of K_D ID were included in the DIRECT_SECURITY_MODE_COMMAND message then the peer UE shall take one of the following two actions:

– If performing isolated one-to-one ProSe direct communication, the peer UE shall first check the signature included in the SIGN IE of the DIRECT SECURITY MODE COMMAND and then obtain the new K_D from the Encrypted Payload IE; or

– If the peer UE is a remote UE that has received the DIRECT_SECURITY_MODE_COMMAND message from a ProSe UE-to-network relay UE, it shall first replace its PRUK ID and PRUK if a GPI IE was included in the DIRECT_SECURITY_MODE_COMMAND. Finally, the UE shall derive a new K_D, as described in 3GPP TS 33.303 [6].

If MSB of K_D ID was not included in the DIRECT_SECURITY_MODE_COMMAND, then the peer UE shall use either the existing K_D indicated by the K_D ID included in the DIRECT_COMMUNICATION_REQUEST or the currently used one.

The peer UE shall then derive the K_D-sess based on the KD-_sess ID in the same way as the commanding UE. Finally the peer UE shall use the algorithms indicated in the Chosen Algorithms IE.

If the DIRECT_SECURITY_MODE_COMMAND message can be accepted, the peer UE shall send a DIRECT_SECURITY_MODE_COMPLETE message ciphered and integrity protected with the new security context. The DIRECT_SECURITY_MODE_COMPLETE message shall include the 16 least significant bits of the K_D ID if the initiating UE included the MSB of K_D ID in the DIRECT_SECURITY_MODE_COMMAND message.

From this time onward the peer UE shall protect all signalling messages and user data with the new security context.

10.4.5.4 Direct security mode control procedure completion by the commanding UE

Upon receipt of the DIRECT_SECURITY_MODE_COMPLETE message, the commanding UE shall stop timer T4111. If an LSB of K_D ID IE was included in the message, the commanding UE uses this and the MSB of K_D ID it previously sent to form the K_D ID of the new K_D. From this time onwards the commanding UE shall protect all signalling messages and user data with the new security context.

10.4.5.5 Direct security mode control procedure not accepted by the peer UE

If the DIRECT_SECURITY_MODE_COMMAND message cannot be accepted, the peer UE shall send a DIRECT_SECURITY_MODE_REJECT message. The DIRECT_SECURITY_MODE_REJECT message contains a PC5 Signaling Protocol Cause Value IE indicating one of the following cause values:

#7: UE security capabilities mismatch;

#8: Unspecified error; or

#9: Authentication synchronisation error.

If the DIRECT_SECURITY_MODE_COMMAND message cannot be accepted due to a synchronisation error when processing the authentication vector contained in the GPI payload sent by the ProSe UE-to-network relay UE to the remote UE, then the peer UE shall include the RAND and AUTS parameters in the DIRECT_SECURITY_MODE_ REJECT message.

Upon receipt of the DIRECT_SECURITY_MODE_REJECT message, the commanding UE shall stop timer T4111. If the PC5 Signaling Protocol Cause Value IE indicates a synchronisation error and the message contained a RAND and an AUTS, then a ProSe UE-to-network relay may fetch a fresh K_D from the PKMF by sending a Key Request message including RAND and AUTS as specified in 3GPP TS 33.303 [6]. Otherwise the commanding UE shall abort the ongoing procedure that triggered the initiation of the direct security mode control procedure, as specified in subclauses 10.4.2 or 10.4.8.

10.4.5.6 Abnormal cases

10.4.5.6.1 Abnormal cases at the commanding UE

If timer T4111 expires, then

– if the direct security mode control procedure is triggered by a DIRECT_COMMUNICATION_REQUEST message, the commanding UE shall discard any derived keys with Nonce_1 and initiate the transmission of the DIRECT_COMMUNICATION_REJECT message with the PC5 Signaling Protocol Cause Value IE set to #10 "non-responsive peer during the direct security mode procedure"; or

– if the direct security mode control procedure is triggered by a DIRECT_REKEYING_REQUEST message, the commanding UE shall continue to use old keys until those keys are no longer valid.

10.4.5.6.2 Abnormal cases at the peer UE

If the DIRECT_SECURITY_MODE_COMMAND message is malformed, the peer UE shall discard the message.

10.4.6 IP Address configuration

10.4.6.1 General

The IP address configuration procedure is performed after the establishment of the direct link to enable IP connectivity between the UEs at each end of the direct link.

When the IP address configuration procedure for a remote UE completes, the ProSe UE-to-network relay UE shall perform the Remote UE report procedure as specified in 3GPP TS 24.301 [11].

10.4.6.2 Selection of IP version

When neither of the two UEs on the direct link acts as a ProSe UE-to-network relay, the two UEs shall select the IP version (IPv4 or IPv6) to be used based on the following rules:

– if the target UE in the direct link setup procedure (see subclause 10.4.2) has indicated "DHCPv4 Server" in the IP Address Config IE, then the initiating UE in the direct link setup procedure (see subclause 10.4.2) shall initiate the IPv4 address configuration with DHCPv4 procedure acting as a DHCP client;

– if the target UE in the direct link setup procedure has indicated "IPv6 Router" in the IP Address Config IE , then the initiating UE in the direct link setup procedure shall initiate the IPv6 address configuration with IPv6 stateless address auto-configuration acting as an IPv6 host;

– if the target UE in the direct link setup procedure has indicated "DHCPv4 Server & IPv6 Router" in the IP Address Config IE, then the initiating UE in the direct link setup procedure shall choose either IP version and initiate the address configuration procedure, acting as a client or host;

– if the target UE in the direct link setup procedure has indicated "address allocation not supported" in the IP Address Config IE and the initiating UE has indicated "DHCPv4 Server", "IPv6 Router" or "DHCPv4 Server & IPv6 Router" in the IP Address Config IE, then the target UE shall:

a) initiate the IPv4 address configuration with DHCPv4 procedure acting as a DHCP client, if the initiating UE has indicated "DHCPv4 Server";

b) initiate the IPv6 address configuration with IPv6 stateless address auto-configuration acting as an IPv6 host if the initiating UE has indicated "IPv6 Router"; and

c) choose either IP version and initiate the corresponding IP address configuration procedure as a client or host, if if the other UE has indicated "DHCPv4 Server & IPv6 Router"; and

– if both of the UEs has indicated "address allocation not supported" in the IP Address Config IE, then the UEs shall use IPv6 link-local addresses formed locally as defined in RFC 4862 [15].

When one of the two UEs on the direct link acts as a ProSe UE-to-network relay, the two UEs shall select the IP version (IPv4 or IPv6) to be used based on the following rules

– if the ProSe UE-to-network relay UE has indicated "DHCPv4 Server" in the IP Address Config IE, the remote UE shall initiate the IPv4 address configuration with DHCPv4 procedure acting as a DHCP client;

– if the ProSe UE-to-network relay UE has indicated "IPv6 Router" in the IP Address Config IE, the remote UE shall initiate the IPv6 address configuration with IPv6 stateless address auto-configuration acting as an IPv6 host; and

– if the ProSe UE-to-network relay UE has indicated "DHCPv4 Server & IPv6 Router" in the IP Address Config IE, the remote UE shall choose the IP version and initiate the corresponding IP address configuration procedure as a client or host. Especially, if the remote UE intends to use the ProSe UE-to-network relay UE for mission critical communication (e.g. MCPTT), the remote UE shall initiate the IPv6 stateless address auto-configuration acting as an IPv6 host.

10.4.6.3 IPv4 address configuration with DHCPv4

The IPv4 address configuration with DHCPv4 shall be carried out as follow:

1. The DHCP client sends a DHCPDISCOVER message;

2. The DHCP server sends the DHCPOFFER message with the assigned IPv4 address for the client. The IPv4 address provided shall correspond to a local IPv4 address range configured in the DHCP server;

3. When the DHCP client receives the lease offer, it sends a DHCPREQUEST message containing the received IPv4 address.

4. The DHCP server sends a DHCPACK message to the client UE. This message includes the lease duration and any other configuration information that the client might have requested.

5. On receiving the DHCPACK message, the IPv4 address configuration is completed.

NOTE: The DHCPv4 client may skip the DHCPv4 Discovery phase, and send DHCPv4 Request message in broadcast as the first message in accordance with the DHCPv4 renewal process.

If the direct link is setup for one-to-one communication between a remote UE and a UE-to-network relay UE, after the remote UE releases the IPv4 address using DHCPv4 or the IPv4 address lease time expires, the ProSe UE-to-network relay UE shall wait for a relay implementation specific time before allocating the same IPv4 address to another remote UE.

10.4.6.4 IPv6 address configuration with IPv6 stateless address auto-configuration

The IPv6 stateless address auto-configuration protocol procedure shall be carried out as follow:

1. the UE acting as an IP Host shall send a Router Solicitation message in order to solicit a Router Advertisement message as specified in IETF RFC 4862 [15].

2. Upon receiving the Router Solicitation message, the other UE shall send an IPv6 Router Advertisement message as specified in IETF RFC 4862 [15], acting as an advertising interface as specified in IETF RFC 4861 [33]. The Router Advertisement messages shall contain an IPv6 prefix, which is to be combined with the interface identifier to form the IPv6 address.

3. The UE which receives the Router advertisement message retrieves the router’s address from the Source IP address field of the message, and formed its own IP address with the prefix and the interface identifier as specified in IETF RFC 4862 [15].

If the direct link is setup for one-to-one communication between a remote UE and a UE-to-network relay, the UE-to-network relay shall obtain the IPv6 prefix assigned to the remote UE via prefix delegation function from the network as defined in 3GPP TS 23.401 [34] before sending the IPv6 prefix to the remote UE. After the remote UE receives the Router Advertisement message, it constructs a full IPv6 address via IPv6 Stateless Address auto-configuration in accordance with IETF RFC 4862 [15]. However, the remote UE shall not use any identifiers defined in TS 23.003 [4] as the basis for generating the interface identifier. For privacy, the remote UE may change the interface identifier used to generate the full IPv6 address, as defined in 3GPP TS 23.221 [35] without involving the network. The remote UE shall use the auto-configured IPv6 address while sending packets in this implicitly created PDN connection.

If the direct link is setup for one-to-one communication between a remote UE and a UE-to-network relay and support for mission critical applications and policy control for remote UEs is required, the remote UE shall be assigned a /64 IPv6 Prefix from a shorter IPv6 prefix by the UE-to-network relay.

NOTE: In order to support policy control per remote UE, the assignment of a /64 IPv6 Prefix from a shorter IPv6 prefix by the UE-to-network relay is used. The support of the extended TFT filter format including the TFT packet filter attribute Local Address and Mask, as defined in 3GPP TS 24.008 [30], is needed in the UE-to-network relay and the network.

10.4.7 ProSe Per-Packet Priority for one-to-one ProSe direct communication

10.4.7.1 General

When receiving the user data from upper layers to be sent over a direct link, the transmitting UE shall associate each outgoing protocol data unit with one of eight possible values to indicate the required ProSe Per-Packet Priority related to the lower layer handling of this packet data unit. The ProSe Per-Packet Priority is selected by the application layer based on criteria that are outside the scope of this specification, and is independent of the Layer 2 destination address used for this packet data unit.

The UE shall associate any outgoing PC5 signalling message with the single ProSe Per-Packet Priority value provisioned for PC5signall ing messages.

10.4.7.2 ProSe Per-Packet Priority for ProSe UE-to-network relay

For unicast uplink traffic, the ProSe UE-to-network relay uses the uplink TFTs to select the uplink EPS bearers for relayed uplink packets independently from the ProSe Per-Packet Priority applied over PC5 by remote UEs.

For unicast downlink traffic the ProSe UE-to-network relay maps the QCI of the EPS bearer into a ProSe Per-Packet Priority value to be applied for the downlink relayed unicast packets over PC5. The mapping rules are provisioned in the ProSe UE-to-network relay.

NOTE: downlink traffic on EPS bearers associated with the same QCI, but different ARP values, is assigned the same ProSe Per-Packet Priority over PC5.

10.4.8 Direct link rekeying procedure

10.4.8.1 General

This procedure is used to refresh the security context used between two UEs on an established direct link.

The UE sending the DIRECT_REKEYING_REQUEST message is called the "initiating UE"and the other UE is called the "target UE".

This procedure triggers initiation of a direct security mode control procedure by the target UE. If the ProSe UE-to-network relay UE wants to initiate this procedure to refresh K_D, it shall use a DIRECT_REKEYING_TRIGGER message to trigger the remote UE to initiate this procedure from the other direction.

10.4.8.2 Direct link rekeying procedure initiation

A UE shall initiate the direct link rekeying procedure in any of the following cases:

a) the session key K_D-sess used to protect direct link communication is going to expire and needs to be refreshed and neither timer T4111 nor T4112 are running; or

b) the UE wants to refresh K_D and neither timer T4111 nor T4112 are running.

The initiating UE shall generate a new 128-bit Nonce_1 value and the most significant 8-bits of the K_D-sess ID. The UE shall generate a DIRECT_REKEYING_REQUEST message with the following:

– a Nonce_1 IE set to the nonce value provided by the initiating UE for the purpose of session key establishment over this direct link;

– a UE Security Capabilities IE set to indicate the list of algorithms that the initiating UE supports for the security establishment of this direct link;

– an MSB of K_D-sess ID IE set to the most significant 8-bits of the K_D-sessID;

– Optionally, an Auth Flag IE set to the value indicating the K_D to be refreshed, if the UE wants to refresh K_D; and

– Optionally, a PRUK ID IE if the initiating UE is a remote UE towards a ProSe UE-to-network relay UE.

A UE initiates the direct link rekeying procedure by sending a DIRECT_REKEYING_REQUEST message to the target UE and starting timer T4112 (see figure 10.4.8.2.1).

Figure 10.4.8.2.1: Direct link rekeying procedure

If the initiating UE is a ProSe UE-to-network relay UE, the ProSe UE-to-network relay UE wishes to refresh K_D used on an established link between the ProSe UE-to-network relay UE and the remote UE, and there is no pending direct link rekeying procedure initiated by the remote UE, the ProSe UE-to-network relay UE shall send a DIRECT_REKEYING_TRIGGER message with the format specified in subclause 11.4.17 to trigger the remote UE to initiate its own direct link rekeying procedure and start timer T4113, as shown in figure 10.4.8.2.2.

Upon receiving a DIRECT_REKEYING_TRIGGER message, the remote UE shall:

– if timer T4112 is not running, initiate a direct link rekeying procedure to refresh K_D as described above; and

– if timer T4112 is running, discard the DIRECT_REKEYING_TRIGGER message.

NOTE: If timer T4112 is running at the remote UE, the ProSe UE-to-network relay UE will use the direct link rekeying procedure already initiated by the remote UE to refresh K_D.

Once the ProSe UE-to-network relay received the DIRECT_REKEYING_REQUEST message, the T4113 timer shall be stopped.

Figure 10.4.8.2.2: Direct link rekeying procedure triggered by a ProSe UE-to-network relay UE to refresh K_D

10.4.8.3 Direct link rekeying procedure accepted by the target UE

If there is no active timer T4112 running, the target UE shall process the received DIRECT_REKEYING_REQUEST message and initiate a direct security mode control procedure acting as the commanding UE as described in subclause 10.4.5.2.

If the timer T4112 is running in the target UE, then:

– if the target UE is a ProSe UE-to-network relay UE, it shall stop timer T4112 and initiate a direct security mode control procedure acting as the commanding UE as described in subclause 10.4.5.2; and

– if the target UE is neither a remote UE nor a ProSe UE-to-network relay UE, and the Nonce_1 value received in the DIRECT_REKEYING_REQUEST message is larger than the Nonce_1 value locally generated (and included in the last DIRECT_REKEYING_REQUEST message sent by the target UE), the target UE shall stop timer T4112 and initiate a direct security mode control procedure acting as the commanding UE as described in subclause 10.4.5.2.

When the target UE is a ProSe UE-to-network relay UE, the ProSe UE-to-network relay UE shall trigger a Key Request procedure to the PKMF (see 3GPP TS 33.303 [6]), before initiating the direct security mode control procedure if one of the following conditions are met:

– the Auth Flag IE is included in the DIRECT_REKEYING_REQUEST message; or

– the Auth Flag IE is not included in the DIRECT_REKEYING_REQUEST message but the ProSe UE-to-network relay UE wants to refresh K_D.

Upon completion of the direct security mode control procedure, i.e. upon receiving a DIRECT_SECURITY_MODE_COMPLETE message, the target UE shall send a DIRECT_REKEYING_RESPONSE message with the format specified in subclause 11.4.16, to notify the initiating UE of the completion of this direct link rekeying procedure.

10.4.8.4 Direct link rekeying procedure completion by the initiating UE

Upon the reception of a DIRECT_REKEYING_RESPONSE message, the initiating UE shall stop timer T4112.

10.4.8.5 Direct link rekeying procedure not accepted by the target UE

A remote UE that receives a DIRECT_REKEYING_REQUEST message shall ignore the message if timer T4112 is running. Also, if there is no timer T4112 running but the remote UE wants to refresh K_D, the UE shall ignore the received DIRECT_REKEYING_REQUEST message and act as the new initiating UE and initiate the direct link rekeying procedure to refresh the K_D as described in subclause 10.4.8.2.

Other UEs shall ignore a DIRECT_REKEYING_REQUEST message if timer T4112 is running and the Nonce_1 value received in the DIRECT_REKEYING_REQUEST message is not larger than the Nonce_1 value locally generated (and included in the last DIRECT_REKEYING_REQUEST message sent by the target UE).

10.4.8.6 Abnormal cases

10.4.8.6.1 Abnormal cases at the initiating UE

If timer T4112 expires, the initiating UE shall initiate the transmission of the DIRECT_REKEYING_REQUEST message again and restart timer T4112. If no response is received from the target UE after reaching the maximum number of allowed retransmissions, the initiating UE shall abort the direct link rekeying procedure and initiate the direct link release procedure (see subclause 10.4.4). Additionally, if the initiating UE is a remote UE, it shall initiate the relay reselection procedure as specified in subclause 10A.2.13.

NOTE: The maximum number of allowed retransmissions is UE implementation specific.

10.4.8.6.2 Abnormal cases at the target UE

If the DIRECT_REKEYING_REQUEST message is malformed, the target UE shall discard the message.

10.5 TMGI monitoring request procedure

10.5.1 General

The purpose of the TMGI monitoring request procedure is for the remote UE to obtain a ProSe Layer 2 Group ID from the ProSe UE-to-network relay UE for receiving the MBMS content for the corresponding TMGI over PC5 interface or for the remote UE to inform the ProSe UE-to-network relay UE to forward the MBMS content for the corresponding TMGI.

The remote UE in this procedure shall be a ProSe-enabled Public Safety UE and authorised to act as a remote UE towards a ProSe UE-to-network relay UE based on the service authorisation procedure as specified in clause 5. The ProSe UE-to-network relay UE in this procedure shall be a ProSe-enabled Public Safety UE and authorised to act as a ProSe UE-to-network relay UE based on the service authorisation procedure as specified in clause 5.

10.5.2 TMGI monitoring request procedure initiation by the remote UE

Before initiating the TMGI monitoring request procedure, the remote UE has successfully discovered the ProSe UE-to-network relay UE and obtained the Layer 2 ID of the ProSe UE-to-network relay UE as described in subclause 10A.2. The remote UE has also obtained TMGI and MBMS SAIs from a group communication application to receive related MBMS content (e.g. as specified in 3GPP TS 23.179 [38]).

The remote UE shall initiate a TMGI monitoring request procedure:

a) when the remote UE is triggered by an upper layer application to receive the MBMS content for a given TMGI and there is no corresponding TMGI monitoring refresh timer T4104 assigned by the ProSe UE-to-network relay UE;

b) when the TMGI monitoring refresh timer T4104 assigned by the ProSe UE-to-network relay UE has expired and the request from the upper layer to receive the MBMS content for a given TMGI is still in place;

c) when the remote UE receives a request from an upper layer application to change the requested ProSe Per-Packet Priority associated with the TMGI of an MBMS content that the remote UE is currently receiving; or

d) when the remote UE receives a request from an upper layer application to change the requested MBMS SAI list associated with the TMGI of an MBMS content that the remote UE is currently receiving.

The remote UE shall initiate the TMGI monitoring request procedure by sending a TMGI_MONITORING_REQUEST with:

– the TMGI set to the TMGI received from the application layer;

– the MBMS SAI list included the TMGI corresponding MBMS SAIs received from the application layer; and

– the Requested ProSe Per-Packet Priority set to the ProSe Per-Packet Priority value mapped from the priority value associated with the TMGI from the application layer.

Figure 10.5.2.1: TMGI monitoring request procedure

10.5.3 TMGI monitoring request procedure accepted by the ProSe UE-to-network relay UE

Upon receiving a TMGI_MONITORING_REQUEST, the ProSe UE-to-network relay UE shall store the TMGI and the MBMS SAIs received in the TMGI_MONITORING_REQUEST and check whether at least one of the MBMS SAIs is included in the MBMS SAI list of the serving cell. If there is no MBMS SAI list of the serving cell, the ProSe UE-to-network relay UE retrieves the MBMS SAI list from the system information of the serving cell as specified in 3GPP TS 36.331 [12].

If the MBMS SAI check indicates at least one of the MBMS SAIs is included in the MBMS SAI list of the serving cell, the ProSe UE-to-network relay UE shall monitor the TMGI received in the TMGI_MONITORING_REQUEST in the MCCH channel of the serving cell as specified in 3GPP TS 36.331 [12].

If the MBMS SAI check indicates none of the MBMS SAIs is included in the MBMS SAI list of the serving cell, the ProSe UE-to-network relay UE shall not monitor the TMGI received in the TMGI_MONITORING_REQUEST in the MCCH channel of the serving cell as specified in 3GPP TS 36.331 [12].

For the receiving TMGI, the ProSe UE-to-network relay UE shall allocate a ProSe Layer 2 Group ID which is neither provisioned for one-to-many direct communication nor used for other TMGI(s). The ProSe UE-to-network relay UE shall also allocate a value for TMGI monitoring refresh timer T4104 to the remote UE, and start a timer T4105. For a given TMGI, the timer T4105 shall be longer than the TMGI monitoring refresh timer T4104.

For the receiving Requested ProSe Per-Packet Priority, the ProSe UE-to-network relay UE shall associate the ProSe Per-Packet Priority value with the receiving TMGI. If there is only one ProSe Per-Packet Priority value associated with the receiving TMGI, the ProSe UE-to-network relay UE shall use the ProSe Per-Packet Priority value to transmit the relayed MBMS traffic corresponding to the TMGI over PC5. If there are several different ProSe Per-Packet Priority values associated with the receiving TMGI, which ProSe Per-Packet Priority value will be used to transmit the TMGI corresponding MBMS traffic over PC5 is based on ProSe UE-to-network relay UE implementation.

Then the ProSe UE-to-network relay UE shall send a TMGI_MONITORING_RESPONSE with:

– the ProSe Layer2 Group ID set to the allocated ProSe Layer 2 Group ID as the link layer identifier of the group for transmitting the MBMS content corresponding to the TMGI received in the TMGI_MONITORING_REQUEST;

– the TMGI monitoring refresh timer T4104 set to the T4104 timer value allocated by the ProSe UE-to-network relay UE for the TMGI received in the TMGI_MONITORING_REQUEST; and

– the SAI Indicator set to "true" if the MBMS SAI check indicates at least one of the MBMS SAIs is included in the MBMS SAI list of the serving cell, set to "false" if the MBMS SAI check indicates none of the MBMS SAIs is included in the MBMS SAI list of the serving cell.

NOTE 1: If different ProSe UE-to-network relay UE allocates the same ProSe Layer 2 Group ID for MBMS content transmitting, the remote UE can use the Source Layer-2 ID (i.e. ProSe Relay UE ID) to distinguish whether the MBMS content is the requested MBMS content or not. If the Source Layer-2 ID is different from the ProSe Relay UE ID of the selected ProSe UE-to-network relay UE, the remote UE can just discard the MBMS content from this Source Layer-2 ID.

NOTE 2: The applicable action when the remote UE receives a TMGI_MONITORING_RESPONSE with the SAI Indicator set to "false" is up to UE implementation (e.g. keep the currently selected ProSe UE-to-network relay UE or reselect another ProSe UE-to-network relay UE).

If timer T4105 expires, the ProSe UE-to-network relay UE shall remove the TMGI and the MBMS SAIs received in the TMGI_MONITORING_REQUEST.

10.5.4 TMGI monitoring request procedure completion by the remote UE

Upon receiving a TMGI_MONITORING_RESPONSE, the UE shall, for the ProSe Layer2 Group ID received in the TMGI_MONITORING_RESPONSE, stop the TMGI monitoring refresh timer T4104 if running and start the TMGI monitoring refresh timer T4104 with the received value.

10.5.5 Abnormal cases

10.5.5.1 Abnormal cases in the remote UE

The following abnormal cases can be identified:

a) No response from the ProSe UE-to-network relay UE after the TMGI_MONITORING_REQUEST has been successfully delivered

The remote UE shall retransmit the TMGI_MONITORING_REQUEST.

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

b) Indication from upper layers that the request to receive the MBMS content for a given TMGI is no longer in place after sending the TMGI_MONITORING_REQUEST, but before the TMGI monitoring request procedure is completed

The remote UE shall discard the TMGI_MONITORING_RESPONSE received from the ProSe UE-to-network relay UE and then abort the procedure.

10.6 Cell ID announcement request procedure

10.6.1 General

The purpose of the cell ID announcement request procedure is for the remote UE to obtain ECGI of the cell serving the ProSe UE-to-network relay.

The remote UE in this procedure shall be a ProSe-enabled Public Safety UE and is authorised to act as a remote UE towards a ProSe UE-to-network relay UE based on the service authorisation procedure as specified in clause 5. The ProSe UE-to-network relay UE in this procedure shall be a ProSe-enabled Public Safety UE and is authorised to act as a ProSe UE-to-network relay UE based on the service authorisation procedure as specified in clause 5.

10.6.2 Cell ID announcement request procedure initiation by the remote UE

Before initiating the cell ID announcement request procedure, a direct link has been successfully established between the remote UE and the ProSe UE-to-network relay UE.

The remote UE shall initiate a cell ID announcement request procedure:

a) when the remote UE is triggered by an upper layer application to report ECGI of the serving cell to the application server, but cannot receive the PC5_DISCOVERY message for Relay Discovery Additional Information from the ProSe UE-to-network relay UE, or the ECGI is not included in the PC5_DISCOVERY message for Relay Discovery Additional Information from the ProSe UE-to-network relay UE; or

b) when the ECGI announcement request refresh timer T4106 expires and the remote UE still needs to obtain ECGI of the cell serving the ProSe UE-to-network relay.

The remote UE shall generate a CELL_ID_ANNOUNCEMENT_REQUEST message and pass this message to the lower layers for transmission along with the remote UE’s Layer 2 ID (for unicast communication) and the ProSe UE-to-network relay UE’s Layer 2 ID (for unicast communication).

Figure 10.6.2.1: Cell ID announcement request procedure

10.6.3 Cell ID announcement request procedure accepted by the ProSe UE-to-network relay UE

Upon receiving a CELL_ID_ANNOUNCEMENT_REQUEST message, the ProSe UE-to-network relay UE shall allocate an ECGI announcement request refresh timer T4106 to the remote UE, and start a timer T4107. The timer T4107 shall be longer than the ECGI announcement request refresh timer T4106.

Then the ProSe UE-to-network relay UE shall respond a CELL_ID_ANNOUNCEMENT_RESPONSE message with a ECGI announcement request refresh timer T4106 IE set to the T4106 timer value assigned by the ProSe UE-to-network relay UE.

10.6.4 Cell ID announcement request procedure completion by the remote UE

Upon receiving a CELL_ID_ANNOUNCEMENT_RESPONSE message, the UE shall start the ECGI announcement request refresh timer T4106 with the received value.

10.6.5 Abnormal cases

10.6.5.1 Abnormal cases in the remote UE

If there is no response from the ProSe UE-to-network relay UE after the CELL_ID_ANNOUNCEMENT_REQUEST message has been successfully delivered, the remote UE shall retransmit the CELL_ID_ANNOUNCEMENT_REQUEST message.

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

10.7 Remote UE information request procedure

10.7.1 General

The purpose of the remote UE information request procedure is for the serving ProSe UE-to-network relay UE to obtain the information from the remote UE served by the relay. This procedure can only be initiated by the ProSe UE-to-network relay UE, over an established link between the remote UE and the ProSe UE-to-network relay UE.

10.7.2 Remote UE information request procedure initiation by the ProSe UE-to-network relay UE

Before initiating the remote UE information request procedure, a direct link has been successfully established between the remote UE and the ProSe UE-to-network relay UE.

The ProSe UE-to-network relay UE shall generate a REMOTE_UE_INFO_REQUEST message containing the Remote UE Information Type IE set to the requested type of information as specified in subclause 11.4.18, and pass this message to the lower layers for transmission along with the remote UE’s Layer 2 ID for unicast communication (i.e., ProSe UE ID) and the ProSe UE-to-network relay UE’s Layer 2 ID for unicast communication (i.e., ProSe Relay UE ID).

Figure 10.7.2.1: Remote UE information request procedure

10.7.3 Remote UE information request accepted by the remote UE

Upon receiving a REMOTE_UE_INFO_REQUEST message, the remote UE shall include the requested type of information in a REMOTE_UE_INFO_RESPONSE message, as specified in subclause 11.4.19.

10.7.4 Remote UE information request procedure completion by the ProSe UE-to-network relay UE

Upon receiving a REMOTE_UE_INFO_RESPONSE message, the ProSe UE-to-network relay UE shall store the information provided by the remote UE temporarily so that the remote UE identity can be reported to the MME, as specified in 3GPP TS 24.301 [11].

NOTE: After the ProSe UE-to-network relay UE reports the information of the remote UE to the MME, the stored remote UE information is deleted.

10.7.5 Abnormal cases

10.7.5.1 Abnormal cases in the ProSe UE-to-network relay UE

If there is no response from the remote UE after the REMOTE_UE_INFO_REQUEST message has been successfully delivered, the ProSe UE-to-network relay UE shall retransmit the REMOTE_UE_INFO_REQUEST message.

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

10.8 Non-IP data transport procedure

10.8.1 General

The purpose of the non-IP data transport procedure is to transport, from the upper layers of a sending UE to the upper layers of the receiving UE, the following information over the PC5 interface:

– non-IP data; and

– non-IP type.

10.8.2 Non-IP data transmission over PC5

Upon a request from upper layers to send a non-IP data of a non-IP type, the UE shall create a non-IP data PDU, shall set the non-IP payload field of the non-IP data PDU to the non-IP data provided by upper layers, and shall set the non-IP type field of the non-IP data PDU to the non-IP type provided by upper layers, as specified in subclause 11.5. The UE shall then pass the non-IP data PDU to the lower layers for transmission.

10.8.3 Non-IP data reception over PC5

Upon receiving a non-IP data PDU from the lower layers, the UE shall either:

– check the non-IP type field in the non-IP data PDU and provide the non-IP data in the non-IP payload field of the non-IP data PDU to the corresponding upper layer entity; or

– provide the upper layers with the non-IP data in the non-IP payload field of the non-IP data PDU and with the non-IP type in the non-IP type field of the non-IP data PDU.