6.7 MAC test method and architecture

34.123-33GPPPart 3: Abstract test suite (ATS)TSUser Equipment (UE) conformance specification

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

6.7.1 Testing architecture

Figure 6.7.1 illustrates a typical realization of the MAC ATS.

Figure 6.7.1: MAC ATS single party test method

6.7.2 Test method

The single party test method is used for MAC testing.

Separation of TTCN test cases from the configuration of the tester and initialization of the UE is achieved by using test steps. For each MAC test case, common test steps will be used to perform the configuration of the tester and the appropriate generic setup procedures as described in 3GPP TS 34.108 [3]. These test steps will make use of PCOs AM, UM, TM, CRLC, CMAC, and CPHY.

Three PCOs are provided at the top of the RLC emulation in the tester, one corresponding to each of the available RLC modes: acknowledged, unacknowledged, and transparent. Routing information for different radio bearers used at these PCOs will be provided in ASP parameters.

The queues shown in the RLC emulation in Figure 6.5.2.2 indicate that normal RLC transmit and receive buffering will be used to isolate the TTCN test suite from the real time issues involved if messages are sent directly to the MAC layer.

A flag is required within the CMAC Config Req to indicate that the SS MAC emulation must not add or remove any MAC header information, even if header fields should be present according to the configured channels. This flag shall allow control of the MAC header on a per logical channel basis. For example, it shall be possible to configure 4 DCCHs and a DTCH mapped to a DCH, such that the MAC will add / remove header information for the DCCHs, but not for the DTCH.

The MAC TTCN test cases make also use of the NAS TTCN test steps in order to bring UE to Idle state. The NAS test steps, which are called by the MAC test cases or steps, interface with the Dc PCO.

For MAC testing, the following RB Ids are used for the high priority NAS RB within the system simulator depending on the MAC configuration being simulated.

RB Id	Simulated configuration
-14	DCCH mapped to FACH
-15	DCCH mapped to DCH
-18	CCCH mapped to FACH

The SS decoder can use the RB Id to determine which MAC header fields are present, and create the appropriate abstract structure during the decode process. The SS decoder must understand enough of the MAC peer-to-peer protocol to determine which fields are present.

For example, the semantics of the UE Id Type field must be known to determine how many bits should be present in the UE Id field.

The MAC PDUs for MAC testing will always contain an AM RLC PDU (data or status) using 7 bit length indicators. See the RLC test method for further information on the SS decoder requirements for RLC PDUs.

Ciphering shall be disabled for all MAC tests.

6.7.2.1 Abnormal decoding situations

If the SS decoder cannot convert the received data into the supported structure, the SS shall terminate the test case immediately and indicate that a test case error has occurred.

6.7.2.2 MAC_es/e test method (Rel-6 or later)

MAC test method for MAC_es/e is depictured in the following figure. In the UE side the RLC entity is AM mode, in the SS the mode of RLC in downlink direction is TM, the AM mode functions are implemented in TTCN. In the uplink direction, the mapping between RB identity and logical channel identity is configured in the RLC entity, the RLC entity passes any data block received on the logical channel to the RB identified by tsc_RB_DTCH_E_DCH_MAC(value is -20), tsc_RB_DTCH_E_DCH_MAC1(-21), or tsc_RB_DTCH_E_DCH_MAC2(-22). Whenever a RLC pdu received through one of the specified RB identifiers, the TTCN shall generate a RLC ack for it and send it on the downlink direction.

Figure 6.7.2.2: MAC_es/e testing model

6.7.2.3 MAC_is/i test method (Rel-8 or later)

MAC test method for MAC is/i is depictured in the following figure. In the UE side the RLC entity is AM or UM mode, in the SS the mode of RLC in downlink direction is TM, the AM or UM mode functions are implemented in TTCN. In the uplink direction, the mapping between RB identity and logical channel identity is configured in the RLC entity, the RLC entity passes any data block received on the logical channel to the RB identified by tsc_RB_DTCH_E_DCH_MAC(value is -20), tsc_RB_DTCH_E_DCH_MAC1(-21), or tsc_RB_DTCH_E_DCH_MAC2(-22). Whenever a RLC pdu received through one of the specified RB identifiers, the TTCN shall generate a RLC ack for it and send it on the downlink direction.

Figure 6.7.2.3: MAC_is/i testing model