6.3 NAS test method and architecture

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

6.3.1 Test configuration

The NAS test method is shown in Figure 6.3.1.

Figure 6.3.1: NAS testing architecture

The single layer distributed test method is used.

The Point of Control and Observation (PCO) are defined as the Dc (Dedicated control) SAP. The NAS test verdicts are assigned depending on the behaviours observed at the PCO.

The TTCN tester provides the NAS TTCN test cases and steps with a simple RRC direct transfer function which buffers the NAS PDU data, converts the data from the NAS TTCN table format into ASN.1, or in reverse way, and delivers all lower layer services of AM-SAP for RB3 and RB4.

The NAS TTCN test cases make also intensively use of the RRC TTCN test steps, in order to:

– Configure, initialize and control the L2 emulator;

– Initialize the UE for testing.

The RRC test steps, which are called by the NAS test cases or steps, interface with the RLC PCOs (UM, AM and TR), the control PCOs CRLC, CMAC and CPHY.

The General control (Gc) SAP and the Notification (Nt) SAP are not applied. Messages exchanged via these SAPs will be replaced with the corresponding RRC TTCN test steps.

The Ut PCO (so called logical interface [4]) is served as the interface to the UE EMMI to allow a remote control of operations, which have to be performed during execution of a test case such as to switch the UE on/off, initiate a call, etc.

6.3.2 Routing UL NAS massages in SS

The UL NAS messages are embedded in RRC messages INITIAL / UL DIRECT TRANSFER. In the UE test, the received UL NAS messages can either be routed to the Dc PCO and verified at the NAS message level, or routed to AM PCO and verified at the RRC message level.

1) RBid =3 at the SS side indicates that the UL NAS high priority messages to be routed to Dc PCO. RB3 applies to RRC_DataInd/Req.

2) RBid= -16 at the SS side indicates the received messages to be routed to RLC AM PCO. RB-16 applies to RLC_DataInd/Req.

The RB3 and RB-16 do not coexist. The TTCN writer uses the MAC and RLC reconfigurations to re-map the RB and the corresponding logical channels. If RB3 has been configured, but a test case needs to re-map the logical channel from RB3 to RB-16 the following way is to replace RB3 with RB-16.

– CMAC_CONFIG_REQ (reconfiguration, RB-16).

Re-mapping on RB-16 which appears in the transport channel and logical channel mapping list.

– CRLC_CONFIG_REQ (reconfiguration, RB-16).

RB-16 appears in the routing info, in order to replace the original mapping on RB3.

Mapping from RB-16 to RB3 is done in the reverse way.