4 General

36.579-13GPPMission Critical (MC) services over LTEPart 1: Common test environmentRelease 15TS

Editor’s note: Implication to the content of the present chapter due to the introduction of MCVideo and MCData are FFS.

4.0 Introduction

Depending on the TS 36.579-5[5] test model being used, either the LTE UE (with the MCX Client installed) is considered as the IUT (MCX EUTRA test model), or, only the MCX Client is considered as the IUT (MCX IPCAN test model).

4.1 MCPTT Conformance testing test points overview

Figure 4.1.1 provides a general overview of all MCPTT players which may have a role in different conformance testing scenarios together with virtual test points representing the information flow which is intended for conformance testing. The figure is mainly for descriptive purposes and may not necessarily represent a real MCPTT deployment or implementation.

Figure 4.1.1: MCPTT Conformance testing test points model

NOTE 1: Which of the shown entities will be simulated and which will be real implementation depends on the test scenario. In the test scenarios in which they play a part, the entities presented with dashed borders and grey fill will be always simulated whereas, the entities with light yellow fill (UE3) will be Implementation Under Test (IUT). The entities with white fill will be either simulated or IUTs or real implementation (e.g. network) depending on the test scenario.

NOTE 2: While showing the different players, figure 4.1.1 should not be understood as showing test environment implementation.

The test points shown on Figure 4.1.1 cover behaviour/requirements observed at various reference points and communication scenarios:

– MCPTT on-network (whenever relevant, reference points as specified in TS 23.179 [8] Functional model description clause 7.3.1 ‘On-network functional model’ are referred):

– Application plane (MCPTT-1, MCPTT-4, MCPTT-7, MCPTT-8 and MCPTT-9), and, (CSC-1, CSC-2, CSC-4 and CSC-8); Signalling control plane (SIP-1, HTTP-1 and HTTP-2). Test point: (1) or (2). IUT: the UE or the MCPTT Client or the MCPTT Server.

– MCPTT-3 (between different MCPTT Servers), CSC-7 (other group management Servers, normally associated with other MCPTT Servers); Signalling control plane (SIP-2, HTTP-1, HTTP2 and HTTP-3). Test point: (4). IUT: the MCPTT Server.

– MCPTT off-network (TS 23.179 [8], clause 7.3.2 ‘Off-network functional model’). Test point: (3). IUT: the UE.

– LTE Legacy requirements between UE and EPS and between 2 UEs (covering e.g. Bearer Management at the UE side, ProSe including among others UE-to-network relay, MBMS). Test point: (1), (2) or (3).

Figure 4.1.2 provides a general overview of functions distributions at the MCPTT server side when multiple MCPTT Servers are involved. More functional models can be found in TS 24.379 [9].

Figure 4.1.2: MCPTT Conformance testing Client-to-Client test points model

NOTE 3: While showing the different players and Server functionality, figure 4.1.2 should not be understood as showing test environment implementation.

The test points shown on Figure 4.1.2 provide an example of how 2 different communication scenarios between 2 MCPTT Servers will result in the communication between the servers being monitored at different test points (4.1) and (4.2). It should be noted that Figure 4.1.2 does not imply the physical existence of 2 test points during MCPTT Server-to-Server testing rather it shows two different information flows which need to be verified for conformance. In practice this will also mean that for testing the MCPTT Server on the Server-to-Server interface (test point 4 on Figure 4.1.1), the System Simulator (SS) will need to implement (i.e. be able to simulate) at least all 3 MCPTT functions.

4.2 MCPTT Conformance testing test environment overview

Based on the test points models shown in clause 4.1 examples for test environment implementations are provided below. Figures 4.2.1 to 4.2.3 show test configuration where the Implementation Under Test (IUT) and the System Simulator communicate, one with the other, over the LTE radio interface (test points (1), (2) and (3)). Figure 4.2.4 shows test configuration where the IUT and the system simulator, simulating MCPTT Clients, communicate, one with the other, over the LTE radio interface (test points (1)). Figures 4.2.5 and 4.2.6 show test configuration where the IUT and the System Simulator communicate, one with the other, over the MCPTT-3 interface, as defined by TS 23.179 [8], clause 7.5.2.4 (test points (4)).

Figure 4.2.1: Testing the MCPTT Client (on-network)

NOTE 1: Figure 4.2.1 covers also the case for testing the UE at interface (1) when the IUT behaves as a Relay. For testing this the existence of another UE playing the role of an UE off-network which uses the Relay to connect to the Server will be needed. This could be implemented by the SS simulating both in similar manner as it is shown on Figure 4.2.2.

Figure 4.2.2: Testing the MCPTT Client (on-network) Relay side

NOTE 1: Figure 4.2.2 covers the case for testing the UE at interface (2) when the IUT behaves as a Relay. For testing this, the existence of LTE NWK and Server to which the Relay relays the data will be needed. This could be implemented by the SS simulating both.

Figure 4.2.3: Testing the MCPTT Client (off-network)

Figure 4.2.4: Testing the MCPTT Server (server-to-client)

Figure 4.2.5: Testing the MCPTT Server (server-to-server), Controlling function

Figure 4.2.6: Testing the MCPTT Server (server-to-server), Originating function

4.3 MCPTT Conformance testing players and roles assumptions

Based on the described in clause 4.2 test environment scenarios a number of players and their roles have been designated to facilitate the test specification and provide a consistent test description.

For the purposes of MCPTT Client testing

1 MCPTT Server:

– Server A simulated by the SS (in the case of on-network operation).

2 MCPTT Clients:

– Client A installed on the implementation under test

– Client B simulated by the System Simulator (SS) either explicitly (in the case of off-network operations), or, implicitly (in the case of on-network operation).

3 MCPTT Users:

– User A registered with Client A and operating on the implementation under test

– User B registered with Client B simulated by the System Simulator (SS) either explicitly (in the case of off-network operations), or, implicitly (in the case of on-network operation); pre-set at User A configuration as User allowed to be called by User A for any types of calls

– User C known to the User A, not involved in any communication, defined for the sole purpose of testing if the User A/Client A can distinguish between different users when choosing one of them for action; pre-set at User A configuration as User allowed to be called by User A for any types of calls.

4 MCPTT groups:

– Group A to which User A is implicitly affiliated, pre-set at User A configuration, and, comprising as members User A, User B and User C, to be available throughout the entire testing.

– Group D to which User A is not implicitly affiliated, pre-set at User A configuration, and, comprising as members User B and User C, to be used for testing group affiliation.

– Groups B and C not pre-set at User A configuration, to be used for testing creation and termination of groups.

For the purposes of MCPTT Server testing

1 MCPTT Server:

– Server A installed on the implementation under test.

2 MCPTT Clients:

– Client A simulated by the System Simulator (SS)

– Client B simulated by the System Simulator (SS).

2 MCPTT Users:

– User A registered with Client A simulated by the System Simulator (SS) ; pre-set at User A configuration as User allowed to be called by User A for any types of calls

– User B registered with Client B simulated by the System Simulator (SS); pre-set at User A configuration as User allowed to be called by User A for any types of calls

1 MCPTT group:

– Group A to which User A is implicitly affiliated, pre-set at User A configuration, and, comprising as members User A and User B to be available throughout the entire testing.

4.4 References to TS 33.179 and TS 33.180

For the purposes of this Technical Specification, it is assumed that TS 33.180 supersedes TS 33.179 and is a backwards compatible substitute for TS 33.179.

4.5 MCVideo Conformance testing test points overview

Figure 4.5.1 provides a general overview of all MCVideo players which may have a role in different conformance testing scenarios together with virtual test points representing the information flow which is intended for conformance testing. The figure is mainly for descriptive purposes and may not necessarily represent a real MCVideo deployment or implementation.

Figure 4.5.1: MCVideo Conformance testing test points model

NOTE 1: Which of the shown entities will be simulated and which will be real implementation depends on the test scenario. In the test scenarios in which they play a part, the entities presented with dashed borders and grey fill will be always simulated whereas, the entities with light yellow fill (UE 1 or UE3) will be Implementation Under Test (IUT).

NOTE 2: While showing the different players, figure 4.5.1 should not be understood as showing test environment implementation.

The test points shown on Figure 4.5.1 cover behaviour/requirements observed at various reference points and communication scenarios:

– MCVideo on-network (TS 23.280 [110] Functional model description clause 7.3.1 ‘On-network functional model’ and TS 23.281 [91] Functional model description clause 6.1.1 ‘On-network functional model’.):

– Application plane (MCVideo-1, MCVideo-4, MCVideo-5, MCVideo-6, MCVideo-7, MCVideo-8 and MCVideo-9), and, (CSC-1, CSC-2, CSC-4, CSC-8, and CSC-14); Signalling control plane (SIP-1, HTTP-1 and HTTP-2). Test point: (1). IUT: the UE or the MCVideo Client.

– MCVideo off-network (TS 23.280 [110], clause 7.3.2 ‘Off-network functional model’ and TS 23.281 [91], clause 6.1.2 ‘Off-network functional model’.). Test point: (2). IUT: the UE.

– LTE Legacy requirements between UE and EPS and between 2 UEs (covering e.g. Bearer Management at the UE side, ProSe, MBMS). Test point: (1) or (2).

4.6 MCVideo Conformance testing test environment overview

Based on the test points models shown in clause 4.5 examples for test environment implementations are provided below. Figures 4.6.1 and 4.6.2 show test configuration where the Implementation Under Test (IUT) and the System Simulator communicate, one with the other, over the LTE radio interface (test points (1) and (2)).

Figure 4.6.1: Testing the MCVideo Client (on-network)

Figure 4.6.2: Testing the MCVideo Client (off-network)

4.7 MCVideo Conformance testing players and roles assumptions

Based on the described test environment scenarios in clause 4.6, a number of players and their roles have been designated to facilitate the test specification and provide a consistent test description.

For the purposes of MCVideo Client testing

1 MCVideo Server:

– Server A simulated by the SS (in the case of on-network operation).

2 MCVideo Clients:

– Client A installed on the implementation under test

– Client B simulated by the System Simulator (SS) either explicitly (in the case of off-network operations), or, implicitly (in the case of on-network operation).

3 MCVideo Users:

– User A registered with Client A and operating on the implementation under test

– User B registered with Client B simulated by the System Simulator (SS) either explicitly (in the case of off-network operations), or, implicitly (in the case of on-network operation); pre-set at User A configuration as User allowed to be called by User A for any types of calls

– User C known to the User A, not involved in any communication, defined for the sole purpose of testing if the User A/Client A can distinguish between different users when choosing one of them for action; pre-set at User A configuration as User allowed to be called by User A for any types of calls.

4 MCVideo groups:

– Group A to which User A is implicitly affiliated, pre-set at User A configuration, and, comprising as members User A, User B and User C, to be available throughout the entire testing.

– Group D to which User A is not implicitly affiliated, pre-set at User A configuration, and, comprising as members User B and User C, to be used for testing group affiliation.

– Groups B and C not pre-set at User A configuration, to be used for testing creation and termination of groups.

4.8 MCData Conformance testing test points overview

Figure 4.8.1 provides a general overview of all MCData players which may have a role in different conformance testing scenarios together with virtual test points representing the information flow which is intended for conformance testing. The figure is mainly for descriptive purposes and may not necessarily represent a real MCData deployment or implementation.

Figure 4.8.1: MCData Conformance testing test points model

NOTE 1: Which of the shown entities will be simulated and which will be real implementation depends on the test scenario. In the test scenarios in which they play a part, the entities presented with dashed borders and grey fill will be always simulated whereas, the entities with light yellow fill (UE1 or UE3) will be Implementation Under Test (IUT).

NOTE 2: While showing the different players, figure 4.8.1 should not be understood as showing test environment implementation.

The test points shown on Figure 4.8.1 cover behaviour/requirements observed at various reference points and communication scenarios:

– MCData on-network (TS 23.280 [110] Functional model description clause 7.3.1 ‘On-network functional model’ and TS 23.282 [91] Functional model description clause 6.4.1, 6.5.1, and 6.6.1 ‘On-network functional model’.):

– Application plane (MCData-SDS-1, MCData-SDS-2, MCData-SDS-3, MCData-FD-1, MCData-FD-2, MCData-FD-3, MCData-FD-4, MCData -5, and MCData -6), and, (CSC-1, CSC-2, CSC-4, CSC-8, and CSC-14); Signalling control plane (SIP-1, HTTP-1 and HTTP-2). Test point: (1). IUT: the UE or the MCData Client.

– MCData off-network (TS 23.280 [110], clause 7.3.2 ‘Off-network functional model’ and TS 23.282 [91], clause 6.4.2 ‘Off-network functional model’.). Test point: (2). IUT: the UE.

– LTE Legacy requirements between UE and EPS and between 2 UEs (covering e.g. Bearer Management at the UE side, ProSe). Test point: (1) or (2).

4.9 MCData Conformance testing test environment overview

Based on the test points models shown in clause 4.8 examples for test environment implementations are provided below. Figures 4.9.1 and 4.9.2 show test configuration where the Implementation Under Test (IUT) and the System Simulator communicate, one with the other, over the LTE radio interface (test points (1) and (2)).

Figure 4.9.1: Testing the MCData Client (on-network)

Figure 4.9.2: Testing the MCData Client (off-network)

4.10 MCData Conformance testing players and roles assumptions

Based on the described test environment scenarios in clause 4.9, a number of players and their roles have been designated to facilitate the test specification and provide a consistent test description.

For the purposes of MCData Client testing

1 MCdata Server:

– Server A simulated by the SS (in the case of on-network operation).

2 MCData Clients:

– Client A installed on the implementation under test

– Client B simulated by the System Simulator (SS) either explicitly (in the case of off-network operations), or, implicitly (in the case of on-network operation).

3 MCData Users:

– User A registered with Client A and operating on the implementation under test

– User B registered with Client B simulated by the System Simulator (SS) either explicitly (in the case of off-network operations), or, implicitly (in the case of on-network operation); pre-set at User A configuration as User allowed to be called by User A for any types of calls

– User C known to the User A, not involved in any communication, defined for the sole purpose of testing if the User A/Client A can distinguish between different users when choosing one of them for action; pre-set at User A configuration as User allowed to be called by User A for any types of calls.

4 MCData groups:

– Group A to which User A is implicitly affiliated, pre-set at User A configuration, and, comprising as members User A, User B and User C, to be available throughout the entire testing.

– Group D to which User A is not implicitly affiliated, pre-set at User A configuration, and, comprising as members User B and User C, to be used for testing group affiliation.

– Groups B and C not pre-set at User A configuration, to be used for testing creation and termination of groups.