7.2.1 Off-network / Private Call / On-demand / Automatic Commencement Mode / No Response to Private Call Setup Request / Private call setup success / With Floor Control / Upgrade to Emergency Call / Cancellation of Emergency on User request / Client Originated (CO)
36.579-23GPPMission Critical (MC) services over LTEPart 2: Mission Critical Push To Talk (MCPTT) User Equipment (UE) Protocol conformance specificationRelease 15TS
7.2.1.1 Test Purpose (TP)
(1)
with { UE (MCPTT Client) registered and authorized for MCPTT Service, including authorized to initiate/cancel private and private emergency calls with automatic commencement in off-network environment, and, the UE is in an off-network environment }
ensure that {
when { the MCPTT User requests the establishment of an MCPTT private call, on-demand Automatic Commencement Mode }
then { UE (MCPTT Client) sends a PRIVATE CALL SETUP REQUEST message requesting establishment of a private call on-demand Automatic Commencement Mode }
}
(2)
with { UE (MCPTT Client) registered and authorized for MCPTT Service, including authorized to initiate/cancel private and private emergency calls with automatic commencement in off-network environment, and, the UE is in an off-network environment, and, UE (MCPTT Client) having sent a PRIVATE CALL SETUP REQUEST message requesting establishment of a private call }
ensure that {
when { the UE (MCPTT Client) does not receive response to the request until the timer TFP1 (private call request retransmission) expires }
then { UE (MCPTT Client) retransmits the PRIVATE CALL SETUP REQUEST message requesting private call if the counter CFP1 (private call request retransmission) has not reached its max value and increments the counter CFP1 with one, and, stops re-transmitting if the counter CFP1 (private call request retransmission) has reached its max value }
}
(3)
with { UE (MCPTT Client) registered and authorized for MCPTT Service, including authorized to initiate/cancel private and private emergency calls with automatic commencement in off-network environment, and, the UE is in an off-network environment, and, UE (MCPTT Client) having sent a PRIVATE CALL SETUP REQUEST message requesting establishment of a private call }
ensure that {
when { the UE (MCPTT Client) receives a PRIVATE CALL ACCEPT message }
then { UE (MCPTT Client) transmits a PRIVATE CALL ACCEPT ACK message and considers the call as being established }
}
(4)
with { UE (MCPTT Client) having established an MCPTT private call in off-network environment }
ensure that {
when { the MCPTT User engages in communication with the invited MCPTT User }
then { UE (MCPTT Client) respects the floor control procedures in off-network environment imposed by Client having the floor (Floor request/grant/release/deny) }
}
(5)
with { UE (MCPTT Client) having established an MCPTT private call in off-network environment }
ensure that {
when { the MCPTT User wants to upgrade the ongoing MCPTT private call to an MCPTT emergency private call }
then { UE (MCPTT Client) sends a PRIVATE CALL SETUP REQUEST message requesting private emergency call on-demand Automatic Commencement Mode, and, after receiving a PRIVATE CALL ACCEPT message the UE (MCPTT Client) sends a PRIVATE CALL ACCEPT ACK message and considers the emergency call as being established }
}
(6)
with { UE (MCPTT Client) having established an MCPTT private call in off-network environment, and, having successfully upgraded it to an MCPTT Private Emergency call }
ensure that {
when { the MCPTT User wants to downgrade the ongoing MCPTT private emergency call to a normal MCPTT private call }
then { UE (MCPTT Client) sends a PRIVATE CALL EMERGENCY CANCEL message, and, after receiving a PRIVATE CALL EMERGENCY CANCEL ACK message, the UE (MCPTT Client) considers the call downgraded to a Private normal call }
}
(7)
with { UE (MCPTT Client) having established an MCPTT private call in off-network environment }
ensure that {
when { the MCPTT User wants to terminate the ongoing MCPTT private call }
then { UE (MCPTT Client) sends a PRIVATE CALL RELEASE request and after receiving a PRIVATE CALL RELEASE ACK messages, leaves the MCPTT session }
}
7.2.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.379 clauses 11.2.1.1.1, 11.2.1.1.2, 11.2.2.4.2.1, 11.2.2.4.2.2, 11.2.2.4.2.4, 11.2.2.4.2.8, 11.2.2.4.5.7, TS 24.380 clauses 7.1, 7.2.3.2.2, 7.2.3.5.2, 7.2.3.4.2, 7.2.3.5.4, 7.2.3.5.5, 7.2.3.4.3, 7.2.3.3.2, 7.2.3.3.5, 7.2.3.7.2, 11.2.3.4.5.1, 11.2.3.4.6.1, 11.2.3.4.6.3, 11.2.2.4.5.1, 11.2.2.4.5.5. Unless otherwise stated these are Rel-13 requirements.
[TS 24.379, clause 11.2.1.1.1]
In order to participate in a private call, the MCPTT client:
1) shall send the MONP message as a UDP message to the local IP address of the MCPTT user, on UDP port TBD, with an IP time-to-live set to 255; and
Editor’s note [CT1#95, C1-160392]: Port number for the message is FFS.
2) shall treat UDP messages received on the port TBD as received MONP messages.
NOTE: An MCPTT client that supports IPv6 is supposed to listen to the IPv6 addresses.
[TS 24.379, clause 11.2.1.1.2]
For an off-network MCPTT session, only MCPTT speech is used.
One off-network MCPTT session includes one media-floor control entity.
The MCPTT client shall generate an SDP body for a private call in accordance with rules and procedures of IETF RFC 4566 [12] and IETF RFC 3264 [44].
The MCPTT client:
1) shall include in the session-level section:
a) the "o=" field with the <username> portion set to a dash;
b) the "s=" field with the <session name> portion set to a dash; and
c) the "c=" field with the <nettype> portion set to "IN", the <addrtype> portion set to the IP version of the unicast IP address of the MCPTT client and the <connection-address> portion set to the unicast IP address of the MCPTT client;
2) shall include the media-level section for MCPTT speech consisting of:
a) the "m=" field with the <media> portion set to "audio", the <port> portion set to a port number for MCPTT speech of the MCPTT group, the <proto> field set to "RTP/AVP" and <fmt> portion set indicating RTP payload type numbers;
b) the "i=" field with the <session description> portion set to "speech";
c) the "a=fmtp:" attribute(s), the "a=rtpmap:" attribute(s) or both, indicating the codec(s) and media parameters of the MCPTT speech; and
d) the "a=rtcp:" attribute indicating port number to be used for RTCP at the MCPTT client selected according to the rules and procedures of IETF RFC 3605 [13], if the media steam uses other than the default IP address;
3) shall include the media-level section for media-floor control entity consisting of:
a) an "m=" line, with the <media> portion set to "application", the <port> portion set to a port number for media-floor control entity of the MCPTT group, the <proto> field set to "udp" and <fmt> portion set to "MCPTT"; and
b) the "a=fmtp:MCPTT" attribute indicating the parameters of the media-floor control entity as specified 3GPP TS 24.380 [5]; and
4) shall include the MIKEY-SAKKE I_MESSAGE, if generated by the MCPTT client, in an "a=key-mgmt" attribute as a "mikey" attribute value in the SDP offer as specified in IETF RFC 4567 [47].
[TS 24.379, clause 11.2.2.4.2.1]
When in the "P0: start-stop" state or "P1: ignoring same call id", upon an indication from MCPTT User to initiate a private call and the value of "/<x>/<x>/Common/PrivateCall/Authorised" leaf node present in the user profile as specified in 3GPP TS 24.383 [45] is set to "true", the MCPTT client:
1) shall generate and store the call identifier as a random number uniformly distributed between (0, 65536);
2) shall store own MCPTT user ID as caller ID;
3) shall store MCPTT user ID of the callee as callee ID;
4) shall store "AUTOMATIC COMMENCEMENT MODE" as commencement mode, if requested and the value of "/<x>/<x>/Common/PrivateCall/AutoCommence" leaf node present in the user profile as specified in 3GPP TS 24.383 [45] is set to "true". Otherwise if the value of "/<x>/<x>/Common/PrivateCall/ManualCommence" leaf node present in the user profile as specified in 3GPP TS 24.383 [45] is set to "true", store "MANUAL COMMENCEMENT MODE" as commencement mode;
5) shall create a call type control state machine as described in subclause 11.2.3.2;
6) if an end-to-end security context needs to be established then:
a) shall use keying material provided by the key management server to generate a PCK as described in 3GPP TS 33.179 [46];
b) shall use the PCK to generate a PCK-ID with the four most significant bits set to "0001" to indicate that the purpose of the PCK is to protect private call communications and with the remaining twenty eight bits being randomly generated as described in 3GPP TS 33.179 [46];
c) shall encrypt the PCK to a UID associated to the MCPTT client using the MCPTT ID of the invited user and a time related parameter as described in 3GPP TS 33.179 [46];
d) shall generate a MIKEY-SAKKE I_MESSAGE using the encapsulated PCK and PCK-ID as specified in 3GPP TS 33.179 [46];
e) shall add the MCPTT ID of the originating MCPTT to the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.179 [46];
f) shall sign the MIKEY-SAKKE I_MESSAGE using the originating MCPTT user’s signing key provided in the keying material together with a time related parameter, and add this to the MIKEY-SAKKE payload, as described in 3GPP TS 33.179 [46] and;
g) shall store the MIKEY-SAKKE I_MESSAGE for later inclusion in an SDP body;
7) may store current user location as user location;
8) shall generate and store offer SDP, as defined in subclause 11.2.1.1.2;
9) shall generate a PRIVATE CALL SETUP REQUEST message as specified in subclause 15.1.5. In the PRIVATE CALL SETUP REQUEST message, the MCPTT client:
a) shall set the Call identifier IE with the stored call identifier;
b) shall set the MCPTT user ID of the caller IE with the stored caller ID;
c) shall set the MCPTT user ID of the callee IE with the stored callee ID;
d) shall set the Commencement mode IE with the stored commencement mode;
e) shall set the Call type IE with the stored current call type associated with the call type control state machine;
f) shall set the SDP offer IE with the stored offer SDP; and
g) may set the User location IE with the stored user location if the stored current call type associated with the call type control state machine is "EMERGENCY PRIVATE CALL".
10) shall send the PRIVATE CALL SETUP REQUEST message towards other MCPTT client according to rules and procedures as specified in subclause 11.2.1.1.1;
11) shall initialize the counter CFP1 (private call request retransmission) with the value set to 1;
12) shall start timer TFP1 (private call request retransmission); and
13) shall enter the "P2: waiting for call response" state.
[TS 24.379, clause 11.2.2.4.2.2]
When in the "P2: waiting for call response" state, upon expiry of timer TFP1 (private call request retransmission), the MCPTT client:
1) may update the stored user location with current user location;
2) shall increment the value of counter CFP1 (private call request retransmission) by 1;
3) shall generate a PRIVATE CALL SETUP REQUEST message as specified in subclause 15.1.5. In the PRIVATE CALL SETUP REQUEST message, the MCPTT client:
a) shall set the Call identifier IE with the stored call identifier;
b) shall set the MCPTT user ID of the caller IE with the stored caller ID;
c) shall set the MCPTT user ID of the callee IE with the stored callee ID;
d) shall set the Commencement mode IE with the stored commencement mode;
e) shall set the Call type IE with the stored current call type associated with the call type control state machine;
f) shall set the SDP offer IE with the stored offer SDP; and
g) may set the User location IE with stored user location if the stored current call type is "EMERGENCY PRIVATE CALL" associated with the call type control state machine.
4) shall send the PRIVATE CALL SETUP REQUEST message towards other MCPTT client according to rules and procedures as specified in subclause 11.2.1.1.1;
5) shall start timer TFP1 (private call request retransmission); and
6) shall remain in the "P2: waiting for call response" state.
[TS 24.379, clause 11.2.2.4.2.4]
In the "P2: waiting for call response" state, when timer TFP1 (private call request retransmission) expires and the value of the counter CFP1 (private call request retransmission) is equal to the upper limit and the stored commencement mode is "AUTOMATIC COMMENCEMENT MODE", the MCPTT client:
1) shall start timer TFP7 (waiting for any message with same call identifier); and
2) shall enter the "P1: ignoring same call id" state.
[TS 24.379, clause 11.2.2.4.2.8]
When in the "P2: waiting for call response" state, upon receiving a PRIVATE CALL ACCEPT message response to PRIVATE CALL SETUP REQUEST message with the same call identifier, the MCPTT client:
1) shall store the SDP answer IE received in the PRIVATE CALL ACCEPT message as answer SDP;
2) shall generate a PRIVATE CALL ACCEPT ACK message as specified in subclause 15.1.11:
a) shall set the Call identifier IE to the stored call identifier;
b) shall set the MCPTT user ID of the caller IE with the stored caller ID; and
c) shall set the MCPTT user ID of the callee IE with the stored callee ID.
3) shall send the PRIVATE CALL ACCEPT ACK message in response to the request message according to rules and procedures as specified in subclause 11.2.1.1.1;
4) shall stop timer TFP1 (call setup retransmission), if running;
5) shall stop timer TFP2 (waiting for call response message), if running;
6) shall establish a media session based on the SDP body of the stored answer SDP;
7) shall start floor control as terminating floor participant as specified in subclause 7.2 in 3GPP TS 24.380 [5];
8) shall start timer TFP5 (max duration); and
9) shall enter the "P4: part of ongoing call" state.
[TS 24.379, clause 11.2.2.4.5.7]
When in the "P1: ignoring same call id" state, upon expiry of timer TFP7 (waiting for any message with same call identifier) the MCPTT client:
1) shall clear the stored call identifier; and
2) shall enter the "P0: start-stop" state.
[TS 24.380, clause 7.1]
In off-network, floor control is performed using floor control messages among the MCPTT clients without a centralized floor arbitrator. When off-network, if a floor control session is active, the floor arbitrator and the floor participant are co-located in the MCPTT client (see 3GPP TS 23.179 [5]). During a floor control session the MCPTT client currently speaking serves as the temporary floor arbitrator. All other MCPTT clients in the call play the role of floor participant. When the floor arbitrator grants the floor to another MCPTT client, that new MCPTT client, when starts to send media, becomes the new floor arbitrator and the former (the MCPTT client which granted the floor) becomes a floor participant.
…
It is assumed that the MCPTT user presses the PTT for requesting talk permission and it keeps it pressed until the request is resolved. If queuing of floor requests is not supported, this request is either granted or rejected or no answer is received. If the request is granted the user is notified with talk permission tone (or equivalent) and the user continues to press the PTT until it finishes the talk burst. If the request is rejected or no answer is received the user is notified and releases the PTT button.
[TS 24.380, clause 7.2.3.2.2]
When an MCPTT call is established with session announcement including an explicit floor request, the originating floor participant:
1. shall create an instance of a floor participant state transition diagram for basic operation state machine;
2. shall send Floor Granted message towards other floor participants. The Floor Granted message:
a. shall include the granted priority in the Floor priority field;
b. shall include the MCPTT user’s own MCPTT ID in the User ID field; and
c. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types;
3. shall set the stored SSRC of the current floor arbitrator to its own SSRC; and
4. shall enter ‘O: has permission’ state.
[TS 24.380, clause 7.2.3.5.2]
Upon receiving encoded media from the user or if encoded media is already buffered the floor participant:
1. shall start timer T206 (Stop talking warning), if not running;
2. shall request the MCPTT client to start sending RTP media packets towards other MCPTT clients; and
3. shall remain in ‘O: has permission’ state.
[TS 24.380, clause 7.2.3.4.2]
If the floor participant receives an indication from the MCPTT user that the MCPTT user wants to send media, the floor participant:
1. shall send the Floor Request message to other clients. The Floor Request message:
a. if a priority different than the default floor priority is required, shall include the Floor Priority field with the requested priority in the <Floor Priority> element;
b. shall include the MCPTT ID of the MCPTT user in the User ID field; and
c. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types;
2. shall initialize the counter C201 (Floor request) with value set to 1;
3. shall start timer T201 (Floor Request); and
4. shall enter ‘O: pending request’ state.
[TS 24.380, clause 7.2.3.5.4]
Upon receiving a Floor Request message which is not pre-emptive as determined by subclause 4.1.1.5, in a session where:
1. the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.383 [4] is set to "false"; or
2. the value of "/<x>/<x>/OffNetwork/QueueUsage" leaf node present in the group configuration as specified in 3GPP TS 24.383 [4] is set to "true" but the F-bit in the Floor Indicator field is set to ‘0’ (i.e. indicating that queuing of floor requests is not supported) or the Floor Indicator field is not included in the Floor Request message;
then the floor participant:
1. shall send the Floor Deny message. The Floor Deny message:
a. shall include in the Reject Cause field the <Reject Cause> value cause #1 (Another MCPTT client has permission);
b. may include in the Reject Cause field an additional text string explaining the reason for rejecting the floor request in the <Reject Phrase> value; and
c. shall include the User ID field received in the Floor Request message; and
2. shall remain in ‘O: has permission’ state.
[TS 24.380, clause 7.2.3.5.5]
Upon receiving an indication from the MCPTT user to release permission to send RTP media, the floor participant:
1. shall stop timer T206 (Stop talking warning), if running;
2. shall stop timer T207 (Stop talking), if running;
3. shall send a Floor Release message towards other floor participants, if no queued requests exist: The Floor Release message:
a. shall include the MCPTT ID of the MCPTT user in the User ID field; and
b. if the session is not initiated as a broadcast group call with the B-bit set to ‘1’ (Broadcast group call), shall include a Floor Indicator field set to ‘0’ (normal call);
4. shall start timer T230 (Inactivity);
5. shall clear the stored SSRC of the current arbitrator; and
6. shall enter ‘O: silence’ state.
[TS 24.380, clause 7.2.3.4.3]
When a Floor Release message is received and if the SSRC in the Floor Release message matches with the stored SSRC of the current arbitrator or with the stored SSRC of the candidate arbitrator, the floor participant:
1. may provide floor idle notification to the MCPTT user.
2. shall request the MCPTT client to stop rendering received RTP media packets;
3. shall stop timer T203 (End of RTP media);
4. shall start timer T230 (Inactivity);
5. shall clear the stored SSRC of the candidate arbitrator;
6. shall clear the stored SSRC of the current arbitrator; and
7. shall enter ‘O: silence’ state;
[TS 24.380, clause 7.2.3.3.2]
If the floor participant receives an indication from the MCPTT user to send media, the floor participant:
1. shall send the Floor Request message to other floor participants. The Floor Request message:
a. if a priority different than the default floor priority is required, shall include the Floor Priority field with the requested priority in the <Floor Priority> element;
b. shall include the MCPTT ID of the MCPTT user in the <User ID> value of the User ID field; and
c. if the floor request is a broadcast group call, system call, emergency call or an imminent peril call, shall include a Floor Indicator field indicating the relevant call types;
2. shall initialize the counter C201 (Floor request) with value set to 1;
3. shall stop timer T230 (Inactivity);
4. shall start timer T201 (Floor Request); and
5. shall enter ‘O: pending request’ state.
[TS 24.380, clause 7.2.3.3.5]
The transition is used in private call only. When a Floor Request message is received, the floor participant:
1. shall send a Floor Granted message toward the other floor participant. The Floor Granted message:
a. shall include the MCPTT ID of the Floor Request message received in User ID value of the User ID field;
b. shall include the SSRC of the Floor Request message received in the SSRC of floor control server field;
c. shall include the max duration as configured in the MCPTT client in the OffNetwork/MaxDuration parameter in the <Duration> value of the Duration field; and
d. shall include the priority of the Floor Request message received in the <Floor Priority> value of the Floor Priority field;
2. shall stop timer T230 (Inactivity);
3. shall start timer T205 (Floor Granted ); and
4. shall enter ‘O: pending granted’ state.
[TS 24.380, clause 7.2.3.7.2]
Upon receiving the RTP media and the SSRC of RTP media packet matches with the stored SSRC of current arbitrator, the floor participant:
1. shall request the MCPTT client to render the received RTP media packets;
2. shall stop timer T205 (Floor Granted), if running;
3. shall stop timer T233 (Pending user action), if running;
4. shall start timer T203 (End of RTP media); and
5. shall enter ‘O: has no permission’ state.
[TS 24.379, clause 11.2.3.4.5.1]
When in the "Q1: in-progress private call" state, upon an indication from MCPTT User to upgrade the call to emergency and the value of "/<x>/<x>/Common/PrivateCall/EmergencyCall/Authorised" leaf node present in the user profile as specified in 3GPP TS 24.383 [45] is set to "true", the MCPTT client:
1) shall generate and store emergency offer SDP as defined in subclause 11.2.1.1.2;
2) shall update caller ID as own MCPTT user ID;
3) shall update callee ID as MCPTT user ID of the other user;
4) shall store current user location as user location;
5) shall set the stored current call type to "EMERGENCY PRIVATE CALL";
6) shall generate a PRIVATE CALL SETUP REQUEST message as specified in subclause 15.1.5. In the PRIVATE SETUP REQUEST message, the MCPTT client:
a) shall set the Call identifier IE with the stored call identifier;
b) shall set the MCPTT user ID of the caller IE with stored caller ID;
c) shall set the MCPTT user ID of the callee IE with the stored callee ID;
d) shall set the Commencement mode IE as "AUTOMATIC COMMENCEMENT MODE";
e) shall set the Call type IE to the stored current call type;
f) shall set the SDP offer IE with emergency offer SDP; and
g) may set the User location IE with user location.
7) shall set the ProSe per-packet priority to the value corresponding to MCPTT off-network emergency private call as described in 3GPP TS 24.383 [45];
8) shall send the PRIVATE CALL SETUP REQUEST message towards other MCPTT client according to rules and procedures as specified in subclause 11.2.1.1.1;
9) shall initialize the counter CFP1 (private call request retransmission) with value set to 1;
10) shall start timer TFP1 (private call request retransmission); and
11) shall enter the "Q2: in-progress emergency private call" state.
[TS 24.379, clause 11.2.3.4.6.1]
When in the "Q2: in-progress emergency private call" state, upon an indication from:
1) the caller of the emergency private call; or
…
to cancel the emergency private call, the MCPTT client:
1) shall generate a PRIVATE CALL EMERGENCY CANCEL message as specified in subclause 15.1.12. In the PRIVATE CALL EMERGENCY CANCEL message, the MCPTT client:
a) shall set the Call identifier IE to the stored call identifier;
b) shall set the MCPTT user ID of the caller IE with the stored caller; and
c) shall set the MCPTT user ID of the callee IE with the stored callee.
2) shall send the PRIVATE CALL EMERGENCY CANCEL message according to rules and procedures as specified in subclause 11.2.1.1.1;
3) shall stop TFP8 (implicit downgrade) timer;
4) shall initialize the counter CFP6 (emergency private call cancel retransmission) with the value set to 1;
5) shall start timer TFP6 (emergency private call cancel retransmission);
6) shall set the stored current call type to "PRIVATE CALL"; and
7) shall enter the "Q1: in-progress private call" state.
[TS 24.379, clause 11.2.3.4.6.3]
When in the "Q1: in-progress private call" state, upon receiving a PRIVATE CALL EMERGENCY CANCEL ACK message response to PRIVATE CALL EMERGENCY CANCEL message with the same "call identifier", the MCPTT client:
1) shall stop timer TFP6 (emergency private call cancel retransmission), if running;
2) shall establish a media session based on the SDP body of the stored answer SDP;
3) shall set the ProSe per-packet priority to the value corresponding to MCPTT off-network private call as described in 3GPP TS 24.383 [45]; and
4) shall remain in the "Q1: in-progress private call" state.
[TS 24.379, clause 11.2.2.4.5.1]
When in the "P4: part of ongoing call" state, upon an indication from MCPTT User to release a private call, the MCPTT client:
1) shall generate a PRIVATE CALL RELEASE message as specified in subclause 15.1.9. In the PRIVATE CALL RELEASE message, the MCPTT client:
a) shall set the Call identifier IE to the stored call identifier;
b) shall set the MCPTT user ID of the caller IE with stored caller ID; and
c) shall set the MCPTT user ID of the callee IE with stored callee ID.
2) shall send the PRIVATE CALL RELEASE message in response to the request message according to rules and procedures as specified in subclause 11.2.1.1.1;
3) shall initialize the counter CFP3 (private call release retransmission) with the value set to 1;
4) shall start timer TFP3 (private call release retransmission); and
5) shall enter the "P3: waiting for release response" state.
[TS 24.379, clause 11.2.2.4.5.5]
When in the "P3: waiting for release response" state, upon receiving a PRIVATE CALL RELEASE ACK to PRIVATE CALL RELEASE message, the MCPTT client:
1) shall stop timer TFP3 (private call release retransmission), if running;
2) shall terminate the media session;
3) shall start timer TFP7 (waiting for any message with same call identifier);
4) shall release the call type control state machine; and
5) shall enter the "P1: ignoring same call id" state.
7.2.1.3 Test description
7.2.1.3.1 Pre-test conditions
System Simulator:
– SS-UE1 (MCPTT client)
– For the underlying "transport bearer" over which the SS and the UE will communicate, the SS is behaving as SS-UE1 as defined in TS 36.508 [24], configured for and operating as ProSe Direct Communication transmitting and receiving device.
– GNSS simulator to simulate a location and provide a timing reference for the assistance of E-UTRAN off-network testing.
NOTE 1: For operation in off-network environment, it needs be ensured that after the UE is powered up it considers the Geographical area #1 that is simulated by the GNSS simulator as being one of the geographical areas set in the USIM for operation when UE is "not served by E-UTRAN".
– SS-NW (MCPTT server) in the Preamble
– For the underlying "transport bearer" over which the SS and the UE will communicate Parameters are set to the default parameters for the basic E-UTRA Single cell network scenarios, as defined in TS 36.508 [24] clause 4.4. The simulated Cell 1 shall belong to PLMN1 (the PLMN specified for MCPTT operation in the MCPTT configuration document).
NOTE 2: The SS operation as NW (MCPTT server) is needed only for the Preamble if the UE has to perform the MCPTT User performs the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2..
IUT:
– UE (MCPTT client)
– The test USIM set as defined in TS 36.579-1 [2], subclause 5.5.10 is inserted.
– For the underlying "transport bearer" over which the SS and the UE will communicate, the UE is behaving as a ProSe enabled UE as defined in TS 36.508 [24], configured for and operating as ProSe Direct Communication transmitting and receiving device.
Preamble:
– The MCPTT User performs the Generic Test Procedure for MCPTT Authorization/Configuration and Key Generation as specified in TS 36.579-1 [2], subclause 5.3.2.
– The GNSS simulator is configured to simulate a location in the centre of Geographical area #1 and provide a timing reference, as defined in TS 36.508 [24] Table 4.11.2-2 scenario #1.
– The UE is Switched OFF (state 1) according to TS 36.508 [24].
7.2.1.3.2 Test procedure sequence
Table 7.2.1.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
Power up the UE. |
– |
– |
– |
– |
|
1A |
Trigger the UE to reset UTC time and location. NOTE: The UTC time and location reset may be performed by MMI or AT command (+CUTCR). |
– |
– |
– |
– |
|
2 |
Activate the MCPTT Client Application and register User A as the MCPTT User (TS 36.579-5 [5], px_MCPTT_User_A_username, px_MCPTT_User_A_password). (NOTE 1) |
– |
– |
– |
– |
|
3 |
Make the UE (MCPTT User) request the establishment of an MCPTT private call, on-demand Automatic Commencement Mode, with Floor Control. (NOTE 1) |
– |
– |
– |
– |
|
– |
EXCEPTION: The E-UTRA/EPC actions which are related to the MCPTT call establishment are described in TS 36.579-1 [2], subclause 5.4.5 ‘Generic Test Procedure for MCPTT CO communication over ProSe direct one-to-one communication out of E-UTRA coverage-establishment’. The test sequence below shows only the MCPTT relevant messages exchanged. |
– |
– |
– |
– |
|
– |
EXCEPTION: Steps 4-6 are repeated CFP1=3 times (CFP1 defined in 36.579-1 [2] Table 5.5.8.1-1) |
– |
– |
– |
– |
|
4 |
Check: Does the UE (MCPTT client) send a PRIVATE CALL SETUP REQUEST, Commencement mode set to AUTOMATIC COMMENCEMENT MODE, Call type set to Private Call? NOTE: It is expected that the UE – shall initialize the counter CFP1 (private call request retransmission) with the value set to 1 on the first transmission, and, increase it by 1 with each re-transmission. – shall start timer TFP1 (private call request retransmission) |
–> |
PRIVATE CALL SETUP REQUEST |
1,2 |
P |
|
5 |
Start TFP1 (private call request retransmission) 2000 milliseconds as defined in 36.579-1 [2] Table 5.5.8.1-1. |
– |
– |
– |
– |
|
6 |
TFP1 expires. |
– |
– |
– |
– |
|
13 |
Start TFP7 (waiting for any message with same call identifier) 6 sec (value chosen to facilitate the test sequence in steps 14-16) and defined in 36.579-1 [2] Table 5.5.8.1-1. NOTE: TFP7 is expected to be started after TFP1 expires and CFP1 is equal to the upper limit. NOTE: It is expected that the UE considers at this moment of time the Private call establishment attempt as failed |
– |
– |
– |
– |
|
14 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL ACCEPT message, |
<– |
PRIVATE CALL ACCEPT |
– |
– |
|
– |
EXCEPTION: Steps 15a1-15b1 depend on UE complience; the "lower case letter" identifies a step sequence that takes place depending on UE behaviour. |
– |
– |
– |
– |
|
15a1 |
Check: Does the UE (MCPTT client) send a PRIVATE CALL ACCEPT ACK? |
–> |
PRIVATE CALL ACCEPT ACK |
2 |
F |
|
15b1 |
Check: Does the TFP7 (waiting for any message with same call identifier) expire? |
– |
– |
2 |
P |
|
16 |
Void. |
– |
– |
– |
– |
|
– |
EXCEPTION: UE releases the E-UTRA connection. The E-UTRA/EPC actions which are related to the MCPTT call release are described in TS 36.579-1 [2], subclause 5.4.8, ‘Generic Test Procedure for MCPTT CO communication over ProSe direct one-to-one communication out of E-UTRA coverage-release by the UE’. |
– |
– |
– |
– |
|
17 |
Make the UE (MCPTT User) request the establishment of an MCPTT private call, on-demand Automatic Commencement Mode, with Floor Control. (NOTE 1) |
– |
– |
– |
– |
|
– |
EXCEPTION: The E-UTRA/EPC actions which are related to the MCPTT call establishment are described in TS 36.579-1 [2], subclause 5.4.5 ‘Generic Test Procedure for MCPTT CO communication over ProSe direct one-to-one communication out of E-UTRA coverage-establishment’. The test sequence below shows only the MCPTT relevant messages exchanged. |
– |
– |
– |
– |
|
18 |
Check: Does the UE (MCPTT client) send a PRIVATE CALL SETUP REQUEST, Commencement mode set to AUTOMATIC COMMENCEMENT MODE, Call type set to Private Call? |
–> |
PRIVATE CALL SETUP REQUEST |
1 |
P |
|
19 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL ACCEPT message, |
<– |
PRIVATE CALL ACCEPT |
– |
– |
|
20 |
Check: Does the UE (MCPTT client) send a PRIVATE CALL ACCEPT ACK? |
–> |
PRIVATE CALL ACCEPT ACK |
3 |
P |
|
21 |
Make the UE (MCPTT User) press the PTT button requesting permission to talk. NOTE 1: Depending on UE implementation the PTT button may already been pressed in step 17. NOTE 2: The UE (MCPTT User) shall keep the button pressed until otherwise written. |
– |
– |
– |
– |
|
22 |
Check: Does the UE (MCPTT client) send Floor Granted message, Floor Indicator set to Normal call? |
–> |
Floor Granted |
4 |
P |
|
23 |
SS-UE1 (MCPTT Client) sends a Floor Request message |
<– |
Floor Request |
– |
– |
|
24 |
Check: Does the UE (MCPTT client) send Floor Deny message? |
–> |
Floor Deny |
4 |
P |
|
25 |
Make the UE (MCPTT User) release the PTT button. |
– |
– |
– |
– |
|
26 |
Check: Does the UE (MCPTT client) send Floor Release message? |
–> |
Floor Release |
4 |
P |
|
27 |
SS-UE1 (MCPTT Client) sends a Floor Request message |
<– |
Floor Request |
– |
– |
|
28 |
Check: Does the UE (MCPTT client) send Floor Granted message? |
–> |
Floor Granted |
4 |
P |
|
29 |
SS continuously sends RTP media until step 34 below. NOTE: The UE (Client) needs to receive RTP media because otherwise the sending of Floor Deny in step 32 will not be a valid behaviour. |
– |
– |
– |
– |
|
30 |
Make the UE (MCPTT User) press the PTT button requesting permission to talk. NOTE: The UE (MCPTT User) shall keep the button pressed until otherwise written. |
– |
– |
– |
– |
|
31 |
Check: Does the UE (MCPTT client) send Floor Request message? |
–> |
Floor Request |
4 |
P |
|
32 |
SS-UE1 (MCPTT Client) sends a Floor Deny message. |
<– |
Floor Deny |
– |
– |
|
33 |
Make the UE (MCPTT User) release the PTT button. |
– |
– |
– |
– |
|
34 |
SS-UE1 (MCPTT Client) sends a Floor Release message. |
<– |
Floor Release |
– |
– |
|
35 |
Make the UE (MCPTT User) press the PTT button requesting permission to talk. NOTE: The UE (MCPTT User) shall keep the button pressed until otherwise written. |
– |
– |
– |
– |
|
36 |
Check: Does the UE (MCPTT client) send Floor Request message? |
–> |
Floor Request |
4 |
P |
|
37 |
SS-UE1 (MCPTT Client) sends a Floor Granted message. |
<– |
Floor Granted |
– |
– |
|
38 |
Make the UE (MCPTT User) release the PTT button. |
– |
– |
– |
– |
|
39 |
Check: Does the UE (MCPTT client) send Floor Release message? |
–> |
Floor Release |
4 |
P |
|
40 |
Make the UE (MCPTT User) request upgrade of the ongoing call to Emergency call. (NOTE 1) |
– |
– |
– |
– |
|
41 |
Check: Does the UE (MCPTT client) send PRIVATE CALL SETUP REQUEST message, Call type set to EMERGENCY PRIVATE CALL? |
–> |
PRIVATE CALL SETUP REQUEST |
5 |
P |
|
42 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL ACCEPT message. |
<– |
PRIVATE CALL ACCEPT |
– |
– |
|
43 |
Check: Does the UE (MCPTT client) send PRIVATE CALL ACCEPT ACK message? |
–> |
PRIVATE CALL ACCEPT ACK |
5 |
P |
|
44 |
Make the UE (MCPTT User) to press the PTT button requesting permission to talk. NOTE 1: Depending on UE implementation the PTT button may already been pressed in step 40. NOTE 2: The UE (MCPTT User) shall keep the button pressed until otherwise written. |
– |
– |
– |
– |
|
45 |
Check: Does the UE (MCPTT client) send Floor Request message? |
–> |
Floor Granted |
5,4 |
P |
|
46 |
Void |
– |
– |
– |
– |
|
47 |
Make the UE (MCPTT User) to release the PTT button. |
– |
– |
– |
– |
|
48 |
Check: Does the UE (MCPTT client) send Floor Release message? |
–> |
Floor Release |
5,4 |
P |
|
49 |
Make the UE (MCPTT User) request downgrade of the ongoing Emergency call. (NOTE 1) |
– |
– |
– |
– |
|
50 |
Check: Does the UE (MCPTT client) send PRIVATE CALL EMERGENCY CANCEL message? |
–> |
PRIVATE CALL EMERGENCY CANCEL |
6 |
P |
|
51 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL EMERGENCY CANCEL ACK message. |
<– |
PRIVATE CALL EMERGENCY CANCEL ACK |
– |
– |
|
52 |
Make the UE (MCPTT User) press the PTT button requesting permission to talk. NOTE: The UE (MCPTT User) shall keep the button pressed until otherwise written. |
– |
– |
– |
– |
|
53 |
Check: Does the UE (MCPTT client) send Floor Request message? |
–> |
Floor Request |
6,4 |
P |
|
54 |
SS-UE1 (MCPTT Client) sends a Floor Granted message. |
<– |
Floor Granted |
– |
– |
|
55 |
Make the UE (MCPTT User) to release the PTT button. |
– |
– |
– |
– |
|
56 |
Check: Does the UE (MCPTT client) send Floor Release message? |
–> |
Floor Release |
6,4 |
P |
|
57 |
Make the UE (MCPTT User) request termination of the MCPTT private call. (NOTE 1) |
– |
– |
– |
– |
|
58 |
Check: Does the UE (MCPTT client) send PRIVATE CALL RELEASE message? |
–> |
PRIVATE CALL RELEASE |
7 |
P |
|
59 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL RELEASE ACK message. |
<– |
PRIVATE CALL RELEASE ACK |
– |
– |
|
– |
EXCEPTION: UE releases the E-UTRA connection. The E-UTRA/EPC actions which are related to the MCPTT call release are described in TS 36.579-1 [2], subclause 5.4.8, ‘Generic Test Procedure for MCPTT CO communication over ProSe direct one-to-one communication out of E-UTRA coverage-release by the UE’. |
– |
– |
– |
– |
|
NOTE 1: This is expected to be done via a suitable implementation dependent MMI. |
|||||
7.2.1.3.3 Specific message contents
Table 7.2.1.3.3-1: PRIVATE CALL SETUP REQUEST (Step 41 Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.5.8.1-1. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Call type |
‘00000110’B |
EMERGENCY PRIVATE CALL |
|
|
User location |
Nor present or Any value |
||
Table 7.2.1.3.3-2: Floor Granted (Step 28, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.3-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
User ID |
|||
|
User ID |
px_MCPTT_User_B_ID |
The MCPTT User ID of the one simulated by the SS |
|
|
Floor Indicator |
|||
|
Floor Indicator |
‘10000×00 0000000 |
Bit A=1 (Normal call) bit F=x (Queueing supported) any value |
|
Table 7.2.1.3.3-2A: Floor Granted (Step 22, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.3-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
SSRC of granted floor participant |
UE (MCPTT client) SSRC |
||
|
Floor Indicator |
|||
|
Floor Indicator |
‘10000×00 0000000 |
Bit A=1 (Normal call) bit F=x (Queueing supported) any value |
|
Table 7.2.1.3.3-3: Floor Granted (Steps 37, 54, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.3-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor Indicator |
|||
|
Floor Indicator |
‘10000100 0000000 |
Bit A=1 (Normal call) bit F=1 (Queueing supported) |
|
Table 7.2.1.3.3-4: Floor Request (Steps 23, 27, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.2-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
User ID |
|||
|
User ID |
px_MCPTT_User_B_ID |
The MCPTT User ID of the one simulated by the SS |
|
|
Floor Indicator |
|||
|
Floor Indicator |
‘10000100 0000000 |
Bit A=1 (Normal call) bit F=1 (Queueing supported) |
|
Table 7.2.1.3.3-5: Floor Request (Step 31, 36, 53, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.2-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor Indicator |
|||
|
Floor Indicator |
‘10000×00 0000000 |
Bit A=1 (Normal call) bit F=x (Queueing supported) any value |
|
Table 7.2.1.3.3-6: Floor Deny (Step 24, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.4-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
User ID |
|||
|
User ID |
px_MCPTT_User_B_ID |
The MCPTT User ID of the one simulated by the SS |
|
|
Floor Indicator |
|||
|
Floor Indicator |
‘10000×00 0000000 |
Bit A=1 (Normal call) bit F=x (Queueing supported) any value |
|
Table 7.2.1.3.3-7: Floor Deny (Step 32, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.4-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor Indicator |
|||
|
Floor Indicator |
‘10000100 0000000 |
Bit A=1 (Normal call) bit F=1 (Queueing supported) |
|
Table 7.2.1.3.3-8: Floor Release (Steps 26, 39, 56, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.5-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor Indicator |
|||
|
Floor Indicator |
‘10000×00 0000000 |
Bit A=1 (Normal call) bit F=x (Queueing supported) any value |
|
Table 7.2.1.3.3-9: Floor Release (Step 34, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.5-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
User ID |
|||
|
User ID |
px_MCPTT_User_B_ID |
The MCPTT User ID of the one simulated by the SS |
|
|
Floor Indicator |
|||
|
Floor Indicator |
‘10000100 0000000 |
Bit A=1 (Normal call) bit F=1 (Queueing supported) |
|
Table 7.2.1.3.3-10: Floor Request (Step 45, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.2-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor Indicator |
|||
|
Floor Indicator |
‘00010×00 0000000 |
Bit D=1 (Emergency call) bit F=x (Queueing supported) any value |
|
Table 7.2.1.3.3-11: Floor Granted (Step 46, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.3-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor Indicator |
|||
|
Floor Indicator |
‘00010100 0000000 |
Bit D=1 (Emergency call) bit F=1 (Queueing supported) |
|
Table 7.2.1.3.3-12: Floor Release (Step 48, Table 7.2.1.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.6.5-1 condition OFF-NETWORK. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Floor Indicator |
|||
|
Floor Indicator |
‘00010×00 0000000 |
Bit D=1 (Emergency call) bit F=x (Queueing supported) any value |
|