[{"name":"R5-193841","title":"Discussion about time alignment between latest TTCN and GCF meeting","source":"Huawei,Hisilicon","contact":"Yuchun Wu","contact-id":77331,"tdoctype":"discussion","for":"Endorsement","abstract":"AI 4.2.1\nThe time gap between GCF meeting and latest TTCN release is about 5 weeks.\nIn this NR initial phase, many TCs need to have 4 weeks review period in RAN5.\nOnly about 1 week is left for test if the verification must use latest TTCN for RAN5 and GCF review, which means very few TCs could be submitted to GCF, therefore not able to satisfy industry desire of NR progress.\nThis problem exist not for one meeting cycle, but may exist for several meeting cycles until NR TCs in the TTCN is quite stable.\nPossible solutions:\nOpt 1: Strictly follow current PRD12 to always use latest TTCN.\nVery difficult to satisfy industry desire of NR progress.\nA TC in current latest TTCN may change in later time, thus need to be re-verificated with later latest TTCN anyway.\nOpt 2: In case the time gap between latest TTCN and GCF meeting is less than 6 weeks, RAN5 allow to use the latest TTCN which is 6-weeks beyond GCF meeting, and give Provisionally Agreed if the test result was approved.\nThe test must be re-verificated based on latest TTCN and submit to RAN5 in 30 calendar days for a 2 week review. If fail to pass the review, the test will be downgraded.\nOpt 3: Adjust meeting time to avoid the issue of too short time for test\nAdjust RAN5 meeting and following TTCN release time one month earlier. \nAdjust GCF meeting time one month later.\n\nProposal: RAN5 allow to use the latest TTCN which is 6-weeks beyond GCF meeting if the time gap between latest TTCN and GCF meeting is less than 6 weeks (same as GCF rule). Modify PRD12 as attached file to solve this problem of too short time for test and submitting for RAN5 and GCF review.","secretary_remarks":"","agenda_item_sort_order":359,"ainumber":"6.3.5.19","ainame":"\tDiscussion Papers \/Work Plan \/ TC lists","tdoc_agenda_sort_order":38410,"status":"noted","reservation_date":"2019-04-29 06:17:18","uploaded":"2019-04-30 10:25:13","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_NR_LTE-UEConTest"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_83_Reno\/Docs\/R5-193841.zip","group":"R5","meeting":"R5-83","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-194039","title":"RAN5 Testing of Network Slicing in 5GC","source":"Qualcomm Korea","contact":"yogesh tugnawat","contact-id":63855,"tdoctype":"discussion","for":"Endorsement","abstract":"According to TS 24.501 clause 4.6.2 there are several conditions which will result in NSSAI storage modification. The following table summarizes the different NAS messages with content which can be used to achieve writing or deleting of a specific NSSAI: [3]. In order to test these conformance requirements, RAN5 tests have the need to read and set below NSSAI(s).\nAt CT1#114, it was proposed in C1-190191 to introduce new AT command +C5GNSSAI to allow setting\/deleting the default configured NSSAI and configured NSSAI(s) at the UE, as well as deleting the allowed NSSAI(s) stored at the UE. This was done to enable the test sequence proposed for RAN5 test case in 5GC WP. Concerns were raised in CT1 that the command could be mis-used to overwrite values received from the network via NAS signalling, so eventually the AT command was down-scoped to only allow setting of the default configured NSSAI, and restricted to the case when the UE has not already received a default configured NSSAI value via NAS signalling (agreed CR in C1-190671).\nAt CT1#115, another attempt was made to enable the RAN5 test sequence by proposing in C1-191044 to extend NAS signalling to trigger the UE to delete the default configured NSSAI, configured NSSAI or allowed NSSAI by sending to the UE an NSSAI IE including zero S-NSSAI in a NAS message. However the CR was not agreed either due to the lack of related stage 2 requirements and the lack of use cases in real networks. At RAN5#82, we did not make progress to resolve this as CT1 discussions were not completed.\nAs a result, RAN5 is still unable to test scenarios which require setting\/deleting the default configured, configured, or allowed NSSAIs at the UE.\nThe purpose of this document is to propose a way forward to resolve this situation.\nProposal\nBased on the discussion in the previous section, it is proposed to proceed with one of the following proposals:\nProposal 1: Complete the CT1 AT CMD +C5GTESTNSSAI with below information\\actions\n\tLink this AT CMD to an existing TLB Mode\n\tInform CT1 of the RAN5 agreement\nProposal 2: Come up with a new TLB mode\\cmd using NAS message in TS 38.509 to add same functionalities as the AT CMD in Proposal#1. This may need 1-2 meeting cycles.\nProposal 3: Allow both Proposal#1 and Proposal#2 based on UE Implementation","secretary_remarks":"","agenda_item_sort_order":359,"ainumber":"6.3.5.19","ainame":"\tDiscussion Papers \/Work Plan \/ TC lists","tdoc_agenda_sort_order":40390,"status":"noted","reservation_date":"2019-05-01 02:21:53","uploaded":"2019-05-04 04:01:08","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_NR_LTE-UEConTest"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_83_Reno\/Docs\/R5-194039.zip","group":"R5","meeting":"R5-83","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]