7.2.2 Off-network / Private Call / On-demand / Automatic Commencement Mode / No Response to Private Call Setup Accept / Private call setup success / With Floor Control / Upgrade to Emergency Call / Cancellation of Emergency on User request / Client Terminated (CT)
36.579-23GPPMission Critical (MC) services over LTEPart 2: Mission Critical Push To Talk (MCPTT) User Equipment (UE) Protocol conformance specificationRelease 15TS
7.2.2.1 Test Purpose (TP)
(1)
with { UE (MCPTT Client) registered and authorized for MCPTT Service, including authorized to receive private and private emergency calls with automatic commencement, and, the UE is in an off-network environment }
ensure that {
when { the UE (MCPTT Client) receives a request for establishment of an MCPTT private call, on-demand Automatic Commencement Mode }
then { UE (MCPTT Client) sends a PRIVATE CALL ACCEPT message accepting the establishment of a private call on-demand Automatic Commencement Mode }
}
(2)
with { UE (MCPTT Client) registered and authorized for MCPTT Service, including authorized to receive private and private emergency calls with automatic commencement, and, the UE is in an off-network environment, and, UE (MCPTT Client) having sent a PRIVATE CALL ACCEPT message accepting the establishment of a private call }
ensure that {
when { the UE (MCPTT Client) does not receive response from the calling Client until the timer TFP4 (private call accept retransmission) expires }
then { UE (MCPTT Client) retransmits the PRIVATE CALL ACCEPT message if the counter CFP4 (private call accept retransmission) has not reached its max value and increments the counter CFP4 with one, and, stops re-transmitting if the counter CFP4 (private call accept retransmission) has reached its max value }
}
(3)
with { UE (MCPTT Client) registered and authorized for MCPTT Service, including authorized to receive private and private emergency calls with automatic commencement, and, the UE is in an off-network environment, and, UE (MCPTT Client) having sent a PRIVATE CALL ACCEPT message accepting the establishment of a private call }
ensure that {
when { the UE (MCPTT Client) receives a PRIVATE CALL ACCEPT ACK message }
then { UE (MCPTT Client) considers the private call as 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 inviting 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 UE (MCPTT Client) receives a request from the remote Client to upgrade the ongoing MCPTT private call to an MCPTT emergency private call }
then { UE (MCPTT Client) sends a PRIVATE CALL ACCEPT message accepting the upgrade, and, after receiving a PRIVATE CALL ACCEPT ACK message, UE (MCPTT Client) considers the emergency private call as 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 UE (MCPTT Client) receives a request from the remote Client to downgrade the ongoing MCPTT private emergency call to a normal MCPTT private call }
then { UE (MCPTT Client) sends a PRIVATE CALL EMERGENCY CANCEL ACK message, and, 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 receives a request from the remote Client to release the ongoing MCPTT private call }
then { UE (MCPTT Client) sends a PRIVATE CALL RELEASE ACK message and leaves the MCPTT session }
}
7.2.2.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.3.2, 11.2.2.4.3.3, 11.2.2.4.3.5, 11.2.2.4.3.4, TS 24.380 clauses 7.1, 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.5.2, 7.2.3.7.2, 11.2.3.4.5.6, 11.2.3.4.6.5, 11.2.2.4.5.4. 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.3.2]
When in the "P0: start-stop" or "P1: ignoring same call id" state, upon receiving a PRIVATE CALL SETUP REQUEST message with Commencement mode IE set to "AUTOMATIC COMMENCEMENT MODE" and Call identifier IE different than stored call identifier and media session declared in SDP body of PRIVATE CALL SETUP REQUEST message can be established, the MCPTT client:
1) shall store the Call identifier IE in the received message as call identifier;
2) shall create the call type control state machine as described in subclause 11.2.3.2;
3) shall store the MCPTT user ID of the caller IE in the received PRIVATE CALL SETUP REQUEST message as caller ID;
4) shall store own MCPTT user ID as callee ID;
5) if the SDP offer contains an "a=key-mgmt" attribute field with a "mikey" attribute value containing a MIKEY-SAKKE I_MESSAGE:
a) shall extract the MCPTT ID of the originating MCPTT user from the initiator field (IDRi) of the I_MESSAGE as described in 3GPP TS 33.179 [46];
b) shall convert the MCPTT ID to a UID as described in 3GPP TS 33.179 [46];
c) shall use the UID to validate the signature of the MIKEY-SAKKE I_MESSAGE as described in 3GPP TS 33.179 [46];
…
e) if the validation of the signature was successful:
i) shall extract and decrypt the encapsulated PCK using the terminating user’s (KMS provisioned) UID key as described in 3GPP TS 33.179 [46];
ii) shall extract the PCK-ID, from the payload as specified in 3GPP TS 33.179 [46];
iii) shall generate and store answer SDP based on received SDP offer IE in PRIVATE CALL SETUP REQUEST message, as defined in subclause 11.2.1.1.2;
iv) shall generate a PRIVATE CALL ACCEPT message as specified in subclause 15.1.7. In the PRIVATE CALL ACCEPT message, the MCPTT client:
A) shall set the Call identifier IE to the stored call identifier; and
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 stored callee ID; and
D) shall set the SDP answer IE with the stored answer SDP;
v) shall send PRIVATE CALL ACCEPT message in response to the request message according to rules and procedures as specified in subclause 11.2.1.1.1;
vi) shall establish a media session based on the SDP body of the stored answer SDP;
vii) shall initialize the counter CFP4 with value set to 1;
viii) shall start timer TFP4 (private call accept retransmission); and
ix) shall enter the "P5: pending" state; and
NOTE: With the PCK successfully shared between the originating MCPTT client and the terminating MCPTT client, both clients are able to use SRTP/SRTCP to create an end-to-end secure session.
6) if the SDP offer does not contain an "a=key-mgmt" attribute, the MCPTT client:
a) shall generate and store answer SDP based on received SDP offer IE in PRIVATE CALL SETUP REQUEST message, as defined in subclause 11.2.1.1.2;
b) shall generate a PRIVATE CALL ACCEPT message as specified in subclause 15.1.7:
i) shall set the Call identifier IE to the stored call identifier;
ii) shall set the MCPTT user ID of the caller IE with stored caller ID.
iii) shall set the MCPTT user ID of the callee IE with stored callee ID; and
iv) shall set the SDP answer IE with the stored answer SDP;
c) shall send PRIVATE CALL ACCEPT message in response to the request message according to rules and procedures as specified in subclause 11.2.1.1.1;
d) shall establish a media session based on the SDP body of the stored answer SDP;
e) shall initialize the counter CFP4 with value set to 1;
f) shall start timer TFP4 (private call accept retransmission); and
g) shall enter the "P5: pending" state.
[TS 24.379, clause 11.2.2.4.3.3]
When in the "P5: pending" state, upon expiry of timer TFP4 (private call accept retransmission), the MCPTT client:
1) shall generate a PRIVATE CALL ACCEPT message as specified in subclause 15.1.7. In the PRIVATE CALL ACCEPT 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 ID;
c) shall set the MCPTT user ID of the callee IE with the stored callee ID; and
d) shall set the SDP answer IE with the stored answer SDP;
2) shall send PRIVATE CALL ACCEPT message in response to the request message according to rules and procedures as specified in subclause 11.2.1.1.1;
3) shall increment the value of the counter CFP4 (private call accept retransmission) by 1;
4) shall start timer TFP4 (private call accept retransmission); and
5) shall remain in the "P5: pending" state.
[TS 24.379, clause 11.2.2.4.3.5]
In the "P5: pending" state, when timer TFP4 (private call accept retransmission) expires and the value of the counter CFP4 (private call accept retransmission) is equal to the upper limit, the MCPTT client:
1) shall start timer TFP7 (waiting for any message with same call identifier);
2) shall release the call type control state machine; and
3) shall enter the "P1: ignoring same call id" state.
[TS 24.379, clause 11.2.2.4.3.4]
When in the "P5: pending" state, upon receiving a PRIVATE CALL ACCEPT ACK message or RTP media from originating user, the MCPTT client:
1) shall stop timer TFP4(private call accept retransmission);
2) shall start floor control as terminating MCPTT client as specified in subclause 7.2 in 3GPP TS 24.380 [5];
3) shall start timer TFP5 (max duration); and
4) 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.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.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.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.6]
When in the "Q1: in-progress private call" state or "Q2: in-progress emergency private call" state, upon receiving a PRIVATE CALL SETUP REQUEST message with the Call identifier IE same as the stored call identifier of the call, the Call type IE set as "EMERGENCY PRIVATE CALL", the MCPTT client:
1) if the media session declared in SDP body of PRIVATE CALL SETUP REQUEST message can be established:
a) shall generate and store emergency answer SDP based on received SDP offer IE in PRIVATE CALL SETUP REQUEST message, as defined in subclause 11.2.1.1.2;
b) shall update the caller ID with the MCPTT user ID of the caller IE as received in the PRIVATE CALL SETUP REQUEST message;
c) shall update the callee ID with own MCPTT user ID;
d) shall generate a PRIVATE CALL ACCEPT message as specified in subclause 15.1.7:
i) shall set the Call identifier IE to the stored call identifier;
ii) shall set the MCPTT user ID of the callee IE with stored callee ID;
iii) shall set the MCPTT user ID of the caller IE with stored caller ID; and
iv) shall set the SDP answer IE with the stored emergency answer SDP;
e) 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];
f) shall start TFP8 (implicit downgrade) timer;
g) shall send PRIVATE CALL ACCEPT message in response to the request message according to rules and procedures as specified in subclause 11.2.1.1.1;
h) shall set the stored current call type to "EMERGENCY PRIVATE CALL"; and
i) shall enter the "Q2: in-progress emergency private call" state;
[TS 24.379, clause 11.2.3.4.6.5]
When in the "Q1: in-progress private call" state or "Q2: in-progress emergency private call" state, upon receiving a PRIVATE CALL EMERGENCY CANCEL message with the same "call identifier" IE, the MCPTT client:
1) shall generate a PRIVATE CALL EMERGENCY CANCEL ACK as specified in subclause 15.1.13:
a) shall set the Call identifier IE to the stored call identifier;
b) shall set the MCPTT user ID of the callee IE with own MCPTT user ID; and
c) shall set the MCPTT user ID of the caller IE with MCPTT user ID of the caller IE in received message;
2) shall send PRIVATE CALL EMERGENCY CANCEL ACK message according to rules and procedures as specified in subclause 11.2.1.1.1;
3) shall stop TFP8 (implicit downgrade) timer;
4) shall establish a media session based on the SDP body of the stored answer SDP;
5) 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
6) shall enter the "Q1: in-progress private call" state and set the stored current call type to "PRIVATE CALL", if current state is the "Q2: in-progress emergency private call" state.
[TS 24.379, clause 11.2.2.4.5.4]
When in the "P4: part of ongoing call" state, upon receiving a PRIVATE CALL RELEASE message, the MCPTT client:
1) shall generate a PRIVATE CALL RELEASE ACK message as specified in subclause 15.1.10;
a) shall set the Call identifier IE to the stored call identifier;
b) shall set the MCPTT user ID of the caller IE the stored caller ID; and
c) shall set the MCPTT user ID of the callee IE with the stored callee ID.
2) shall send the PRIVATE CALL RELEASE ACK message in response to the request message according to rules and procedures as specified in subclause 11.2.1.1.1;
3) shall terminate the media session for private call;
4) shall start timer TFP7 (waiting for any message with same call identifier);
5) shall release the call type control state machine; and
6) shall enter the "P1: ignoring same call id" state.
7.2.2.3 Test description
7.2.2.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.2.3.2 Test procedure sequence
Table 7.2.2.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). |
– |
– |
– |
– |
|
– |
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.6 ‘Generic Test Procedure for MCPTT CT 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. |
– |
– |
– |
– |
|
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: This is expected to be done via a suitable implementation dependent MMI. |
– |
– |
– |
– |
|
3 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL SETUP REQUEST, Commencement mode set to AUTOMATIC COMMENCEMENT MODE, Call type set to Private Call. |
<– |
PRIVATE CALL SETUP REQUEST |
– |
– |
|
– |
EXCEPTION: Steps 4-6 are repeated CFP4=2 times (CFP4 defined in 36.579-1 [2] Table 5.5.8.1-1) |
– |
– |
– |
– |
|
4 |
Check: Does the UE (MCPTT client) send a PRIVATE CALL ACCEPT? NOTE: It is expected that the UE – shall initialize the counter CFP4 (private call accept retransmission) with value set to 1 on the first transmission, and, increase it by 1 with each re-transmission – shall start timer TFP4 (private call accept retransmission). |
–> |
PRIVATE CALL ACCEPT |
1,2 |
P |
|
5 |
Start TFP4 (private call accept retransmission) 50 milliseconds as defined in 36.579-1 [2] Table 5.5.8.1-1. |
– |
– |
– |
– |
|
6 |
TFP4 expires. |
– |
– |
– |
– |
|
10-12 |
Void |
– |
– |
– |
– |
|
13 |
Start TFP7 (waiting for any message with same call identifier) 6 sec (value chosen to facilitate the test sequence in steps 14-17) and defined in 36.579-1 [2] Table 5.5.8.1-1. NOTE: TFP7 is expected to be started after TFP4 expires and CFP4 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 ACK |
– |
– |
|
15 |
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. |
– |
– |
– |
– |
|
– |
EXCEPTION: Steps 16a1-16b1 depend on UE complience; the "lower case letter" identifies a step sequence thats take place depending on UE behaviour. |
– |
– |
– |
– |
|
16a1 |
Check: Does the UE (MCPTT client) sends a Floor Request message |
–> |
Floor Request |
2 |
F |
|
16b1 |
Check: Does the TFP7 (waiting for any message with same call identifier) expire? |
– |
– |
2 |
P |
|
17 |
Make the UE (MCPTT User) release the PTT button. |
– |
– |
– |
– |
|
– |
EXCEPTION: SS 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.7, ‘Generic Test Procedure for MCPTT CO communication over ProSe direct one-to-one communication out of E-UTRA coverage-release by the SS’. |
– |
– |
– |
– |
|
18 |
Wait for 5 sec to ensure the UE is in stable state – scanning for incoming ProSe messages. |
– |
– |
– |
– |
|
– |
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.6 ‘Generic Test Procedure for MCPTT CT 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. |
– |
– |
– |
– |
|
19 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL SETUP REQUEST. |
<– |
PRIVATE CALL SETUP REQUEST |
– |
– |
|
20 |
Check: Does the UE (MCPTT client) send a PRIVATE CALL ACCEPT? |
–> |
PRIVATE CALL ACCEPT |
1 |
P |
|
21 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL ACCEPT ACK. |
<– |
PRIVATE CALL ACCEPT ACK |
– |
– |
|
22 |
SS-UE1 (MCPTT Client) sends Floor Granted message. |
<– |
Floor Granted |
– |
– |
|
23 |
SS-UE1 (MCPTT Client) continuously sends RTP media until step 28 below. NOTE: The UE (Client) needs to receive RTP media because otherwise the sending of Floor Deny below will not be a valid behaviour. |
– |
– |
– |
– |
|
24 |
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. |
– |
– |
– |
– |
|
25 |
Check: Does the UE (MCPTT client) send a Floor Request message? |
–> |
Floor Request |
3,4 |
P |
|
26 |
SS-UE1 (MCPTT Client) sends Floor Deny message. |
<– |
Floor Deny |
– |
– |
|
27 |
Make the UE (MCPTT User) release the PTT button. |
– |
– |
– |
– |
|
28 |
SS-UE1 (MCPTT Client) sends Floor Release message. |
<– |
Floor Release |
– |
– |
|
29 |
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. |
– |
– |
– |
– |
|
30 |
Check: Does the UE (MCPTT client) send a Floor Request message? |
–> |
Floor Request |
4 |
P |
|
31 |
SS-UE1 (MCPTT Client) sends Floor Granted message. |
<– |
Floor Granted |
– |
– |
|
32 |
SS-UE1 (MCPTT Client) sends a Floor Request message. |
<– |
Floor Request |
– |
– |
|
33 |
Check: Does the UE (MCPTT client) send Floor Deny message? |
–> |
Floor Deny |
4 |
P |
|
34 |
Make the UE (MCPTT User) release the PTT button. |
– |
– |
– |
– |
|
35 |
Check: Does the UE (MCPTT client) send a Floor Release message? |
–> |
Floor Release |
4 |
P |
|
36 |
SS-UE1 (MCPTT Client) sends a Floor Request message. |
<– |
Floor Request |
– |
– |
|
37 |
Check: Does the UE (MCPTT client) send Floor Granted message? |
–> |
Floor Granted |
4 |
P |
|
38 |
SS-UE1 (MCPTT Client) sends Floor Release message. |
<– |
Floor Release |
– |
– |
|
39 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL SETUP REQUEST message with Call type IE, call type = "EMERGENCY PRIVATE CALL. |
<– |
PRIVATE CALL SETUP REQUEST |
– |
– |
|
40 |
Check: Does the UE (MCPTT client) send a PRIVATE CALL ACCEPT? |
–> |
PRIVATE CALL ACCEPT |
5 |
P |
|
41 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL ACCEPT ACK. |
<– |
PRIVATE CALL ACCEPT ACK |
– |
– |
|
42 |
SS-UE1 (MCPTT Client) sends Floor Granted message. |
<– |
Floor Granted |
– |
– |
|
43 |
SS-UE1 (MCPTT Client) sends Floor Release message. |
<– |
Floor Release |
– |
– |
|
44 |
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. |
– |
– |
– |
– |
|
45 |
Check: Does the UE (MCPTT client) send a Floor Request message? |
–> |
Floor Request |
5,4 |
P |
|
46 |
SS-UE1 (MCPTT Client) sends Floor Granted message. |
<– |
Floor Granted |
– |
– |
|
47 |
Make the UE (MCPTT User) release the PTT button. |
– |
– |
– |
– |
|
48 |
Check: Does the UE (MCPTT client) send a Floor Release message? |
–> |
Floor Release |
5,4 |
P |
|
49 |
SS-UE1 (MCPTT Client) sends a PRIVATE CALL EMERGENCY CANCEL message. |
<– |
PRIVATE CALL EMERGENCY CANCEL |
– |
– |
|
50 |
Check: Does the UE (MCPTT client) send a PRIVATE CALL EMERGENCY CANCEL ACK message? |
–> |
PRIVATE CALL EMERGENCY CANCEL ACK |
6 |
P |
|
51 |
SS-UE1 (MCPTT Client) sends Floor Granted message. |
<– |
Floor Granted |
– |
– |
|
52 |
SS-UE1 (MCPTT Client) sends Floor Release message. |
<– |
Floor Release |
– |
– |
|
53 |
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. |
– |
– |
– |
– |
|
54 |
Check: Does the UE (MCPTT client) send a Floor Request message? |
–> |
Floor Request |
6,4 |
P |
|
55 |
SS-UE1 (MCPTT Client) sends Floor Granted message. |
<– |
Floor Granted |
– |
– |
|
56 |
Make the UE (MCPTT User) release the PTT button. |
– |
– |
– |
– |
|
57 |
Check: Does the UE (MCPTT client) send a Floor Release message? |
–> |
Floor Release |
6,4 |
P |
|
58 |
SS-UE1 (MCPTT Client) sends PRIVATE CALL RELEASE message. |
<– |
PRIVATE CALL RELEASE |
– |
– |
|
59 |
Check: Does the UE (MCPTT client) send a PRIVATE CALL RELEASE ACK message |
–> |
PRIVATE CALL RELEASE ACK |
7 |
P |
|
– |
EXCEPTION: SS 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.7, ‘Generic Test Procedure for MCPTT CO communication over ProSe direct one-to-one communication out of E-UTRA coverage-release by the SS’. |
– |
– |
– |
– |
7.2.2.3.3 Specific message contents
Table 7.2.2.3.3-1: PRIVATE CALL SETUP REQUEST (Step 39 Table 7.2.2.3.2-1)
|
Derivation Path: 36.579-1 [2], Table 5.5.5.8.2-1. |
|||
|
Information Element |
Value/remark |
Comment |
Condition |
|
Call type |
‘00000110’B |
EMERGENCY PRIVATE CALL |
|
Table 7.2.2.3.3-2: Floor Granted (Step 37, Table 7.2.2.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 |
SS-UE1 (MCPTT Client) SSRC |
||
|
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.2.3.3-3: Floor Granted (Steps 22, 51, Table 7.2.2.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 |
SS-UE1 (MCPTT Client) SSRC |
||
|
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.2.3.3-3A: Floor Granted (Steps 31, 55, Table 7.2.2.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.2.3.3-4: Floor Request (Steps 32, 36, Table 7.2.2.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.2.3.3-5: Floor Request (Step 25, 30, 54, Table 7.2.2.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.2.3.3-6: Floor Deny (Step 33, Table 7.2.2.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.2.3.3-7: Floor Deny (Step 26, Table 7.2.2.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.2.3.3-8: Floor Release (Steps 35, 57, Table 7.2.2.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.2.3.3-9: Floor Release (Steps 28, 38, 52, Table 7.2.2.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.2.3.3-10: Floor Request (Step 45, Table 7.2.2.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.2.3.3-11: Floor Granted (Step 42, Table 7.2.2.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 |
SS-UE1 (MCPTT Client) SSRC |
||
|
User ID |
|||
|
User ID |
px_MCPTT_User_B_ID |
The MCPTT User ID of the one simulated by the SS |
|
|
Floor Indicator |
|||
|
Floor Indicator |
‘00010100 0000000 |
Bit D=1 (Emergency call) bit F=1 (Queueing supported) |
|
Table 7.2.2.3.3-11A: Floor Granted (Step 46, Table 7.2.2.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.2.3.3-12: Floor Release (Step 48, Table 7.2.2.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 |
|
Table 7.2.2.3.3-13: Floor Release (Step 43, Table 7.2.2.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 |
‘00010100 0000000 |
Bit D=1 (Emergency call) bit F=1 (Queueing supported) |
|