[{"name":"S2-2200008","title":"LS from CT WG3: LS on PDU Session ID assignment for the Interworking scenario","source":"CT WG3","contact":"Xiaoyun Zhou","contact-id":77294,"tdoctype":"LS in","for":"Action","abstract":"CT WG3 is studying an issue of PDU Session ID assignment in the following scenario: 1) UE firstly establishes a PDN connection via MME and MME assigns a Default EPS bearer ID1 to the PDN connection. The SMF+PGW-C will calculate a PDU Session ID1 with the value of 64 + Default EPS bearer ID1 according to Table 5.4.2-1 of TS 29.571, e.g. if Default EPS bearer ID is 5, then the calculated PDU Session ID1 is 69. And then the SMF+PGW-C sends the PDU Session ID1 to the PCF as a parameter to identify the PDU session for the SUPI, DNN and S-NSSAI. 2) UE handovers to the ePDG and the ePDG assigns a new Default EPS bearer ID2. The Default EPS bearer ID2 may be the same as the Default EPS bearer ID1 or different from the Default EPS bearer ID1. CT WG3 understands the SMF+PGW-C doesn't calculate a new PDU session ID, since there is no explicit requirement to do so. 3) UE may establish an additional PDU connection to the same DNN and S-NSSAI via MME while the UE keeps the PDN connection via ePDG. As the MME may assign the same value of Default EPS bearer ID3 as the Default EPS bearer ID1, the SMF+PGW-C would allocate the same PDU session ID3 as the PDU session ID1 (i.e. the Default EPS bearer ID3 is 5, and the PDU Session ID3 will be 69). When the SMF+PGW-C sends the PDU Session ID3 to the PCF, PCF can't identify this is a different PDU Session than PDU Session ID1 and may reject the request from the SMF+PGW-C incorrectly. CT WG3 would like to ask the following questions to SA WG2: Question 1: Is it correct understanding that SMF+PGW-C doesn't calculate a new PDU session ID at UE handover from MME to ePDG, and vice-versa? Question 2: If answer to Q1 is yes, how to resolve the issue raised in bullet 3)? Question 3: If answer to Q1 is no, can the SMF+PGW-C update the PDU session ID to the PCF with new calculated value?. Action: CT WG3 kindly asks SA WG2 to answer the questions above and amend the SA WG2 specifications accordingly, where appropriate.","secretary_remarks":"Revision of Postponed S2-2108267 from S2#148E. Responses drafted in S2-2200113 and S2-2200311. Final response in S2-2201271","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10030,"status":"replied to","reservation_date":"2022-01-10 13:42:19","uploaded":"2022-01-10 13:44:26","revisionof":"S2-2108267","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG4","lsoriginalls":"C3-214527","lsreply":"S2-2201271","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200008.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200023","title":"LS from RAN WG3: Reply to Reply LS On ACL support for Indirect Data Forwarding","source":"RAN WG3","contact":"Angelo Centonza","contact-id":45800,"tdoctype":"LS in","for":"Action","abstract":"RAN WG3 thanks SA WG2 for the reply LS on ACL support Indirect Data Forwarding. SA WG2 asked RAN WG3 to provide their view on whether the source address for a normal Iu-U\/N3 tunnel (for example, during Service request procedure from CM_IDLE to CM_CONNECTED) needs to be provided to RAN for ACL support or it can be made aware to RAN by other means. RAN WG3 discussed this use case and agreed that the source address for a normal Iu-U\/N3 tunnel may be configured at the RAN. Hence this use case is considered of lower priority and a solution for it is not needed. RAN WG3 would like to point out that the case of indirect data forwarding is different because the UP GW responsible for data forwarding may be different from the UP GW serving the Iu-U\/N3 tunnel. RAN WG3 would like to ask SA WG2 to confirm whether this understanding is correct and whether the UP GW selection for data forwarding is subject to any limitations. Action: RAN WG3 kindly asks SA WG2 to take the above into account.","secretary_remarks":"Revision of Postponed S2-2109007 from S2#148E. Response drafted in S2-2200340. Final response in S2-2201272","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10070,"status":"replied to","reservation_date":"2022-01-10 13:42:21","uploaded":"2022-01-10 13:44:26","revisionof":"S2-2109007","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG1, CT WG4","lsoriginalls":"R3-216140","lsreply":"S2-2201272","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200023.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200035","title":"LS from GSMA ESTF: LS informing partner groups of ESTF creation","source":"GSMA ESTF","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"Introduction: Several technological changes have been challenging the resilience of the emergency communications, during the past years. It is becoming more and more threatening taking into account the 2G\/3G sunset and the regional and local obligations that emergency services are subject to. In order to address Emergency services related issues in a coordinated manner within GSMA Networks Group, GSMA NG has created the Emergency services Task force (ESTF). The Terms of Reference of ESTF are as follows: The objective of ESTF is primarily to create a whitepaper that captures the key issues associated with the provision of Emergency Services. The topics addressed within the whitepaper will include, but not be limited to: - Implementation best practice - Emergency Services architectures - Resilience in the provision of Emergency Services - Future Emergency Services covering all-IP end-to-end emergency services, Next Generation 112 and future regulatory initiatives The purpose of this LS is to inform the appropriate partner groups and SDO of the creation of the ESTF and request that future emergency services related matters be sent to NG ESTF. ACTION to Partner Organisations: GSMA ESTF requests the partner groups to take this information into account.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10100,"status":"noted","reservation_date":"2022-01-10 14:20:56","uploaded":"2022-01-10 16:05:25","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ETSI EMTEL, SA WG1, SA WG2","Cc":"","lsoriginalls":"ESTF 02_102","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200035.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200036","title":"LS from BBF: Alignment concerning 5G RG requirements and its remote management","source":"Broadband Forum","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"Dear colleagues, Thank you for your answer to our previous liaison. In that answer, you wrote: 'The requirements related to eRG include security, privacy, and intra-CPN connectivity. These requirements are potentially related to specifications of BBF, particularly when the eRG goes beyond the role of 5G-RG acting as a 3GPP UE. Additionally, FS_Resident specifies requirements for the provisioning of eRG, these management aspects are potentially related to TR-069, TR-369, TR-124i6 specified by the Broadband User Services Work Area, and TR-181 by the Broadband Home Work Area.' That answer confirms our concern about a potential overlap in requirements leading to a confusion in the industry as well as a potential break of the overall interworking of the solution. For clarity in the industry, common practice is to have one SDO responsible for requirements concerning a given device or function. This has served us well in our work in cooperation with 3GPP to date. The BBF is the responsible SDO for 5G-BRG specifications, while referring to 3GPP standards as appropriate. Therefore the BBF requests that 3GPP liaise any requirements for an 5G-BRG to BBF. This would allow one repository for 5G-BRG requirements, namely TR-124. It would also allow a thorough review of the proposed requirements in order to make sure that the WWC solution is working smoothly with existing customer premise networks. With the knowledge that it is SA WG2 group that would write down the architectural requirements with the inputs from SA WG1, we are sending this request to the SA WG2 group of 3GPP. We look forward to continuing our fruitful relationship. Thanks, Lincoln Lavoie Broadband Forum Technical Committee Chair","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10110,"status":"noted","reservation_date":"2022-01-10 14:20:56","uploaded":"2022-01-10 16:05:25","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2","Cc":"","lsoriginalls":"LIAISE-483","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200036.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200037","title":"LS from IEEE 802.1 Working Group: Liaison response to work items related to deterministic communication in ITU-T SG13","source":"IEEE 802.1 Working Group","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"Dear Colleagues, The IEEE 802.1 Working Group would like to thank ITU-T Study Group 13 for the information provided in liaison statement SG13-LS217 about work items related to deterministic communication in ITU-T SG13. From an organizational perspective, there are three coordinated standardization initiatives for deterministic communication: - IEEE: Time-Sensitive Networking (TSN) - IETF: Deterministic Networking (DetNet) - 3GPP: SA Working Group 2 As part of IEEE 802, the IEEE 802.1 TSN Task Group (TSN TG) is focused on TSN scoped to Local\/Metropolitan Area Networks. For application areas that require deterministic communication in a Local\/Metropolitan Area Network, a TSN profile standard is standardized. Examples of ongoing TSN profile projects include: - IEC\/IEEE 60802: TSN Profile for Industrial Automation - IEEE P802.1DG: TSN Profile for Automotive In-Vehicle Ethernet Communications - IEEE P802.1DP \/ SAE AS 6675: TSN for Aerospace Onboard Ethernet Communications With each application profile, the TSN TG coordinates with the leading standardization organization for that application (e.g., IEC for industrial automation, SAE International for aerospace). This helps to meet the needs of that application profile in a Local\/Metropolitan Area Network. Many of these applications have needs beyond a Local\/Metropolitan Area Network, including the Internet and 5G\/6G networks. The TSN TG uses its coordination with IETF and 3GPP to help meet those needs as well. The overall goal is to provide coordination among standardization initiatives for deterministic communication. The work items related to deterministic communication in ITU-T SG13 appear to be proposed independently of this coordination. The risk of such independence is that ITU-T SG13 could miss out on much of the coordination with the applications that ITU-T SG13 work items aim to target (such as smart industry). The IEEE 802.1 Working Group also looks forward to continued collaboration with ITU-T SG13. In that spirit, please find in Annex our technical considerations related to the documents attached to your liaison statement. Additionally, in the context of deterministic communication, we invite ITU-T SG13 to work as an integrated part of the coordination described above. We are happy to develop our TSN technology further to address needs and requirements as they arise. We welcome you and any interested parties to join, contribute, and work together towards addressing market needs. Note that the IEEE 802 work is open and contribution driven. Participation is on an individual basis and technical discussion can be conducted based on individual contributions. The TSN Task Group holds regular electronic meetings: details are available at https:\/\/1.ieee802.org\/wg-calendar. Respectfully submitted, Glenn Parsons Chair, IEEE 802.1 Working Group","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10120,"status":"noted","reservation_date":"2022-01-10 14:20:56","uploaded":"2022-01-10 16:05:25","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ITU-T SG13","Cc":"ITU-T SG12, IETF DetNet, SA WG2, IEC TC65, IEC SC65C, SAE International","lsoriginalls":"liaison-response-itu-t-SG13-LS217-determcommunics-","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200037.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200053","title":"LS from CT WG4: Reply LS on ACL support for Indirect Data Forwarding","source":"CT WG4","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 thanks RAN WG3 for their LS on ACL support for Indirect Data Forwarding. CT WG4 would like to point out that the solution described in the LS to support ACL functionality for indirect data forwarding would require new functionalities in EPC and 5GC (MME, SGW-C, SGW-U, SMF, UPF) and protocol extensions to several CN interfaces (S11, Sxa, N4, S1AP and NGAP at least), e.g. to support retrieving the source IP address of the forwarding SGW-U or UPF and signal it to the target RAN. CT WG4 would not expect new functionalities to be defined in Rel-16 (frozen). Action: CT WG4 kindly asks RAN WG3 and SA WG2 groups to take note of the above feedback.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10130,"status":"noted","reservation_date":"2022-01-10 14:20:57","uploaded":"2022-01-10 16:05:24","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, SA WG2","Cc":"","lsoriginalls":"C4-216377","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200053.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200054","title":"LS from CT WG4: Reply LS on Support of Asynchronous Type Communication in N1N2MessageTransfer","source":"CT WG4","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 would like to thank SA WG2 for their reply LS on Support of Asynchronous Type Communication in N1N2MessageTransfer and to provide the following questions on SA WG2 responses. - SA WG2 Answer 1: The Asynchronous Type Communication could be applied for those procedures\/messages where no immediate response from UE is expected and the intended functionality shall not be impacted by the delay of the message delivery. For the procedures\/messages requiring immediate response, ATC is not applied. CT WG4 Question: Which procedures\/messages do not require an immediate response from the UE? Practically, in which use case is it possible to apply Asynchronous Type Communication? - SA WG2 Answer 4: Please also see Answer 1. In principle, ATC could be allowed also on MT Data assuming delivering mtData does not require immediate response from UE. CT WG4 Question: How can the SMF be aware of whether the mtData requires an immediate response or not?. Action: CT WG4 kindly requests SA WG2 to provide answers to the above questions.","secretary_remarks":"Responses drafted in S2-2200282 and S2-2201011. CC#2: This LS was postponed.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10140,"status":"postponed","reservation_date":"2022-01-10 14:20:57","uploaded":"2022-01-10 16:05:25","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG1","lsoriginalls":"C4-216381","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200054.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200055","title":"LS from CT WG4: Reply LS On Source IP address clarifications","source":"CT WG4","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"CT WG4 thanks RAN WG3 for the LS On Source IP address clarifications. As specified in 3GPP TS 29.281, a GTP-U tunnel is considered as a unidirectional tunnel where the destination IP address and 'the TEID in the GTP-U header is used to de-multiplex traffic incoming from remote tunnel endpoints so that it is delivered to the User plane entities in a way that allows multiplexing of different users, different packet protocols and different QoS levels'. There is no specific requirement specified for a sending GTP-U entity regarding the source IP address(es) used when sending GTP-U packets towards a destination GTP-U F-TEID. A receiving GTP-U entity should be prepared to receive GTP-U packets from different source IP addresses. Clause 4.3.0 in 3GPP TS 29.281 documents a few example scenarios where a GTP-U endpoint may receive GTP-U packets from multiple remote GTP-U endpoints; this list is not meant to be exhaustive. Therefore, CT WG4 would like to provide the following response to the question: RAN WG3 would like to ask CT WG4 whether DL forwarding traffic contained within a GTP-U DL forwarding tunnel can be transmitted by more than one source IP address. As per the above GTP-U principles, DL forwarding traffic contained within a GTP-U DL forwarding tunnel could be transmitted by more than one source IP address. CT WG4 however would like to ask RAN WG3 to clarify what are the intended use cases for such a scenario.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10170,"status":"noted","reservation_date":"2022-01-10 14:20:57","uploaded":"2022-01-10 16:05:25","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"CT WG1, SA WG2","lsoriginalls":"C4-216388","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200055.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200063","title":"LS from SA WG1: LS on Emergency Communication Improvement","source":"SA WG1","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"SA WG1 thanks GSMA NRG for their LS on Emergency Communication improvement. Some companies expressed the view that for the purpose given in the roadmap 'Emergency communications - improving access through the single European emergency number '112' ' a fully standardized solution is already available today. Back in Rel.11 SA WG1 has studied Non Voice Emergency Services (NOVES) which resulted in the specification of IMS Multimedia Emergency Sessions (IMS MES; cf. TS 22.101, clause 10.4.2). Therefore, SA WG1 could not agree on starting work for emergency SMS, which would need further investigation on existing regulatory requirements and thorough analysis of gaps and impacts to existing SA WG1 service level requirements.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10180,"status":"noted","reservation_date":"2022-01-10 14:20:57","uploaded":"2022-01-11 07:09:44","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA NRG","Cc":"SA WG2, ETSI TC EMTEL","lsoriginalls":"S1-214240","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200063.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200074","title":"LS from SA WG5: LS on the mapping between service types and slice at application","source":"SA WG5","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 thanks RAN WG3 for the LS R3-212904 on the mapping between service types and slice at application. RAN WG3 is discussing how to support per-slice QoE i.e. QoE measurement collection and reporting separately for a given slice. However, RAN WG3 is not sure whether the application is aware of the mapping between service types and slice. RAN WG3 asks SA WG5 to provide feedback if there is any relevant information. For SA WG5 to support per-slice QoE TS 28.404 needs to be updated with a requirement to have QoE measurement collection per-slice.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10200,"status":"noted","reservation_date":"2022-01-10 14:20:57","uploaded":"2022-01-11 07:09:44","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"CT WG1, SA WG2, RAN WG2, SA WG4","lsoriginalls":"S5-216414","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200074.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200076","title":"LS from SA WG5: LS Reply on model deployment and update from OAM to NG-RAN","source":"SA WG5","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 thanks RAN WG3 for the LS on model deployment and update from OAM to NG-RAN. SA WG5 understands the RAN WG3 requirements for OAM to deploy and update the AI\/ML model to NG-RAN to support RAN intelligence. SA WG5 would like to inform RAN WG3 about the following relevant work in SA WG5: - The ML model training is being defined as part of on-going Rel-17 work; - SA WG5 will also study other AI\/ML management capabilities (including model validation, testing, deployment, etc) for supporting the AI-enabled functions (including RAN intelligence) in Rel-18. In the study, SA WG5 plans to make it a first priority to address the AI\/ML model management capabilities to support AI\/ML in NG-RAN for the scenario where the AI\/ML model training is in the OAM and inference is in NG-RAN. The corresponding Rel-18 SID has been agreed at SA5#140e.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"noted","reservation_date":"2022-01-10 14:20:57","uploaded":"2022-01-11 07:09:44","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"SA WG2","lsoriginalls":"S5-216423","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200076.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200077","title":"LS from TSG SA: LS on Energy Efficiency as guiding principle for new solutions","source":"TSG SA","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"3GPP has addressed the topic of EE (Energy Efficiency) for several 3GPP releases. For instance, TSG SA has undertaken studies at TSG SA level and in some of its WGs. Similarly, TSG RAN has addressed the topic quite extensively in various studies and is also soon engaging in additional work on the subject in Rel-18. The EE-specific efforts so far undertaken e.g., in SA WG5 have aimed mostly at improving the energy efficiency by impacting the operations of the system. As we now are starting to specify the 5G-Advanced features, TSG SA kindly requests the recipient WGs and TSGs to consider EE even more as a guiding principle when developing new solutions and evolving the 3GPP systems specification, in addition to the other established principles of 3GPP system design. TSG SA clarifies that in addition to EE, other system level criteria shall continue to be met (i.e. the energy efficiency aspects of a solution defined in 3GPP is not to be interpreted to take priority or to be alternative to security, privacy, complexity etc. and to meeting the requirements and performance targets of the specific feature(s) the solution addresses). This guiding principle complements the continued importance of work specifically dedicated to Energy efficiency (e.g., work aiming at improving the energy efficiency by impacting the operations of the system, as for instance work in [1],[2],[3],[4])..","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10220,"status":"noted","reservation_date":"2022-01-10 14:20:57","uploaded":"2022-01-11 07:09:44","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG RAN, TSG CT, SA WG1, SA WG2, SA WG3, SA WG4, SA WG5, SA WG6, RAN WG1, RAN WG2, RAN WG3, RAN WG4, RAN WG5, CT WG1, CT WG3, CT WG4, CT WG6","Cc":"","lsoriginalls":"SP-211621","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200077.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200112","title":"SMF+PGW-C assigned PDU Session ID","source":"Nokia, Nokia Shanghai Bell, ZTE, Cisco, Qualcomm","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: This paper implements Option-2 as follows: If the SMF+PGW-c is to allocate a PDU Session Id, - the SMF+PGW-C may query the UDM for any PDU Session ID(s) that are already assigned to the UE by the same or different SMF+PGW-C by invoking Nudm_UECM_Get service operation. - When the SMF+PGW-C establishes the PDN connection successfully, the SMF+PGW-C may perform UDM registration using the Nudm_UECM_Registration service operation.","secretary_remarks":"Revision of (Noted) S2-2108386 from S2#148E. Merged into S2-2201675","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10230,"status":"merged","reservation_date":"2022-01-24 14:57:18","uploaded":"2022-01-28 18:29:49","revisionof":"S2-2108386","revisedto":"","release":"Rel-17","crspec":"23.502","crspecversion":"17.3.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3135.0,"crrevision":2.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200112.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200113","title":"[DRAFT] LS on PDU Session ID assignment for the Interworking scenario","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS on PDU Session ID assignment for the Interworking scenario","secretary_remarks":"Response to S2-2200008. r00 agreed. Revised to S2-2201271, merging S2-2200311","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10040,"status":"revised","reservation_date":"2022-01-24 14:57:20","uploaded":"2022-01-28 18:29:49","revisionof":"","revisedto":"S2-2201271","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_Ph1-CT"},{"winame":" TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"CT WG4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200113.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200282","title":"[DRAFT] Reply LS on Support of Asynchronous Type Communication in N1N2MessageTransfer","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"To reply the LS on ATC use cases","secretary_remarks":"Response to S2-2200054. CC#2: This LS was noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10150,"status":"noted","reservation_date":"2022-01-26 13:33:23","uploaded":"2022-01-28 12:23:29","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"SBIProtoc17"},{"winame":" TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"CT WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200282.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200309","title":"Documentation handling for description of NF profile","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add a note in clause 6.2.6.2 (NF profile) to provide linkage to the feature specific specifications.","secretary_remarks":"Merged into S2-2201273","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10240,"status":"merged","reservation_date":"2022-01-26 19:42:15","uploaded":"2022-01-28 20:48:14","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"17.3.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3488.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200309.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200310","title":"SMF+PGW-C assigned PDU Session ID","source":"Ericsson, [Cisco, Nokia, Nokia Shanghai Bell, ZTE]","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: When the SMF+PGW-C is expected to allocate a PDU Session Id, if handover between EPS and EPC\/ePDG is required, based on operator's configuration, - the SMF+PGW-C may query the UDM for any PDU Session ID(s) that are already assigned by the same or different SMF+PGW-C by invoking Nudm_UECM_Get service operation. - When the SMF+PGW-C establishes the PDN connection successfully, the SMF+PGW-C may perform UDM registration using the Nudm_UECM_Registration service operation. Add a note clarifying the scenario that requires UDM interaction. Add a new sub-clause for PDN connection release, which is generic to any PDN connection with UDM registration.","secretary_remarks":"Revision of (Noted) S2-2108386 from S2#148E. CC#2: r10 agreed. Revised, merging S2-2200112, to S2-2201675.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10250,"status":"revised","reservation_date":"2022-01-26 19:42:17","uploaded":"2022-01-28 20:48:14","revisionof":"S2-2108386","revisedto":"S2-2201675","release":"Rel-17","crspec":"23.502","crspecversion":"17.3.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3135.0,"crrevision":3.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200310.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200311","title":"[DRAFT] Rely to LS on PDU Session ID assignment for the Interworking scenario","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"This paper answer CT WG3 questions on handling of SMF+PGW-C assigned PDU Session ID at EPS-EPC\/ePDG handover","secretary_remarks":"Response to S2-2200008. Merged into S2-2201271","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10060,"status":"merged","reservation_date":"2022-01-26 19:42:18","uploaded":"2022-01-28 20:48:14","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1-CT"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"CT WG4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200311.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200340","title":"[DRAFT] Reply LS on ACLIndirectForwarding","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS to RAN WG3 on the ACL support for Indirect forwarding tunnel.","secretary_remarks":"Response to S2-2200023. r06 agreed. Revised to S2-2201272.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10080,"status":"revised","reservation_date":"2022-01-26 21:22:35","uploaded":"2022-01-28 20:48:14","revisionof":"","revisedto":"S2-2201272","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"TEI16"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"CT WG1, CT WG4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200340.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200411","title":"LS from GSMA NRG: LS reply from NRG to 3GPP on IMS emergency communication improvement - SMS","source":"GSMA NRG","contact":"Marc BALON","contact-id":49009,"tdoctype":"LS in","for":"Action","abstract":"Background :GSMA NRG thanks SA WG1 for the reply related to the improvement of emergency services and acknowledges that IMS evolutions are already defined to provide real time text and video, using IMS Multimedia Emergency Sessions (IMS MES; cf. TS 22.101, clause 10.4.2). GSMA NRG is currently working on a white paper on emergency services. One of the major challenges is to enrich and improve the existing emergency service portfolio using IMS and enable the migration and operation of those new IMS emergency services (end-to-end). Today issue: Today, SMS is a widely used channel for access to emergency services and for the provision of caller location information (see annex 1). SMS is easy to use at device side and easy to integrate with PSAP. But SMS cannot be adequately used for emergency service while roaming, due to home routing. Recital 285 of the European Electronic Communications Code (EECC) (adopted in 2018 and must be transposed in the Member States by December 2020) states that 'end-users should be able to access emergency services through emergency communications free of charge and without having to use any means of payment, from any device which enables number-based interpersonal communications services, including when using roaming services in a Member State. Emergency communications are a means of communication that includes not only voice communications services, but also SMS, messaging, video or other types of communications, for example real time text, total conversation and relay services' - (emphasis added). Furthermore, EECC Article 109(8) requires the EC, after consultation with BEREC, to adopt delegated act(s) to ensure compatibility, interoperability, quality, reliability and continuity of emergency communications in the EU. The study is in progress to inform the delegated act(s). It is being carried out by e-Mercury and it addresses inter-alia access to emergency services for roaming end-users in respect of the establishment and provision of caller location information, equivalent access to emergency services for end-users with disabilities and routing of emergency communications to the most appropriate PSAP in order to determine any technical or regulatory gaps that need to be addressed to provide seamless and free-of-charge access for roaming end-users. In order to meet regulatory obligations going forward, the current design of SMS needs to be reviewed. GSMA Requirements: Based on European Commission needs, GSMA proposes to improve SMS service: - SMS design shall enable SMS for emergency service in case of roaming - SMS shall be supported for emergency numbers such as 112 or 911 (other local emergency numbers could be considered as an option) - SMS for emergency service shall use SMSoIMS based on LBO data connections in case of roaming instead of Home Routing (see annex 2). Action: GSMA NG\/NRG kindly requests 3GPP to consider the above improvements and to provide feedback to GSMA on how to support those evolutions on 3GPP specifications.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10190,"status":"noted","reservation_date":"2022-01-27 15:09:57","uploaded":"2022-01-27 16:01:33","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2","Cc":"CT WG1, ETSI EMTEL","lsoriginalls":"NRG_012_204","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200411.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200422","title":"Reply LS On Source IP address clarifications","source":"RAN WG3","contact":"Angelo Centonza","contact-id":45800,"tdoctype":"LS in","for":"Action","abstract":"RAN WG3 thanks CT WG4 for their reply LS On Source IP address clarifications. CT WG4 has confirmed that DL forwarding traffic contained within a GTP-U DL forwarding tunnel could be transmitted by more than one source IP address As a consequence, RAN WG3 has agreed to the attached CRs, enabling an ACL solution where the source IP address used for direct data forwarding traffic is signalled from the node sending forwarded data to the target node on a per QoS flow basis. The use cases this solution is addressing concern the use of dedicated IP domains\/addresses per QoS class, which is a possible option especially in cloud based RAN deployments. Action: RAN WG3 kindly asks CT WG4 and SA WG2 to take the above into account and to provide comments in case the use cases mentioned may generate issues in light of current specifications.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10270,"status":"noted","reservation_date":"2022-01-27 15:09:57","uploaded":"2022-01-27 16:01:33","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, CT WG4","Cc":"CT WG1","lsoriginalls":"R3-221474","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200422.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200423","title":"LS from RAN WG3: LS on NAS PDU delivery during PDU Session modification procedure","source":"RAN WG3","contact":"Aijuan Liu","contact-id":43714,"tdoctype":"LS in","for":"Action","abstract":"RAN WG3 discussed the PDU session NAS PDU delivery in NG-RAN node during PDU session modification procedure and two options are on the table as below: - Option 1: NG-RAN node always sends the PDU session NAS-PDU to UE no matter the PDU Session Modification succeeds or not for the concerned PDU session; - Option 2: NG-RAN node sends the PDU session NAS-PDU to UE only when PDU Session Modification for the concerned PDU session succeeds. Views are split in RAN WG3 on which alternative should be adopted. Meanwhile, RAN WG3 notice the discussion may be related to the procedure texts in section 4.3.3.2 of TS 23.502, and have two different understandings: If the PDU Session modification is UE triggered and the N2 SM information indicates modification failure, the SMF shall reject the PDU session modification by including a N1 SM container with a PDU Session Modification Reject message (see clause 8.3.3 of TS 24.501 [25]) in the Nsmf_PDUSession_UpdateSMContext Response in step 7b. Step 8 is skipped in this case. - Understanding 1: The SMF would send PDU Session Modification Reject message to UE if the SMF found that the UE requested modification on the PDU session is rejected by NG-RAN node no matter other modifications e.g. TNL address update included in the same N2 message succeeds or not. - Understanding 2: The SMF would send PDU session Modification Reject message to UE only when all of the modification request included in the N2 message failed, i.e. upon receiving the PDU Session Resource Modify Unsuccessful Transfer IE in the PDU SESSION RESOURCE MODIFY RESPONSE message. RAN WG3 would like to know which understanding is correct. Action: RAN WG3 respectfully asks SA WG2 to provide feedbacks on above question.","secretary_remarks":"Response drafted in S2-2201026. CC#2: Final response in S2-2201676","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10280,"status":"replied to","reservation_date":"2022-01-27 15:09:57","uploaded":"2022-01-27 16:01:33","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"R3-221475","lsreply":"S2-2201676","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200423.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200442","title":"Reply LS on mandatory SSC modes supported by UE","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"This paper proposes a reply to the LS received from CT WG6","secretary_remarks":"Response to S2-2108269 (already replied to at S2#148E in S2-2109345). r00 Revised to S2-2201274.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10310,"status":"revised","reservation_date":"2022-01-27 16:12:56","uploaded":"2022-01-28 20:54:50","revisionof":"","revisedto":"S2-2201274","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_Ph1_UEConTest"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG6","Cc":"CT WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200442.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200443","title":"SSC mode support by the UEs","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Specifies that SSC mode 1 is mandatory while SSC modes 2 and 3 are optional to support in the UE. Further states that the PDU Session release with reconnect can be used independent of SSC mode.","secretary_remarks":"CC#2. r03 agreed. Revised to S2-2201677.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"revised","reservation_date":"2022-01-27 16:12:56","uploaded":"2022-01-28 20:54:50","revisionof":"","revisedto":"S2-2201677","release":"Rel-15","crspec":"23.501","crspecversion":"15.12.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI15"}],"crnumber":3503.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200443.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200444","title":"SSC mode support by the UEs","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-16 mirror CR: Summary of change: Specifies that SSC mode 1 is mandatory while SSC modes 2 and 3 are optional to support in the UE. Further states that the PDU Session release with reconnect can be used independent of SSC mode.","secretary_remarks":"r00 Revised to S2-2201275.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10350,"status":"revised","reservation_date":"2022-01-27 16:12:58","uploaded":"2022-01-28 20:54:50","revisionof":"","revisedto":"S2-2201275","release":"Rel-16","crspec":"23.501","crspecversion":"16.11.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI16"}],"crnumber":3504.0,"crrevision":"","crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200444.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200445","title":"SSC mode support by the UEs","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-17 mirror CR: Summary of change: Specifies that SSC mode 1 is mandatory while SSC modes 2 and 3 are optional to support in the UE. Further states that the PDU Session release with reconnect can be used independent of SSC mode.","secretary_remarks":"r00 Revised to S2-2201276.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10370,"status":"revised","reservation_date":"2022-01-27 16:12:59","uploaded":"2022-01-28 20:54:50","revisionof":"","revisedto":"S2-2201276","release":"Rel-17","crspec":"23.501","crspecversion":"17.3.0","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":3505.0,"crrevision":"","crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200445.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200446","title":"Handling of SSC modes being mandatory or optional .","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"discussion","for":"Agreement","abstract":"This contribution discusses whether SSC modes are optional or mandatory in the UE, as brought up in the LS from CT WG6.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10390,"status":"noted","reservation_date":"2022-01-27 16:13:00","uploaded":"2022-01-28 20:54:50","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200446.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200510","title":"Removal of ATC","source":"Ericsson, Nokia, Nokia Shanghai Bell","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Remove the support of asynchronous type communication in clause 5.23.","secretary_remarks":"Revision of (Noted) S2-2103896 from S2#145E. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10400,"status":"noted","reservation_date":"2022-01-27 20:20:00","uploaded":"2022-01-28 20:55:44","revisionof":"S2-2103896","revisedto":"","release":"Rel-15","crspec":"23.501","crspecversion":"15.12.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2866.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200510.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200511","title":"Removal of ATC","source":"Ericsson, Nokia, Nokia Shanghai Bell","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-16 mirror CR: Summary of change: Remove the support of Asynchronous type communication in clause 5.23.","secretary_remarks":"Revision of (Noted) S2-2103897 from S2#145E. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10410,"status":"noted","reservation_date":"2022-01-27 20:20:02","uploaded":"2022-01-28 20:55:44","revisionof":"S2-2103897","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.11.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2867.0,"crrevision":1.0,"crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200511.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200512","title":"Removal of ATC","source":"Ericsson, Nokia, Nokia Shanghai Bell","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-17 mirror CR: Summary of change: Remove the support of Asynchronous type communication in clause 5.23.","secretary_remarks":"Revision of (Noted) S2-2103898 from S2#145E. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10420,"status":"noted","reservation_date":"2022-01-27 20:20:03","uploaded":"2022-01-28 20:55:44","revisionof":"S2-2103898","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"17.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2868.0,"crrevision":1.0,"crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200512.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200513","title":"Removal of ATC","source":"Ericsson, Nokia, Nokia Shanghai Bell","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Update Network triggered service request procedure, PDU session modification procedure, EPS bearer ID allocation procedure to remove the asynchronous type communication","secretary_remarks":"Revision of (Noted) S2-2103899 from S2#145E. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10430,"status":"noted","reservation_date":"2022-01-27 20:20:04","uploaded":"2022-01-28 20:55:44","revisionof":"S2-2103899","revisedto":"","release":"Rel-15","crspec":"23.502","crspecversion":"15.15.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2746.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200513.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200514","title":"Removal of ATC","source":"Ericsson, Nokia, Nokia Shanghai Bell","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-16 mirror CR: Summary of change: Update Network triggered service request procedure, PDU session modification procedure, EPS bearer ID allocation procedure to remove the asynchronous type communication","secretary_remarks":"Revision of (Noted) S2-2103900 from S2#145E. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10440,"status":"noted","reservation_date":"2022-01-27 20:20:05","uploaded":"2022-01-28 20:55:44","revisionof":"S2-2103900","revisedto":"","release":"Rel-16","crspec":"23.502","crspecversion":"16.11.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2747.0,"crrevision":1.0,"crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200514.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200515","title":"Removal of ATC","source":"Ericsson, Nokia, Nokia Shanghai Bell","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-17 mirror CR: Summary of change: Update Network triggered service request procedure, PDU session modification procedure, EPS bearer ID allocation procedure to remove the asynchronous type communication","secretary_remarks":"Revision of (Noted) S2-2103901 from S2#145E. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10450,"status":"noted","reservation_date":"2022-01-27 20:20:06","uploaded":"2022-01-28 20:55:44","revisionof":"S2-2103901","revisedto":"","release":"Rel-17","crspec":"23.502","crspecversion":"17.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2748.0,"crrevision":1.0,"crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200515.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2200811","title":"LS from RAN WG2: LS on User consent Updating","source":"RAN WG2","contact":"Angelo Centonza","contact-id":35887,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 has agreed to the following working assumption: It is proposed to enable optional inclusion of the Management Based MDT PLMN List IE in the NG: UE CONTEXT MODIFICATION REQUEST message in Rel-17. The above implies that, when a change of the user consent information occurs, and if a signalling connection between NG-RAN and 5GC is active for the UE, the 5GC signals the updated user consent information to the NG-RAN. The NG-RAN can therefore replace the previous user consent information with the new one and use it at its earliest convenience. Question to SA WG3: RAN WG3 would like to ask SA WG3 whether an update of the user consent information shall be signalled to the RAN as soon as the update occurs. The use of such information at the NG-RAN would be to allow enforcement of the updated user consent information at the earliest RAN convenience, e.g. at the next MDT configuration. Question to CT WG4: RAN WG3 would like to ask CT WG4 whether the AMF can signal a new user consent information to the RAN whenever this is updated.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10460,"status":"noted","reservation_date":"2022-01-28 10:40:35","uploaded":"2022-01-29 09:56:21","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4, SA WG3","Cc":"SA WG5, SA WG2","lsoriginalls":"R3-221210","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2200811.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201011","title":"[DRAFT] Reply LS on support of Asynchronous Type Communication in N1N2MEssageTransfer","source":"Nokia, Nokia Shanghai Bell","contact":"Hannu Hietalahti","contact-id":69922,"tdoctype":"LS out","for":"Approval","abstract":"Proposal to reply to CT WG4 that no valid use case has been identified for ATC procedure","secretary_remarks":"Response to S2-2200054. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10160,"status":"noted","reservation_date":"2022-01-28 14:11:08","uploaded":"2022-01-28 17:05:01","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"SBIProtoc17"},{"winame":" TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"CT WG1, CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201011.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201024","title":"Discussion on NAS PDU delivery during PDU Session modification procedure.","source":"CATT","contact":"Yunjing Hou","contact-id":46707,"tdoctype":"discussion","for":"Discussion","abstract":"This discussion paper is proposed to discuss the NAS PDU delivery during PDU Session modification procedure.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10470,"status":"noted","reservation_date":"2022-01-28 14:14:34","uploaded":"2022-01-28 15:02:34","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.502","crspecversion":"","workitem":[{"winame":"5GS_Ph1"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201024.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201025","title":"NAS PDU delivery during PDU Session modification","source":"CATT","contact":"Yunjing Hou","contact-id":46707,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Delete the misleading description.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10480,"status":"noted","reservation_date":"2022-01-28 14:14:34","uploaded":"2022-01-28 15:02:34","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.502","crspecversion":"16.11.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":3404.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201025.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201026","title":"[DRAFT] Response LS on NAS PDU delivery during PDU Session modification procedure","source":"CATT","contact":"Yunjing Hou","contact-id":46707,"tdoctype":"LS out","for":"Approval","abstract":"Reply to S2-2200423","secretary_remarks":"Response to S2-2200423. CC#2: r06 agreed. Revised to S2-2201676.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10290,"status":"revised","reservation_date":"2022-01-28 14:14:36","uploaded":"2022-01-28 15:02:34","revisionof":"","revisedto":"S2-2201676","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_Ph1"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201026.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201189","title":"Completing description of NF profile","source":"Nokia, Nokia Shanghai Bell","contact":"Thomas Belling","contact-id":68266,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: For parameters documented in separate specifications, references to those specifications are added to Clause 6.2.6.2.","secretary_remarks":"r01 agreed. Revised to S2-2201273, merging S2-2200309","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10490,"status":"revised","reservation_date":"2022-01-28 18:54:56","uploaded":"2022-01-28 21:19:21","revisionof":"","revisedto":"S2-2201273","release":"Rel-17","crspec":"23.501","crspecversion":"17.3.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3577.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201189.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201251","title":"LS from GSMA 5GMRR: LS to 3GPP CT WG4 on Identification of source PLMN-ID in SBA","source":"GSMA 5GMRR","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"Background: Following the LS on Identification of source PLMN-ID in SBA from CT WG4 (C4-210249) and a Reply-LS on Identification of source PLMN-ID in SBA from SA WG3 to 5GJA (S3-212392), GSMA NG 5GMRR has discussed the need to uniquely identify the source PLMN-ID in all signalling messages over the N32-f interface, given that the cSEPP serving a PLMN may provide the pSEPP with one or multiple sender PLMN- ID(s). Below are the specific requirements from a business, operational and security perspective. Business and Operational: - Business Intelligence Tools - data collected needs to uniquely identify the specific PLMN-ID for the traffic. Without visibility to the PLMN-ID the need to correlate N32-c to retrieve the PLMN-ID would complicate the BSS tools and create a potential source of errors if translation tables are incorrect provisioned or not updated. - Probing Tools\/ Reporting systems - The unique PLMN-ID is needed on N32-f interfaces for probing systems to avoid complexity and cost. In the absence of visibility to the PLMN-ID, the probing systems need to retrieve the PLMN-ID from N32-c and can no longer be stateless, making them more complex and expensive. This case is applicable when the probing tools\/ reporting systems is deployed at one of the intermediaries, e.g. IPX provider. - SLA tracing - full visibility is required by PLMN-ID to track and manage E2E SLAs per contract and inter-operator charging capabilities. Without the PLMN-ID visibility no such services can be offered by intermediates with PRINS given that the list of PLMN-IDs is negotiated via the N32-c interface and not visible in the signalling messages on the N32-f interface. Security - It is understood that in some cases, the cSEPP cannot be certain which one of the PLMN-IDs to include, if none is explicitly received in an incoming request from NF consumer to the cSEPP. A solution is required on how cSEPP derives the unique appropriate PLMN ID in the request sent to the pSEPP even if the NF consumer has not included the intended source PLMN ID in the request. - The cSEPP cannot be certain which one of the PLMN-IDs to include and consequently the receiving pSEPP cannot uniquely determine whether the included PLMN-ID is to be trusted as if coming from the NF service consumer which initiated the message. - It is understood that in some cases, the pSEPP may detect a mismatch between the PLMN-ID included in N32-f messages and the PLMN-ID(s) from the cSEPP N32-c certificate. A solution is required on the actions of the SEPPs in order to: 1. avoid reattempts that could fall into same result or 2. proceed and, in that case to clarify how the pSEPP will choose the content of the headers sent to the NFp.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10510,"status":"noted","reservation_date":"2022-01-29 15:17:12","uploaded":"2022-01-29 15:17:41","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4, SA WG3, SA WG2","Cc":"","lsoriginalls":"5GMRR Doc 27_06r3","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201251.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201261","title":"LS from SA WG5: Reply LS on energy efficiency as guiding principle for new solutions","source":"SA WG5","contact":"Jean Michel Cornily","contact-id":7599,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 would like to thank TSG SA for your LS on energy efficiency as guiding principle for new solutions. SA WG5 would also like to inform TSG SA that we will initiate our Release 18 work on energy efficiency and energy saving in 5G networks at SA WG5#142e. In relation to your LS on Energy Efficiency as guiding principle for new solutions, amongst many objectives, our Rel-18 work on EE aims to investigate on digital sobriety applied to SA WG5 OA&M solutions. Given that a) the cheapest energy is the energy which is not used and b) the energy consumed by network elements \/ network functions has some dependency on data or signaling volumes processed and\/or transported and\/or stored by the network elements \/ network functions, we aim to: - study which forms digital sobriety could take in SA WG5, e.g. by minimizing the volume of OA&M data (number and type of operation parameters, input data to MDAF (Management Data Analytics Function), etc.) to be processed and\/or transported and\/or stored, - study if any metrics can be defined so as to compare different alternative solutions with regards to digital sobriety. Reference documents are: o SP-211440 (New Study on new aspects of EE for 5G networks Phase 2). Available at: https:\/\/portal.3gpp.org\/ngppapp\/TdocList.aspx?meetingId=60223 o SP-211441 (New WID on Enhancements of EE for 5G Phase 2). Available at: https:\/\/portal.3gpp.org\/ngppapp\/TdocList.aspx?meetingId=60223. To TSG SA, TSG RAN, TSG CT, SA WG1, SA WG2, SA WG3, SA WG4, SA WG6, RAN WG1, RAN WG2, RAN WG3, RAN WG4, RAN WG5, CT WG1, CT WG3, CT WG4, CT WG6: please take the above information into account.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10520,"status":"noted","reservation_date":"2022-02-08 06:42:27","uploaded":"2022-02-08 06:46:09","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"TSG RAN, TSG CT, SA WG1, SA WG2, SA WG3, SA WG4, SA WG6, RAN WG1, RAN WG2, RAN WG3, RAN WG4, RAN WG5, CT WG1, CT WG3, CT WG4, CT WG6","lsoriginalls":"S5-221501","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201261.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201264","title":"LS from SA WG5: LS on 3GPP SA5 work on 5G network energy efficiency and energy saving","source":"SA WG5","contact":"Jean Michel Cornily","contact-id":7599,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 would like to inform that it has completed its Release 17 work on the energy efficiency of 5G networks. Main outcomes include (non-exhaustive list): - Definition of Energy Efficiency (EE) KPIs for: o gNBs, both split and non-split, o 5G core network o 5G network slice of the following types: eMBB, URLLC, MIoT - Definition of the Energy Consumption (EC) of: o 5G network o 5G Network Function (NF). In case a 5G NF is composed of Virtualized Network Function(s) (VNF), the EC of the VNF is estimated (as there is no means to measure it yet) based on its virtual CPU usage (measurement collected from NFV MANO) - Energy saving use cases and solutions: o Capacity booster cell partially overlaid by candidate cell(s) o Capacity booster cell fully overlaid by candidate cell(s) o Switch off edge UPFs during off-peak traffic hours. {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10530,"status":"noted","reservation_date":"2022-02-08 06:42:27","uploaded":"2022-02-08 06:46:09","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA, NGMN, ITUT SG5, ETSI TC EE, ETSI ISG NFV","Cc":"TSG SA, SA WG2, TSG RAN","lsoriginalls":"S5-221680","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201264.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201271","title":"LS on PDU Session ID assignment for the Interworking scenario","source":"SA WG2","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG3. CC: CT WG4. Attachments: CR 3135 to 23.502 under working agreement","secretary_remarks":"Revision of S2-2200113r00, merging S2-2200311. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10050,"status":"approved","reservation_date":"2022-02-23 07:37:54","uploaded":"2022-03-01 08:41:12","revisionof":"S2-2200113","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_Ph1-CT"},{"winame":" TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2200008","lsto":"CT WG3","Cc":"CT WG4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201271.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201272","title":"Reply LS On ACL support for Indirect Data Forwarding","source":"SA WG2","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG3, CT WG4. CC: CT WG1","secretary_remarks":"Revision of S2-2200340r06. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10090,"status":"approved","reservation_date":"2022-02-23 07:37:54","uploaded":"2022-03-01 08:41:12","revisionof":"S2-2200340","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"TEI16"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2200023","lsto":"RAN WG3, CT WG4","Cc":"CT WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201272.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201273","title":"Completing description of NF profile","source":"Nokia, Nokia Shanghai Bell, Ericsson","contact":"Thomas Belling","contact-id":68266,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: For parameters documented in separate specifications, references to those specifications are added to Clause 6.2.6.2.","secretary_remarks":"Revision of S2-2201189r01, merging S2-2200309. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10500,"status":"agreed","reservation_date":"2022-02-23 07:37:55","uploaded":"2022-03-01 08:41:20","revisionof":"S2-2201189","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"17.3.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3577.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-220066","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201273.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201274","title":"Reply LS on mandatory SSC modes supported by UE","source":"SA WG2","contact":"Stefan Rommer","contact-id":25950,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG6 CC: CT WG1. Attachment: TS 23.501 CRs #3503 (Rel-15), #3504 (Rel-16), #3505 (Rel-17)","secretary_remarks":"Revision of S2-2200442r00. CC#2: Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10320,"status":"approved","reservation_date":"2022-02-23 07:37:56","uploaded":"2022-03-01 08:41:12","revisionof":"S2-2200442","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_Ph1_UEConTest"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2108269","lsto":"CT WG6","Cc":"CT WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201274.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201275","title":"SSC mode support by the UEs","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-16 mirror CR: Summary of change: Specifies that SSC mode 1 is mandatory while SSC modes 2 and 3 are optional to support in the UE. Further states that the PDU Session release with reconnect can be used independent of SSC mode.","secretary_remarks":"Revision of S2-2200444r00. CC#2: This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10360,"status":"agreed","reservation_date":"2022-02-23 07:37:56","uploaded":"2022-03-01 08:41:20","revisionof":"S2-2200444","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.11.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":3504.0,"crrevision":1.0,"crcategory":"A","tsg_crp":"SP-220042","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201275.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201276","title":"SSC mode support by the UEs","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-17 mirror CR: Summary of change: Specifies that SSC mode 1 is mandatory while SSC modes 2 and 3 are optional to support in the UE. Further states that the PDU Session release with reconnect can be used independent of SSC mode.","secretary_remarks":"Revision of S2-2200445r00. CC#2: This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10380,"status":"agreed","reservation_date":"2022-02-23 07:37:57","uploaded":"2022-03-01 08:41:20","revisionof":"S2-2200445","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"17.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":3505.0,"crrevision":1.0,"crcategory":"A","tsg_crp":"SP-220042","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201276.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201675","title":"SMF+PGW-C assigned PDU Session ID","source":"Ericsson, Nokia, Nokia Shanghai Bell, ZTE, Deutsche Telekom, Qualcomm, Orange, Telecom Italia, Verizon, Cisco, Vodafone, T-Mobile USA, AT&T","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: When the SMF+PGW-C is expected to allocate a PDU Session Id, if handover between EPS and EPC\/ePDG is required, based on operator's configuration, - the SMF+PGW-C may query the UDM for any PDU Session ID(s) that are already assigned by the same or different SMF+PGW-C by invoking Nudm_UECM_Get service operation. - When the SMF+PGW-C establishes the PDN connection successfully, the SMF+PGW-C may perform UDM registration using the Nudm_UECM_Registration service operation. Add a note clarifying the scenario that requires UDM interaction. Add a new sub-clause for PDN connection release, which is generic to any PDN connection with UDM registration.","secretary_remarks":"Revision of S2-2200310r10, merging S2-2200112. This CR was agreed, subject to a Working Agreement","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10260,"status":"agreed","reservation_date":"2022-02-23 07:39:05","uploaded":"2022-03-01 08:31:09","revisionof":"S2-2200310","revisedto":"","release":"Rel-17","crspec":"23.502","crspecversion":"17.3.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3135.0,"crrevision":4.0,"crcategory":"F","tsg_crp":"SP-220041","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201675.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201676","title":"Response LS on NAS PDU delivery during PDU Session modification procedure","source":"SA WG2","contact":"Yunjing Hou","contact-id":46707,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG3","secretary_remarks":"Revision of S2-2201026r06. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10300,"status":"approved","reservation_date":"2022-02-23 07:39:07","uploaded":"2022-03-01 08:41:12","revisionof":"S2-2201026","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_Ph1"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2200423","lsto":"RAN WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201676.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201677","title":"SSC mode support by the UEs","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Specifies that SSC mode 1 is mandatory while SSC modes 2 and 3 are optional to support in the UE. Further states that the PDU Session release with reconnect can be used independent of SSC mode.","secretary_remarks":"Revision of S2-2200443r03. This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10340,"status":"agreed","reservation_date":"2022-02-23 07:39:07","uploaded":"2022-03-01 08:41:20","revisionof":"S2-2200443","revisedto":"","release":"Rel-15","crspec":"23.501","crspecversion":"15.12.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":3503.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-220042","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_149E_Electronic_2022-02\/Docs\/S2-2201677.zip","group":"S2","meeting":"S2-149-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]