[{"name":"R5-231046","title":"ASN.1 extension groups in default information elements contents","source":"Ericsson","contact":"Bo J\u00f6nsson","contact-id":76116,"tdoctype":"discussion","for":"Endorsement","abstract":"The content of  RRC is specified using ASN.1 by RAN2. According to TS 38.331 [1], 6 and annex A. Some extracts for information \n\u201c6.1.2\tNeed codes and conditions for optional fields\n\u2026 groups of non-critical extensions using double brackets (referred to as extension groups)\u201d\n\u201cA.3.3 Message definition\n\u2026 Non-critical extensions are characterised by the addition of new information to the original specification of the PDU type. If not comprehended, a non-critical extension may be skipped by the decoder, whilst the decoder is still able to complete the decoding of the comprehended parts of the PDU contents.\u201d\n\u201cA.4.1 General principles to ensure compatibility\nThe non-critical extension mechanism is the primary mechanism for introducing protocol extensions\u2026\u201d\n\u201cA.4.3.1 General principles\nThe mechanisms to extend a message in a non-critical manner are defined in A.3.3. W.r.t. the use of extension markers, the following additional guidelines apply:\n\u2026\nThe extension marker (\"...\") is the primary non-critical extension mechanism that is used\u201d\n2\tDiscussion\nTS 38.508-1 Default NG-RAN RRC message and information elements contents\nSpecifically, the clause 4.6.3 Radio resource control information elements should include ASN.1 fields and values used by normally more than one test case. Unused non-critical extensions provide no valuable information. \nA subset of mainly rel-16 and rel-17 optional and not used ASN.1 fields (TS 38.331 [1], 6.3) have been added. More features will be discussed and a guideline for maintenance purpose should be agreed.\nObservation 2-1: \nSeveral non-used extension groups are present in the default common test environment. \nProposal 2-1: \nTo not include any non-used extension groups in the common test environment [2].\n3\tProposal\nIt\u2019s proposed to implement the proposal 2-1.\n4\tReferences\n[1] 3GPP TS 38.331: \"NR; Radio Resource Control (RRC); Protocol specification\".\n[2] 3GPP TS 38.508-1: \"5GS; User Equipment (UE) conformance specification; Part 1: Common test environment\".","secretary_remarks":"","agenda_item_sort_order":980,"ainumber":"6.4.7","ainame":"Discussion Papers \/ Work Plan \/ TC lists","tdoc_agenda_sort_order":10460,"status":"noted","reservation_date":"2023-02-17 10:04:58","uploaded":"2023-02-17 11:01:19","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_98_Athens\/Docs\/R5-231046.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-231170","title":"TS 38.523-1 Tracker status before RAN5-98","source":"Huawei, Hisilicon","contact":"zhaobing yang","contact-id":80062,"tdoctype":"other","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":980,"ainumber":"6.4.7","ainame":"Discussion Papers \/ Work Plan \/ TC lists","tdoc_agenda_sort_order":11700,"status":"noted","reservation_date":"2023-02-17 12:30:34","uploaded":"2023-02-17 13:28:25","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_98_Athens\/Docs\/R5-231170.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-231176","title":"Impact of DNS IP address inclusion in PDU Session Establishment Accept message","source":"Qualcomm Incorporated, Rohde & Schwarz","contact":"Bharadwaj Kumar Cheruvu","contact-id":68613,"tdoctype":"discussion","for":"Endorsement","abstract":"Prose CR [5] introduced inclusion of DNS IPV4 and IPV6 addresses in PDU Session Establishment Accept message when UE requests for it in PDU Session Establishment Request message. This causes an issue while running NR protocol test cases from [1], [2].\n2.\tDiscussion\nIn NR, when mobile data is enabled, UE requested PDU session is established automatically after completion of Registration procedure on same RRC connection.\nDevice under test may be configured to trigger multiple PDU sessions (IMS and Internet). In a common scenario execution with multi PDU configuration, IMS DNN would automatically be brought up after the registration procedure and additional PDU session (for internet DNN) may be brought up automatically by UE when mobile data is enabled on the UE.\nProse CR [5] introduced inclusion of DNS server IP address in PDU Session Establishment Accept message if the UE requested for it in the PDU Session Establishment Request message. However, when Mobile data is ON, UE may start sending multiple DNS queries and thereby initiate unexpected service request procedures. This causes failure of NR protocol test cases in [1], [2].\nThe changes in [5] (associated with TTCN CR [6]) were introduced to handle the issue observed while running XCAP test cases (a XCAP enabled UE may resolve the IP address of the XCAP server by sending DNS query). \nFor non-XCAP test cases, it is not necessary to have DNS IP address in PDU Session Establishment Accept message. Hence to address the afore mentioned execution issue, it is recommended to not include DNS IP address in PDU Session Establishment Accept message.\nFor XCAP test cases, as specified in clause A.21 of [2], UE shall be registered to IMS on an IMS PDU session and at least have one PDU session for Internet active. It is recommended to have DNS IP address in PDU Session Establishment Accept messages for all PDU sessions. However, the XCAP testcases may still fail as the UE may start sending multiple DNS queries and thereby initiate unexpected service request procedures if Mobile data is ON. \n3.\tProposal\n\u2022\tProposal #1:\tUpdate default message content of PDU SESSION ESTABLISHMENT ACCEPT in Table 4.7.2-2 of [3] to have DNS address assigned only for XCAP test cases and\n\n\u2022\tProposal #2:\tUpdate XCAP testcase related procedures in [2] about the impact of Mobile data, px_MobileDataOn (defined in [4]).","secretary_remarks":"","agenda_item_sort_order":980,"ainumber":"6.4.7","ainame":"Discussion Papers \/ Work Plan \/ TC lists","tdoc_agenda_sort_order":11760,"status":"noted","reservation_date":"2023-02-17 12:51:37","uploaded":"2023-02-17 12:53:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"TEI15_Test"},{"winame":" 5GS_NR_LTE-UEConTest"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_98_Athens\/Docs\/R5-231176.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0}]