MCC TF160 / SS Vendors Sidebar Tuesday 20th August 2017

Agenda TTCN-2 UTRA AccessStratumReleaseIndicator upgrade Encoding rules for RRC ASN.1: UTRA, E-UTRA, 5G NR IMSoWLAN: XCAP signalling Supporting DS2 in WLAN Test Model.

TTCN-2 UTRA AccessStratumReleaseIndicator upgrade In order to ensure the IE AccessStratrumReleaseIndicator is logged correctly for Rel-14 UE’s it is proposed to upgrade the type AccessStratumReleaseIndicator. AccessStratumReleaseIndicator ::= ENUMERATED { rel-4, rel-5, rel-6, rel-7, rel-8, rel-9, rel-10, rel-11, rel-12, rel-13, rel-14, spare5, spare4, spare3, spare2, spare1 } This change will be implemented in TTCN-2 delivery iWD17wk35.

Encoding rules for RRC ASN.1 3GPP requirements regarding RRC ASN.1 encoding: TS 25.331 cl. 12.1: basic production = unaligned PER encoding according to X.691(07/2002) except for the 0 to 7 bits added at the end to produce a multiple of 8 bits. TS 36.331 (and TS 38.331) cl. 8.3: basic production = unaligned PER encoding according to X.691(07/2002) (i.e. octet aligned).  Different encoding rules for UTRA ASN.1 & LTE(incl. NB-IoT) ASN.1. Problem statement: No provision of encoding rules in TTCN to distinguish the 2 slightly separate encoding rules. import from UTRAN_RRC_ASN1_Definitions language "ASN.1:2002“ all; import from EUTRA_RRC_ASN1_Definitions language "ASN.1:2002" all; import from NBIOT_RRC_ASN1_Definitions language "ASN.1:2002" all;

Encoding rules for RRC ASN.1 Solution: Prose: Add a new normative clause in 36.523-3 to specify encoding rules for RRC ASN.1. TTCN: Update TTCN import statements as follows: import from UTRAN_RRC_ASN1_Definitions language "ASN.1:2002“ all with {encode "UNALIGNED_PER_25331_EncRule"}; import from EUTRA_RRC_ASN1_Definitions language "ASN.1:2002" all with {encode "UNALIGNED_PER_EncRule"}; import from NBIOT_RRC_ASN1_Definitions language "ASN.1:2002" all with {encode "UNALIGNED_PER_EncRule"}; f_OctetAlignedBitString(): Perform a clean-up of TTCN where f_OctetAlignedBitString() is used. TF160 to raise a TTCN CR.

XCAP in IMSoWLAN after R5-172937 RAN 5 agreement IR. 51 provides two main deployment scenarios (DSs) (DS1) Wi-Fi access without PDN connection Current TTCN approach (DS2) with the APN to be used for XCAP requests in Wi-Fi access. RAN5 decided after R5-172937 agreement that test procedure in IMSoWLAN Supplementary Services TC with XCAP signaling shall be testable with either DS1 or DS2. RAN5 CRs being presented at RAN5#76 to address the new requirement on XCAP test cases.

DS2 Scenario Overview According to IR.51 section 4.7.3 „The UE must establish a separate Swu instance (i.e a separte Ipsec Tunnel) for the PDN connection to the IMS well-known APN and to the APN to be used for XCAP request.“ Swu1: IMS PDN Connection Swu2 : XCAP PDN Connection TS 23402 Figure 4.2.2-1: Non-Roaming Architecture within EPS using S5, S2a, S2b

TTCN-3 Test model: DS1 vs DS2 DS1 : Wi-Fi access without PDN connection DS2: EPC-integrated WLAN TTCN -3 EPDG Tunnel –> Normal IMS P-CSCF Server HTTP/XCAP Server Without PDN - XCAP UE TTCN -3 EPDG Tunnel –> Normal IMS P-CSCF Server HTTP/XCAP Server UE EPDG Tunnel -> XCAP IP PTC

DS2: XCAP/HTTP server inside of the 3GPP network UE non-3GPP network: WLAN ePDG IPsec tunnel non-3GPP IP-Address 3GPP IP-Address 3GPP network 3GPP IP-Address non-3GPP IP-Address ICMPv6-Server DHCP-Server DNS-Server remote UE AAA-Server NOTE: in general non-3GPP and 3GPP addresses are different (different networks; un-trusted network) non-3GPP IP-Address HTTP-Server 3GPP IP-Address

DS2: IP Address Overview px_WLAN_UE_AddrIPvx px_WLAN_UE_AddrIPvx px_IPvx_Address1_UE px_IPvx_Address1_NW IMS IpSec Tunnel px_IPvx_Address2_UE XCAP IpSec Tunnel px_IPvx_Address2_NW P-CSCF NW EPDG UE IMS NW WLAN UE WLAN XCAP/ HTTP Server

DS2: APN Handling IMS IPSec Tunnel Establishment XCAP IPSec Tunnel Establishment UE/SS TTCN UE/SS TTCN IKE_SA_INIT_Ind IKE_SA_INIT_Ind IKE_AUTH_Req without AccessPointName IKE_AUTH_Req with AccessPointName EAP_AKA_Cmpl EAP_AKA_Cmpl IPSecTunnelEstabCmpl IPSecTunnelEstabCmpl According to 24.302: “ The UE indicates a request for the default APN by omitting the "IDr" payload“. Therefore, AccessPointName included in IKE_AUTH_REQ might be omitted when IMS is the Default APN (pc_IMS_APN_default set to true) during the IMS IPSec Tunnel Establishment.

DS2: Test Model Open Issues Test Model updates XCAP/HTTP server is inside of the 3GPP Network ASP extensions Handling multiple IPSec tunnels is not supported by current ePDG ASP Definition. Non-backwards compatible changes likely to be required. APN name might be needed in order to identify the PDN type. IP_DrbInfo_Type only considers one IPsecTunnel to be routed. IPSecTunnel union field to be extended to support multiple IPsec Tunnels. Test procedure to cover multiple PDN Connections New generic procedure for XCAP establishment to be added (R5-173591, R5-173592)