[{"name":"S2-1908653","title":"Liaison Statement from SC 29\/WG 11: Liaison statement on MPEG Network-Based Media Processing","source":"ISO\/IEC JTC 1\/SC 29","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"MPEG is pleased to inform you that the Network-Based Media Processing (NBMP) specification has progressed into Draft International Standard (DIS) during our 127th MPEG meeting. NBMP specifies an abstraction layer for setting up and managing media processing workflows on any cloud or edge computing platform. It allows content and service providers to describe, deploy, and control media processing for their content in the network\/cloud. NBMP workflows are composed of multiple media processing tasks that are connected to build a direct acyclic graph to process incoming media and metadata from a media source and to produce processed media and metadata streams, which are subsequently published for consumption by media sinks. The DIS specification brings several quality improvements and clarifications to the different functionalities of the NBMP standard. MPEG would like to invite you to consider NBMP for your future work on media processing and to share your comments and thoughts on this version of the NBMP specification. You are also encouraged to subscribe to the AHG mailing list at https:\/\/lists.aau.at\/mailman\/listinfo\/mpeg-nbmp.","secretary_remarks":"Proposed to note. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10040,"status":"noted","reservation_date":"2019-09-16 19:37:37","uploaded":"2019-09-16 21:37:53","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6, SA WG2","Cc":"","lsoriginalls":"ISO\/IEC JTC1\/SC29\/WG11\/N1873","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908653.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1908654","title":"LS from ITU-T FGVM: LS on the call for proposals for an internationally agreed Vehicular Multimedia Architecture","source":"ITU-T FGVM","contact":"Jun Li","contact-id":72143,"tdoctype":"LS in","for":"Information","abstract":"We are pleased to inform you about the recent activities of the ITU Focus Group on Vehicular Multimedia (FG-VM). The FG-VM has almost completed a technical report on 'Use Cases and Requirements for Vehicular Multimedia'. The latest version of this Technical Report is attached for your information and any comments. According to the finding of the technical report, during the fifth meeting of the FG-VM, held in Changchun, China, 11-12 July 2019, it was agreed to issue a call for proposals to initiate the activities under the Working Group 2 on Vehicular Multimedia Architecture. - https:\/\/www.itu.int\/en\/ITU-T\/focusgroups\/vm\/Documents\/FGVM_CallForProposals.pdf All interested stakeholders, namely OEMs, Tier1 and Tier2 suppliers, are invited to submit their proposals for an internationally agreed Vehicular Multimedia Architecture. Proposals should be submitted by 4 September 2019 to tsbfgvm@itu.int. The proposals will be discussed at the 11-12 September 2019 meeting of the FG-VM in Budapest, Hungary. More info on FG-VM website: https:\/\/www.itu.int\/en\/ITU-T\/focusgroups\/vm","secretary_remarks":"Proposed to note. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10050,"status":"noted","reservation_date":"2019-09-16 19:37:37","uploaded":"2019-09-16 21:37:53","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"Relevant bodies for automotive standardization","Cc":"","lsoriginalls":"FGVM-LS007","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908654.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1908670","title":"LS from CT WG4: LS on 5GS Enhanced support of OTA mechanism for UICC configuration parameter update","source":"CT WG4","contact":"Ulrich Wiehe","contact-id":73600,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 have discussed the attached WID on '5GS Enhanced support of OTA mechanism for UICC configuration parameter update' and kindly ask SA WG2, SA WG3 and CT WG6 to provide feedback especially on potential impacts to architecture, security and UICC. Action: Provide feedback to the attached WID","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10140,"status":"noted","reservation_date":"2019-09-16 19:37:37","uploaded":"2019-09-16 21:37:53","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3, CT WG6, SA WG2","Cc":"CT WG1","lsoriginalls":"C4-193790","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908670.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1908717","title":"LS from SA WG3LI: N9HR Regulatory Obligations","source":"SA WG3LI","contact":"Gerald McQuaid","contact-id":25351,"tdoctype":"LS in","for":"Information","abstract":"SA WG3LI is defining details of lawful interception (LI) using N9HR. In addition, ETSI TC LI will also require the ability to maintain lawful disclosure (LD) capability. SA WG3LI solutions need access to unencrypted IMS signalling (e.g. signalling packets) in the VPLMN for all inbound roamers in order to meet LI obligations. However, SA WG3LI consider that the 4G solution of turning confidentiality protection off entirely for all inbound roaming user which, while meeting LI requirements, is undesirable in Release 16 from a privacy perspective. Therefore, for R16 SA WG3LI require a solution where IMS Signalling (e.g. signalling packets) and media can be accessed at a point in the VPLMN but otherwise ensures confidentiality at all other points between the UE and IMS Core. For example, a back to back encryption proxy in the UPF or other NF identified by SA WG3 could meet this requirement.","secretary_remarks":"Proposed to note. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10060,"status":"noted","reservation_date":"2019-09-16 19:37:38","uploaded":"2019-09-16 21:37:53","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"ETSI TC LI, TSG SA, SA WG2, TSG SA","lsoriginalls":"S3i190548","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908717.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1908718","title":"LS from SA WG4: Reply LS on Use Cases for eXtended Reality (XR) in 5G","source":"SA WG4","contact":"Thomas Stockhammer","contact-id":60397,"tdoctype":"LS in","for":"Information","abstract":"SA WG4 (SA WG4) would like to thank SA WG1 (SA WG1) for your LSs on 'Use Cases for eXtended Reality (XR) in 5G' in S1-183711 and S1-191569. {...} SA WG4 will continue the analysis of use cases, architectures, processing requirements as well as connectivity requirements in the context of the use cases 1, 2 and 3 of clause 5.2 and also the use case in clause 5.3 in TR 22.842. The two study items on FS_XR5G and FS_TyTraC are scheduled to be completed within the Rel-16 timeframe in order to initiate and support normative work in Rel-17 on Immersive Media over 5G as well as to support the development of 5G system, core and radio network features. SA WG4 remains interested in any studies and requirements for any of the use cases in particular when considering media related issues. We look forward to further dialog.","secretary_remarks":"Proposed to note. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10070,"status":"noted","reservation_date":"2019-09-16 19:37:38","uploaded":"2019-09-16 21:37:53","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1","Cc":"SA WG2","lsoriginalls":"S4-190972","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908718.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1908720","title":"LS from SA WG4: Reply LS to LS on TS 26.501 5G Media Streaming (5GMS); General description and architecture (S4h190837\/S2-1906842)","source":"SA WG4","contact":"Lucia D'Acunto","contact-id":66239,"tdoctype":"LS in","for":"Action","abstract":"SA WG4 thanks SA WG2 for reviewing TS 26.501 '5G Media Streaming (5GMS); General description and architecture' and for the corresponding LS where companies in SA WG2 asked for a number of clarifications. SA WG4 has amended the text of TS 26.501 to reflect the comments present in the LS from SA WG2 as follows: - Concerning the comment on 'Configuring slice from AF': the following text: 'The Media AF is responsible for configuring the network slice instance to ensure appropriate traffic routing, e.g. to a LADN that hosts the media processing compute instances' has been replaced with the text 'The Media AF is responsible to ensure appropriate traffic routing, e.g. request the routing of traffic to a local access to a Data Network (identified by a DNAI) that hosts the media processing compute instances.' - Concerning the comment on 'Directly notifying AF for RAN quality (as documented in clause 6.7 of TS 26.501) and metrics collection and reporting (as documented in clause 5.5 of TS 26.501).', clause 5.5 has been amended such that interactions between the AF and the RAN are done via interaction with the OAM, as recommended by SA WG2. Changes to clause 6.7 are still pending. - The call flow as defined within TS 26.501 \u00a75.5 has also been amended to include interaction between the AF and the RAN via the OAM. SA WG4 endeavours to put SA WG2 earlier in the loop for architectural aspects that may require changes to the 5G Core. Note: due to the amendments where the AF and the RAN interact via the OAM, SA WG5 is put in copy of this LS for information. Action: SA WG4 asks SA WG2 to take the above information into consideration.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10160,"status":"noted","reservation_date":"2019-09-16 19:37:38","uploaded":"2019-09-16 21:37:53","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"SA WG5","lsoriginalls":"S4-191003","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908720.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1908722","title":"LS from SA WG5: Reply LS from ETSI TC LI to SA WG5 on 5G Cell ID(s) in the SA WG5 billing system","source":"SA WG5","contact":"Maryse Gardella","contact-id":68914,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 thanks ETSI TC LI for their LS on 5G Cell ID(s) in the SA WG5 billing system in relationship with their standards related to Lawful Interception (LI) Retained Data (RD). SA WG5 can confirm the current SA WG5 charging specifications for 5G access specify the user location information as an information which can be available in the CHF CDRs generated for PDU sessions, with the granularity of the Cell Id when reported. In the context of dual connectivity, only one Cell Id is currently specified: i.e. the one of the Master Node. SA WG5 has discussed the recent development conducted between SA WG2 and RAN WG3 on PSCell ID and PCELL information. Based on the LS reply (S5-195060\/ S2-1908634) from SA WG2 to ETSI TC LI on Reporting all Cell IDs in 5G, SA WG5 would like to provide the following information to ETSI TC LI: The two Methods 1) and 2) by which the PSCell Id is reported to the MME, do not allow the PSCell Id to be available in the Billing system for EPC, since no MME CDR is specified for this context, and the PSCell Id is not propagated beyond the MME. In 5GS, with the same capabilities of reporting the PSCell Id to the AMF, the possibility to include the PSCell Id in addition to the PCELL in CHF CDRs for AMF could be investigated by SA WG5 during the ongoing Rel-16 'Charging AMF in 5G System Architecture Phase 1' work.","secretary_remarks":"Proposed to note. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10080,"status":"noted","reservation_date":"2019-09-16 19:37:39","uploaded":"2019-09-16 21:37:54","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ETSI TC LI","Cc":"SA WG3LI, SA WG2, RAN WG3","lsoriginalls":"S5-195570","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908722.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1908728","title":"LS from O-RAN Alliance: LS on O-RAN Alliance & 3GPP Coordination on O-RAN Alliance Outputs","source":"O-RAN Alliance","contact":"Brian K. Daly","contact-id":13316,"tdoctype":"LS in","for":"Information","abstract":"The O-RAN Alliance (https:\/\/www.o-ran.org\/) is committed to evolving radio access networks\u2014 making them more open and smarter than previous generations. O-RAN activities are guided by the following objectives [1]: - Leading the industry towards open, interoperable interfaces, RAN virtualization, and big data and AI enabled RAN intelligence. - Maximizing the use of common-off-the-shelf hardware and merchant silicon and minimizing proprietary hardware - Specifying APIs and interfaces, driving standards to adopt them as appropriate, and exploring open source where appropriate The O-RAN Reference Architecture [1] is designed to enable next generation RAN infrastructures. Empowered by principles of intelligence and openness, the O-RAN architecture is the foundation for building the virtualized RAN on open hardware, with embedded AI-powered radio control, that has been envisioned by operators around the globe. Future RANs will be built on a foundation of virtualized network elements, white-box hardware and standardized interfaces that fully embrace O-RAN's core principles of intelligence and openness. The architecture is based on well-defined, standardized interfaces to enable an open, interoperable supply chain ecosystem in full support of and complimentary to standards promoted by 3GPP and other industry standards organizations. The O-RAN Software Community (SC) [2] is a collaboration between the O-RAN Alliance and Linux Foundation with the mission to support the creation of software for the Radio Access Network (RAN). The RAN is the next challenge for the open source community. The O-RAN SC plans to leverage other LF network projects, while addressing the challenges in performance, scale, and 3GPP alignment. The O-RAN Software Community is focused on aligning with the O-RAN Alliance's open architecture and specifications to achieve a solution that can be utilized for industry deployment. As an open source community under the Linux Foundation, the O-RAN SC is sponsored by the O-RAN Alliance, and will enable the development of open source software enabling modular, open, intelligent, efficient, and agile disaggregated radio access networks. Within the O-RAN Alliance, there are currently 8 technical workgroups which have specific focus areas: - WG1: Use Cases and Overall Architecture Workgroup. It has overall responsibility for the O-RAN Architecture and Use Cases. Work Group 1 identifies tasks to be completed within the scope of the Architecture and Use Cases and assigns task group leads to drive these tasks to completion while working across other O-RAN work groups. - WG2: The Non-real-time RAN Intelligent Controller and A1 Interface Workgroup. The primary goal of Non-RT RIC is to support non-real-time intelligent radio resource management, higher layer procedure optimization, policy optimization in RAN, and providing AI\/ML models to near-RT RIC. WG3: The Near-real-time RIC and E2 Interface Workgroup. The focus of this workgroup is to define an architecture based on near-RT RIC, which enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over E2 interface. - WG4: The Open Fronthaul Interfaces Workgroup. The objective of this work is to deliver truly open fronthaul interfaces, in which multi-vendor DU-RRU interoperability can be realized. - WG5: The Open F1\/W1\/E1\/X2\/Xn Interface Workgroup. The objective of this work is to provide fully operable multi-vendor profile specifications (which shall be compliant with 3GPP specification) for F1\/W1\/E1\/X2\/Xn interfaces and in some cases will propose 3GPP specification enhancements. - WG6: The Cloudification and Orchestration Workgroup. The cloudification and orchestration workgroup seeks to drive the decoupling of RAN software from the underlying hardware platforms and to produce technology and reference designs that would allow commodity hardware platforms to be leveraged for all parts of a RAN deployment incl","secretary_remarks":"Proposed to note. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10090,"status":"noted","reservation_date":"2019-09-16 21:27:42","uploaded":"2019-09-16 21:37:54","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, TSG CT, TSG RAN, SA WG1, SA WG2, SA WG3, SA WG5, SA WG6, RAN WG1, RAN WG2, RAN WG3","Cc":"3GPP PCG","lsoriginalls":"ORAN_3GPP_Liaison_Statement","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908728.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1908756","title":"LS from TSG SA: Reply LS to 'O-RAN Alliance & 3GPP Coordination on O-RAN Alliance Outputs'","source":"TSG SA","contact":"Puneet Jain","contact-id":36283,"tdoctype":"LS in","for":"Information","abstract":"TSG SA thanks O-RAN Alliance for their Liaison Statement on 'O-RAN Alliance & 3GPP Coordination on O-RAN Alliance Outputs'. 3GPP has a well-defined process and successful track record in delivering global standards to meet market requirements for multivendor interoperation (see http:\/\/www.3gpp.org\/about-3gpp\/about-3gpp). TSG SA is of the opinion that there is synergy between the 3GPP and O-RAN Alliance activities. TSG SA welcomes co-ordination with O-RAN Alliance and would welcome further input in relevant areas via 3GPP individual members in accordance with 3GPP working procedures.","secretary_remarks":"Proposed to note. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10100,"status":"noted","reservation_date":"2019-09-24 13:53:49","uploaded":"2019-09-24 14:47:09","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG RAN","Cc":"TSG CT, TSG RAN, SA WG1, SA WG2, SA WG3, SA WG5, SA WG6, RAN WG1, RAN WG2, RAN WG3, 3GPP PCG","lsoriginalls":"SP-190947","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908756.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1908760","title":"LS from GSMA: LS Response to SA WG2 on EPC\/5GC Roaming","source":"GSMA","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"Introduction: GSMA NG 5GJA thanks SA WG2 for its Liaison Statement regarding a SA-only Network having to support its outbound roamers in a NSA Network. Specifically, SA WG2 asked GSMA 5GJA to provide feedback on whether there is requirement to support the following roaming scenarios:- A. Capability to support roaming from an EPC only HPLMN to a 5GC only VPLMN (the VPLMN using Option 2\/4 and\/or Option 5\/7); B. Capability to support roaming from a 5GC only HPLMN to an EPC only VPLMN. Discussion: GSMA NG 5GJA believes that the requirement to support roaming between EPC-only and 5GC-only networks or vice versa is primarily a commercial decision. To this end, 5GJA has sought advice on this topic from the GSMA Wholesale Agreements & Solutions (WAS) Working Group. The topic was discussed by WAS in conjunction with the GSMA Wholesale Agreements (WAGREE) and GSMA Wholesale Solutions (WSOLU) groups to analyse the commercial impacts of 5G Roaming. Specifically, the two theoretically possible EPC-5GC roaming scenarios that are not currently supported by 3GPP specifications were considered: - VPMN has EPC only and HPMN has 5GC only, - VPMN has 5GC only and HPMN has EPC only. NOTE: HPMN\/VPMN that has EPC may deploy either Option 1 (LTE Radio and EPC core) or Option 3 (Non-Standalone 5G New Radio using EPC Option). HPMN\/VPMN that has 5GC may have one of the deployment options 2, 4, 5 or 7). The feedback from WAS to NG 5GJA was that:- - for the roaming scenario where a VPMN has EPC only and HPMN has 5GC only, the HPMN can deploy already standardized functions and functionality to enable roaming with EPC only networks. - for the scenario where a VPMN has 5GC only and HPMN has EPC only, there is no commercial need for such interworking at this time. In addition, WAS will continue to assess the market as 5G networks launch and roaming is implemented to determine whether a need for an interworking solution arises, including any impact due to regulatory requirements. Action: GSMA NG 5GJA would like to ask SA WG2 to take the above into account.","secretary_remarks":"Proposed to note. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10110,"status":"noted","reservation_date":"2019-09-24 13:53:50","uploaded":"2019-09-24 14:47:09","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"5GJA09bis_107r1","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908760.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1908761","title":"LS from NGMN: NGMN 5G End-to-End Architecture Framework","source":"NGMN","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"Intention of the LS and required actions: NGMN is pleased to inform the recipient of this liaison statement for information sharing on the deliverable for Phase-2 (v3.0.8) of the NGMN 5G End-to-End Architecture Framework that includes requirements together with descriptions and concepts associated with new topics. The new topics include: ? Autonomic management and control ? Distributed Ledger Technology ? Minimization or avoidance of tunnelling ? Network automation This NGMN liaison is intended for information sharing in terms of the new topics that have been introduced in the attached document. Please take this into account in the 5G architecture considerations.","secretary_remarks":"Proposed to note. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10120,"status":"noted","reservation_date":"2019-09-24 13:53:50","uploaded":"2019-09-24 14:47:09","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, SA WG2, SA WG5, SA WG6, TSG RAN, ETSI ISG PDL, ETSI ISG ZSM, ITU-T SG13, TM Forum","Cc":"","lsoriginalls":"190916 Liaison_NGMN_E2E Arch FW","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1908761.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1909697","title":"Recommendation on TR Structure","source":"MediaTek Inc.","contact":"Guillaume Sebire","contact-id":45073,"tdoctype":"discussion","for":"Agreement","abstract":"TR structure","secretary_remarks":"Proposal 2 was endorsed. This was then noted.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10170,"status":"noted","reservation_date":"2019-10-04 07:31:47","uploaded":"2019-10-04 08:08:07","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1909697.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1909962","title":"LS from CT WG4: LS on Support of Network Address Translation in the User Plane function","source":"CT WG4","contact":"yong yang","contact-id":59744,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 has discussed the contribution C4-194233 which proposes one protocol solution over N4\/Sxb to support Network Address Translation in the UP function. Several companies expressed their support to introduce support of NAT in the user plane function. This is a legacy feature used in many operators' network to support various use cases. However, a few companies believe SA WG2 should specify first stage 2 requirements for the control over N4\/Sxb of NAT functionalities in the user plane function, if any, before CT WG4 can specify any protocol solution. Action: CT WG4 kindly requests SA WG2 to answer whether specific requirements are expected for the control of NAT in the user plane function over N4\/Sxb and, if so, to consider specifying the relevant stage 2 requirements.","secretary_remarks":"This LS was postponed.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10130,"status":"postponed","reservation_date":"2019-10-11 13:25:15","uploaded":"2019-10-11 13:25:45","revisionof":"","revisedto":"S2-1910872","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG3","lsoriginalls":"C4-194528","lsreply":"S2-1910981, S2-1911744","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1909962.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-1909969","title":"LS from CT WG6: Reply to LS on 5GS Enhanced support of OTA mechanism for UICC configuration parameter update","source":"CT WG6","contact":"Ly thanh Phan","contact-id":43228,"tdoctype":"LS in","for":"Action","abstract":"CT WG6 thanks CT WG4 for their LS on 5GS Enhanced support of OTA mechanism for UICC configuration parameter update and the attached work item description. CT WG6 has discussed the provided WID on '5GS Enhanced support of OTA mechanism for UICC configuration parameter update' and would like to provide the following feedback to CT WG4: - Until now, for security reasons only the OTA USIM management platform is allowed to provide updates to the USIM. Due to the key role performed by the OTA Platform in the security architecture of the MNO, it is important that considerations with regard to the security are taken into account in the design of the API so only legitimate and authorized network functions get access to the OTAF through the API. - It is CT WG6 understanding that the work item is covering USIM parameter updates only via NAS transport protocol. - Our understanding is that in the future any network functions would be able to access the API to the OTAF and therefore CT WG6 would like to be informed of new parameter updates as potential technical aspects would need be assessed and evaluated for any impact on the secure packet. - In order to reduce the impact on existing OTA Platforms and USIMs, the secure packet defined in 3GPP TS 31.115 shall be used with no (or minor) changes to avoid backward compatibility issues. Our understanding is that the secure packet structure would not be affected.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10150,"status":"noted","reservation_date":"2019-10-11 14:33:54","uploaded":"2019-10-11 14:34:18","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4, SA WG3, SA WG2","Cc":"CT WG1","lsoriginalls":"C6-190351","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_135_Split\/Docs\/S2-1909969.zip","group":"S2","meeting":"S2-135","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]