[{"name":"R5-232745","title":"Discussion on GNSS emulation for NTN","source":"Rohde & Schwarz","contact":"Niels Petrovic","contact-id":49274,"tdoctype":"discussion","for":"Approval","abstract":"AI 5.3.38.9\nTS 38.509\nDuring the RAN5#98 a paper [1] was presented discussing the open points for NR NTN TC definition. In this paper we share our view on how to solve the issue of GNSS acquisition for NR-NTN and IoT-NTN.\n2.\tDiscussion\nCurrently RAN5 is discussing two different work items with respect to NTN, one with respect to NR-NTN and the other one covering IoT-NTN. Since for both cases it is necessary to provide the UE with GNSS information, so that the UE can derive its location, it would be beneficial to have a common approach for both cases.\nIn the last meeting an associated action point has been raised: [..]\nAs discussed in [1] there are multiple options to provide the GNSS information to the UE. The most prominent ones being discussed are either using GNSS simulator or providing the UE with one-shot GNSS information via e.g. AT commands.\nFrom a test system vendor perspective both options are feasible, however they present different challenges.\nWhile the usage of a GNSS simulator may provide real-time GNSS information to the UE, there are several drawbacks to this solution. GNSS emulators are designed to provide a wide range of GNSS emulation scenarios for LBS testing. For current NTN testing it seems that there is only a need to provide a fixed position to the UE, thus, using a fully-optioned GNSS simulator would unnecessarily increase the system complexity.\nObservation 1: Using a GNSS simulator unnecessarily increases the test system complexity.\nThe UE needs to know its position in order to calculate the frequency pre-compensation. When using a GNSS simulator the UE needs to determine the position information based on its own GNSS receiver. Measurement uncertainties in this process can propagate through the pre-compensation and impact the measurement results for several TCs. This would need to be carefully considered and assessed.\nObservation 2: Using a GNSS simulator introduces additional uncertainties into the TCs.\nBoth of these issues could be avoided by providing a one-shot GNSS fix to the UE at a defined location using AT commands. \nObservation 3: Using a one-shot GNSS fix does not have the complexity and uncertainty issues of using a GNSS simulator.\nProprietary AT commands on the other hand may have the drawback that they would need to be device specific, which also leads to additional complexity for the test system development. This however could be lessened by introducing a common test function, which can be specified in TS 38.509 and\/or 36.509.\nObservation 4: Test system complexity issues of using proprietary AT commands can be reduced by specifying corresponding test functions.\nTherefore, from a test system vendor perspective it would be beneficial to define test function which provides the GNSS information to the UE. \nProposal: RAN5 defines test functions in TS 38.509 and TS 36.509 to provide the UE with the GNSS information for NTN testing.\nHowever, since there are already several protocol test cases existing for IoT-NTN, it may be difficult to \u201cretroactively\u201d introduce a test function into 36.509. For this case, further discussions may be necessary whether the usage of a test function is feasible or it is required to use proprietary AT commands.\n3.\tProposals\nIn this contribution, we discussed how to provide the GNSS information to the UE for NTN testing, with the following Observations and Proposal.\nObservation 1: Using a GNSS simulator unnecessarily increases the test system complexity.\nObservation 2: Using a GNSS simulator introduces additional uncertainties into the TCs.\nObservation 3: Using a one-shot GNSS fix does not have the complexity and uncertainty issues of using a GNSS simulator.\nObservation 4: Test system complexity issues of using proprietary AT commands can be reduced by specifying corresponding test functions.\nProposal: RAN5 defines test functions in TS 38.509 and TS 36.509 to provide the UE with the GNSS information for NTN testing.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"4.2.2","ainame":"All other topics","tdoc_agenda_sort_order":27450,"status":"noted","reservation_date":"2023-12-05 07:19:57","uploaded":"2023-05-12 12:58:17","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_99_Incheon\/Docs\/R5-232745.zip","group":"R5","meeting":"R5-99","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-233062","title":"Discussion paper on IMS Data Channel test","source":"Huawei, Hisilicon","contact":"zhaobing yang","contact-id":80062,"tdoctype":"discussion","for":"Endorsement","abstract":"The IMS data channel uses the data channel media type as defined in 3GPP Release 16 TS 26.114 and can be used in parallel with other media types such as voice and video in the Multimedia Telephony (MMTel) service. This data channel is highly flexible and can be used to carry any type of information between the User Equipment (UE) and the network or end-to-end between UEs. It is adapted to be used in the 3GPP MMTel context by SA4 group in 3GPP Release 16 TS 26.114 and through extensions to existing call handling procedures developed by CT1 group in 3GPP Release 17 TS 24.229, TS 29.165 and TS 24.173. In 3GPP Release 18, SA2 further studied the IMS architecture enhancements to support data channel services. It is specified in Annex AC of 3GPP TS 23.228.\nFor the progress of NG.134, GSMA NG UPG IDCTF has been working on NG.134 IMS Data Channel profile for nearly a year. NG.134 v0.4 is submitted to GSMA TSG#50 for information. The NG.134 v0.5 is already sent to GSMA NG#17 for approval in 2023Q2.\nHuawei, HiSilicon actually submitted a discussion paper R5-222805 at RAN5#95-e meeting to figure out the related testing and received some comments on the test development, including clear test scope required, feasible test method and the timing\/progress of NG.134 in GSMA.\n2\tDiscussion\nFor the test scope, we have reached agreement that RAN5 will focus on the SIP exchange and not touch the application layer too much. Correspondingly, GSMA has built a new WI to figure out the Data Channel end-to-end service testing.\nIMS Data Channel applies to VoLTE and VoNR. So for each Radio access, the objective includes at least the following cases:\n1.\tInitial Registration to check if UE can include the sip.app-subtype media feature tag with a value \"webrtc-datachannel\" if the UE supports IMS data channel. \n-\tUE side: supports IMS data channel\n-\tSS side: supports SIP without any WebRTC protocol.\n\n2.\tBootstrap data channel (BDC) to check if UE and network can negotiate and establish BDC, including the correct stream ID 0\/10\/100\/110 with http protocol, shown as below.\n-\tSub-cases: MT\/MO, before\/after Voice\/Video\/Voice+Video call establishment.\n-\tUE side: initial BDC establishment and Data Channel Application Retrieval. (Creating test mode control messages or AT command if needed, so far there is no related AT CMD found)\n-\tSS side: supports SIP without any WebRTC protocol if we just verify SDP O\/A negotiation and do not care about the BDC established or not.\n3.\tFail to establish IMS data channel: if IMS DC get failed when SDP O\/A negotiates, legacy IMS call should be supposed to proceed as normal.\n-\tSub-cases: MT\/MO, before\/after Voice\/Video\/Voice+Video call establishment.\n-\tUE side: initial IMS DC establishment along with legacy IMS call. (Creating test mode control messages or AT command if needed)\n-\tSS side: supports SIP without any WebRTC protocol\n\n4.\tApplication data channel (ADC) to check if application data channel can be established. After BDC established, UE will retrieve data channel application so that SS needs to additionally support SCTP over DTLS. Actual application is not needed. SS probably send an arbitrary http packet, maybe containing some simple text after UE sends HTTP GET.\n-\tSub-cases: MT\/MO\n-\tUE side: BDC established and trigger Data Channel Application Retrieval. (Creating test mode control messages or AT command if needed)\n-\tSS side: SCTP over DTLS, HTTP\n\n5.\tIMS data channel associated with an IMS call (Voice, Video) to check if UE can support using data channel simultaneously with voice or video media.\n-\tSub-cases: MT\/MO, before\/after Voice\/Video\/Voice+Video call establishment.\n-\tUE side: initial IMS DC establishment along with legacy IMS call. (Creating test mode control messages or AT command if needed)\n-\tSS side: SCTP over DTLS, HTTP\n3\tProposal\nThe following is proposed:\nProposal: RAN5 to approve the new WI of IMS data channel test cases shown as draft WID R5-233063.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"4.2.2","ainame":"All other topics","tdoc_agenda_sort_order":30620,"status":"noted","reservation_date":"2023-12-05 12:30:54","uploaded":"2023-05-12 13:51:36","revisionof":"","revisedto":"","release":"Rel-17","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_99_Incheon\/Docs\/R5-233062.zip","group":"R5","meeting":"R5-99","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0}]