[{"name":"S2-2201921","title":"LS from RAN WG2: LS on paging subgrouping and PEI","source":"RAN WG2","contact":"Yanhua Li","contact-id":76945,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 discussed UE paging subgrouping as part of the Rel-17 work on UE power saving enhancement (see RP-200938). On paging subgrouping, the following provides the detailed agreements for the 2 approaches (CN-assigned subgrouping and UE ID-based subgrouping): \u00de Assume that one subgroup indication refers to either CN-assigned subgroups or UE ID-based subgroup (no overlapping) \u00de Both UE ID-based and CN-assigned subgrouping can be supported simultaneously in a cell, it is allowed to just support one of them. \u00de The total number of CN-assigned subgroups that is used is not fixed and can be configured up to 8 (e.g. by OAM). No impact on signalling is assumed. \u00de RAN introduces a new parameter Nsg-UEID to indicate its support of UE ID-based subgrouping. \u00de RAN does not support any type of subgrouping if its configuration for subgrouping is either absent or nullified (e.g. subgroupsNumPerPO is either absent or set to zero). FFS for the signalling details. \u00de We assume separate indications for UE capability of CN-assigned subgrouping and UE ID-based subgrouping. \u00de UE's capability of supporting the UE ID-based subgrouping is reported to RAN by AS UE capability signalling while R2 assumes that UE's capability of supporting the CN-assigned subgrouping is reported to CN by NAS signalling. RAN WG2 also discussed the Paging Early Indication, and agreed to the following: \u00de RAN WG2 assumes that if PEI is detected, and the PEI indicates that the UE has to monitor the associated PO, then the UE monitors paging DCI in the associated PO, including scheduling information for paging PDSCH (if included) as in legacy. This assumption may be updated based on RAN WG1 agreements. \u00de As a baseline RAN WG2 has a preference to support PEI with both DRX and eDRX, but potential issues (e.g. PEI and PTW) are FFS. \u00de For UE ID-based subgroups the UE identity is UE_ID = 5G-S-TMSI mod X, where X is 8192 (1024*8). \u00de Introduce a UERadioPagingInfo IE in the UECapabilityInformation message in NR in Rel-17. \u00de If the UE was not able to monitor the PEI occasion corresponding to its PO, the UE shall monitor the PO. Actions: To SA WG2 and CT WG1: RAN WG2 respectfully asks SA WG2 and CT WG1 to take the above information into account for their future work, and provide further information on the following issue once concluded: - NAS signalling between AMF and UE to convey the related information to the UE, e.g., UE's capability reporting by NAS.","secretary_remarks":"Revision of Postponed S2-2200032 from S2#149E. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"postponed","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 08:00:13","revisionof":"S2-2200032","revisedto":"S2-2203625","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, CT WG1, RAN WG3, RAN WG1","Cc":"","lsoriginalls":"R2-2111415","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201921.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201922","title":"LS from GSMA: Reply LS on IMEI for Non-Public Networks\/Private Networks without using USIM","source":"GSMA","contact":"Mungal Singh Dhanda","contact-id":84552,"tdoctype":"LS in","for":"Information","abstract":"GSMA TSG would like to thank SA WG2 for their LS TSG46_005\/S2-2108093 informing GSMA TSG that 5GS capable UEs are allowed to operate in private networks and Standalone Non-Public Networks (SNPNs) without a USIM, and a 5GS capable device can simultaneously connect to a PLMN using a USIM and to a private network\/SNPN without a USIM. GSMA TSG discussed the LS and detailed feedback provided below. Detailed respone: To support the 3GPP requirements for UEs supporting private networks and Standalone Non-Public Networks (SNPNs) without a USIM, GSMA TSG intends to update TAC Allocation Specifications TS.06 & TS.30 to allow the following: 1. TAC allocation for a UE that only supports operation with private networks and SNPN. 2. TAC allocation for a UE that supports simultaneous connection to a PLMN and to a private network and SNPN. GSMA TSG also discussed impact to the multi-SIM specification TS.37. As currently written, this specification applies only to devices used on public networks. GSMA TSG do not anticipate dual connection devices aimed at private networks and SNPNs in the short term. Accordingly GSMA TSG do not intend to add any requirements to support private networks and SNPNs, but have declared such device types to be out of scope of TS.37. GSMA TSG will undertake a revision of TS.37 when 3GPP has completed the Release 17 multi-SIM feature. For the specific two-part question in the LS, GSMA TSG would like to provide the following answers: Question part 1: 'SA WG2 would therefore like to ask GSMA TSG whether a device where the device can register simultaneously to a PLMN using (U)SIM and a private network\/SNPN that does not require (U)SIM is required to have and signal a separate IMEI for each simultaneous registration.' GSMA TSG reply 1: Yes. Question part 2: 'SA WG2 would also like GSMA TSG to clarify whether the requirement applies only to the IMEI as PEI used for 3GPP registration over 3GPP RAT or also to registration via N3IWF as long as different UE permanent identities are registered simultaneously for the same IMEI?' GSMA TSG reply 2: The GSMA requirement applies only to the IMEI (and IMEI part of IMEISV) as PEI used for 3GPP registration with PLMN\/private network\/SNPN over 3GPP RAT. When other type of PEI is used, it is out of scope of GSMA to provide feedback on that.","secretary_remarks":"Revision of Postponed S2-2200040 from S2#149E. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10060,"status":"noted","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 08:00:13","revisionof":"S2-2200040","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"SA WG1, SA WG3, CT WG1","lsoriginalls":"TSG46_028","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201922.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201924","title":"LS on access to multiple IMS networks via a 5GC network slice","source":"CT WG1","contact":"Sung Hwan Won","contact-id":70307,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 has been performing study on enhanced IMS to 5GC integration. Within the study a scenario depicted in the figure below was discussed (the figure is copied from 3GPP TR 23.700-10). In the scenario, a 5GC network slice provides access to a different IMS network for each of two UEs. Figure 5.1-5: Two UEs connect to separate IMS network through one common 5GC network slice To be more specific, CT WG1 investigated how an SMF in the 5GC network slice can discover an appropriate P-CSCF (in the figure above, for UE#1 and UE#2, an SMF in 5GC Slice #1 should select a P-CSCF in IMS network#1 and IMS network#2, respectively). Two solutions were incorporated in 3GPP TR 23.700-10: - Solution 2 (see clause 6.2 of the TR) proposes that a UE provides IMS network domain information during the establishment of an IMS PDU session. It is assumed that IMS network#1 and IMS network#2 are associated with the same DNN. - Solution 4 (see clause 6.4 of the TR) proposes that if multiple IMS networks can be accessed by a 5GC network slice, an IMS DNN needs to include information identifying the corresponding IMS network similar to clause AB.1.2.3 of 3GPP TS 23.228. Action: CT WG1 kindly asks SA WG2 to provide feedback on the solutions above. If SA WG2 has other comments on the P-CSCF discovery in the scenario described above, please include them also.","secretary_remarks":"Revision of Postponed S2-2200042 from S2#149E. 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-03-25 17:03:58","uploaded":"2022-03-28 08:00:13","revisionof":"S2-2200042","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG4","lsoriginalls":"C1-216839","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201924.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201925","title":"LS from CT WG4: Reply LS on Support of Asynchronous Type Communication in N1N2MessageTransfer","source":"CT WG4","contact":"Caixia Qi","contact-id":56676,"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":"Revision of Postponed S2-2200054 from S2#149E. Response drafted in S2-2202048. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10230,"status":"noted","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 08:00:13","revisionof":"S2-2200054","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_150E_Electronic_2022-04\/Docs\/S2-2201925.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201929","title":"LS from CT WG1: LS on progress of FS_eIMS5G2","source":"CT WG1","contact":"haitao Wei","contact-id":48249,"tdoctype":"LS in","for":"Action","abstract":"CT WG1, CT WG3 and CT WG4 are carrying out work of FS_eIMS5G2. From the perspective of CT WG1, we reached conclusions for key issue 1 of TR 23.700-10 as follows: - providing 'IMS home network domain name' in the traffic descriptor and Solution 4 will be the basis for work in the normative phase. Action: CT WG1 kindly asks SA WG2 to complete the normative work on solutions above.","secretary_remarks":"Revision of Postponed S2-2200082 from S2#149E. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10070,"status":"noted","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 08:00:13","revisionof":"S2-2200082","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG4, CT WG3","lsoriginalls":"C1-220734","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201929.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201935","title":"LS from SA WG3: LS on full Registration Request upon AMF re-allocation","source":"SA WG3","contact":"Vlasios Tsiatsis","contact-id":76181,"tdoctype":"LS in","for":"Action","abstract":"SA WG3 thanks SA WG2 for the LS Response on full registration request message to be rerouted via RAN. SA WG3 would like to respond to SA WG2 that the TS 23.502 CR 3150 (originally provided by SA WG2 in S2-2107865\/S2-2108374) is acceptable to SA WG3 and SA WG3 has agreed to the attached TS 33.501 CR. In addition, SA WG3 has concluded the study of the security of AMF re-allocation with no agreement on the security handling of the AMF re-allocation via RAN case. Action: SA WG3 kindly asks SA WG2 to take this information into account and potentially make appropriate changes to the existing specifications.","secretary_remarks":"Revision of Postponed S2-2201519 from S2#149E. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10080,"status":"noted","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 08:00:13","revisionof":"S2-2201519","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S3-220453","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201935.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201936","title":"LS from CT WG1: LS on Mapped NSSAI","source":"CT WG1","contact":"Robert Zaus","contact-id":85311,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 has discussed UE requirements regarding the NSSAI mapping during the transfer of a PDU session between HPLMN and VPLMN, or upon a change of the Allowed NSSAI in the Serving PLMN. Specifically, CT WG1 has been discussing the following scenario: 1. UE is registered in the HPLMN and receives Allowed NSSAI containing S-NSSAI_1 only. 2. UE establishes PDU session in the HPLMN using S-NSSAI_1. 3. UE moves to a VPLMN, which provides Allowed S-NSSAI containing S-NSSAI_2 only and no corresponding mapped S-NSSAI. CT WG1 has been discussing the validity of the above scenario, in particular step 3, and the corresponding UE behaviour in relation to the PDU session. In several places in TS 23.501, it is indicated that the mapping to HPLMN S-NSSAIs is optional. See, e.g., in clause 5.15.2.1: The optional mapping of Serving PLMN S-NSSAIs to HPLMN S-NSSAIs contains Serving PLMN S-NSSAI values and corresponding mapped HPLMN S-NSSAI values. To make sure that CT WG1 specs are fully in line with the stage 2 intention, CT WG1 would like to ask SA WG2 to clarify the following: Question 1: Could SA WG2 confirm that it is indeed optional for the VPLMN to provide the mapped S-NSSAI for VPLMN S-NSSAI 2? Question 2: If the answer to question 1 is yes, could SA WG2 further clarify the conditions under which it is optional to provide the mapped S-NSSAI. Question 3: If the answer to question 1 is yes, could SA WG2 further clarify if it is mandatory for the network to provide the mapped S-NSSAI to the UE if the mapped S-NSSAI is known to the network? Question 4: If the answer to question 3 is no, could SA WG2 further clarify how the UE determines the mapped S-NSSAI in that case?. Action: CT WG1 kindly asks SA WG2 to answer CT WG1's questions.","secretary_remarks":"Responses drafted in S2-2202046, S2-2202239, S2-2202369, S2-2202662, S2-2202876, S2-2202576. Final response in S2-2203151","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":0,"status":"replied to","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C1-222095","lsreply":"S2-2203022, S2-2203022, S2-2203151","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201936.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201937","title":"LS on handling of packet filters when the supported number is exceeded","source":"CT WG3","contact":"Susana Fernandez","contact-id":42321,"tdoctype":"LS in","for":"Action","abstract":"TS 23.501 clause 5.7.1.4 states that in 5G, the UE can indicate the number of supported packet filters for signalled QoS rules of the PDU session during the PDU Session Establishment procedure or using the PDU Session Modification procedure after the first inter-system change from EPS to 5GS for a PDU Session established in EPS and transferred from EPS with N26 interface. When dynamic PCC is deployed, the PCF shall ensure that the sum of the packet filters used by all PCC rules which trigger the generation of signalled QoS rules does not exceed that number. The SMF ensures that the sum of the Packet Filters used by all signalled QoS rules for a PDU Session does not exceed the number indicated by the UE. The number of packet filters supported in LTE is limited to 16 per PDN connection but the number of packet filters per PDU session can be up to 1024 in 5G. As described in TS 23.502, clause 4.11.1.1, when the UE is served by the 5GC, during PDU Session establishment and GBR QoS Flow establishment, SMF+PGW-C performs EPS QoS mappings, from the 5G QoS parameters obtained from the PCF, and allocates TFT with the PCC rules obtained from the PCF if PCC is deployed. Otherwise, EPS QoS mappings and TFT allocation are mapped by the SMF+PGW-C locally. Question 1: For a UE with an established PDU session in 5GS with dynamic PCC deployment, how does the SMF+PGW-C know what packet filters will be part of the TFT allocation based on the PCC rules obtained from the PCF if the number of packet filters for signalled QoS rules exceeds the number supported in EPS? Is there any precedence criteria for the SMF+PGW-C to consider the pre-defined PCC rules (known or unknown to the PCF) in the TFT allocation? Question 2: For a UE with an established PDU session in 5GS without dynamic PCC deployment, how does the SMF+PGW-C know what packet filters will be part of the allocated TFT based on the local policy if the number of packet filters for signalled QoS rules exceeds the number supported in EPS?. Action: SA WG2 is kindly requested to answer the questions above, and update stage 2 if deemed necessary.","secretary_remarks":"Responses drafted in S2-2202182, S2-2202448, S2-2202825. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10670,"status":"postponed","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"S2-2203627","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C3-221503","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201937.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201938","title":"LS from BBF: EAP-5G change; Answer to S2-2109043","source":"BBF","contact":"Lincoln Lavoie","contact-id":39231,"tdoctype":"LS in","for":"Information","abstract":"Dear colleagues, In your previous liaison, you noted 'SA WG2 assumes that the changes in TR-456 would only impact the way EAP-5G is transported between RG and W-AGF and has no impacts to EAP-5G as such.' We would like to confirm that the changes in TR-456 do NOT impact EAP-5G. EAP-5G is no longer used in the W-5GAN procedures between AGF and 5G-RG. EAP-5G is deprecated in TR-456 issue 2. As previously communicated, we have come to realize that the use of EAP-5G over PPP for W-CP initiation is an unsuitable choice for 5G-RG support over wireline. As such we have modified our call flows to initiate the VSNP procedures to establish reliable NAS transport with fragmentation and reassembly support earlier in the call flow sequence; and communicate the key elements of the EAP-5G exchange as part of W-CP initiation dialog within our framework of VSNP messaging. We note the above change will have a number of impacts on TS23.316. We have documented the updated procedures in issue 2 of TR-456, which is now published at https:\/\/www.broadband-forum.org\/technical\/download\/TR-456_Issue-2.pdf. We would like to inform 3GPP that WWC phase 2 is now finished and includes the following published documents: TR-470i2 - 5G Wireless Wireline Convergence Architecture, TR-124i7 - Functional Requirements for Broadband Residential Gateway Devices , TR-456i2 - AGF Functional Requirements, available at https:\/\/www.broadband-forum.org\/technical-reports. We look forward to continuing our fruitful relationship. Thanks, Lincoln Lavoie Broadband Forum Technical Committee Chair","secretary_remarks":"Response drafted in S2-2201984. Final response in S2-2203017","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10780,"status":"endorsed","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, CT WG4, CT WG1","Cc":"","lsoriginalls":"LIAISE-508-02","lsreply":"S2-2203017","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201938.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201939","title":"LS from BBF: LS on 5GC Support of DHCP signaling for RG; Response to S2-2009340","source":"BBF","contact":"Lincoln Lavoie","contact-id":39231,"tdoctype":"LS in","for":"Information","abstract":"Dear colleagues, Thank you for your liaison. On point 1. We note your answer, thank you. On point 2 and point 3. We noted the changes you have made in TS23.316. Thank you. We notice that in TS23.316, you refer to TR-456, we recommend that you refer explicitly to TR-456 latest issue. On point 4. We note your answer, thank you. On point 5. UPF specifications are owned by 3GPP. We believe it will be detrimental to the industry to split such requirements\/specifications between different standardization bodies. We consider the need to support framed routes is not just for wireline RGs but also for FWA and may be applicable to other verticals. We also understand that the 5GC won't be able to distinguish the type of connected access network. Therefore we recommend that the support for framed routes in UPF is elevated to a mandatory requirement in clause 5.16 of TS29.244. We look forward to continuing our fruitful relationship. Thanks, Lincoln Lavoie Broadband Forum Technical Committee Chair","secretary_remarks":"Response drafted in S2-2202170. Final response in S2-2203029","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10810,"status":"replied to","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"LIAISE-512-on DHCP to SA-03","lsreply":"S2-2203029, S2-2203029","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201939.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201940","title":"LS from GSMA: Reply LS to 3GPP SA2 on ARP PL","source":"GSMA","contact":"Steffen Habermann","contact-id":5927,"tdoctype":"LS in","for":"Action","abstract":"Action: The GSMA NG NRG kindly requests SA WG2 to take this information into account and to provide feedback.","secretary_remarks":"Response drafted in S2-2202185. Final response in S2-2203023","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10250,"status":"replied to","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"NRG 012_206r3","lsreply":"S2-2203023, S2-2203023","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201940.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201941","title":"LS from EUWENA: LS on presentation of EUWENA and involvement in 3GPP on Non Public Network","source":"EUWENA","contact":"Thierry Berisot","contact-id":77639,"tdoctype":"LS in","for":"Action","abstract":"EUWENA (European Users Wireless Enterprise Network Association, https:\/\/www.euwena.eu) has been established in 2021, as a vehicle to entice and promote private wireless networks (Non Public Network for 3GPP) or services for industries and verticals. EUWENA clearly recognizes the need for mobile connectivity in a wide range of public and private enterprises and organisations related to the particular area where the enterprise or organization operates. This need can be geographically determined: from a confined, local area, all the way up to a nationwide and even global footprint; indoor and\/or outdoor; application-related such as voice, data or video, from modest IoT messages up to 8k-video-streams, and diverse levels of criticality and latency from basic non-real-time data transmission to the steering of a crane. In multiple scenarios, a best effort solution is simply not good enough, as critical services require high availability with guaranteed service levels. EUWENA mission statement [1] is: 'Working together with all interested parties, EUWENA acts as a catalyst for the wider adoption of feature-rich private mobile networks across Europe. It advocates sufficient, accessible, affordable, harmonised spectrum and promotes an open, multi-vendor approach to advanced services and applications running in these networks. EUWENA's ultimate goal through its actions is to make the adoption of such solutions as easy as possible for as many organisations as possible, thereby creating enhanced and sustained value for enterprises and wider society.' In this context, EUWENA intends to represent verticals and sees its roles as following: - To speed up the availability and harmonisation of sufficient frequency spectrum for private wireless networks in Europe, stimulating the creation of an open ecosystem. - To exchange knowledge and experience on the technology, demand and supply market, to contribute to the digital transformation process, accelerating the adoption of mobile broadband technology by enterprises in Europe and supporting the specific needs of vertical sectors. - To inform, advise and represent European enterprise users in established European spectrum, regulatory and related organisations and in international interest groups for private networks. - To help enterprise customers define and deploy the best spectrum and private mobile network strategies Within EUWENA, there are currently 4 technical workgroups which have specific focus areas: - Standards Working Group: It is the main body within EUWENA feeding industry and enterprise private wireless network requirements into regional and global standards organisations, liaising closely with 3GPP, ETSI and other relevant and related bodies, as well as informing our members of latest developments, standards releases and main future trends which will impact their businesses - Working Group on Alliances and Associations: Some countries already have national business-critical user wireless solution associations. In addition, there are already a few international bodies and associations, either horizontally oriented or vertically oriented towards a specific sector. - Spectrum harmonisation Working Group: Wireless networks and solutions start with the availability of appropriate frequency spectrum. EUWENA advocates sufficient, accessible, affordable, harmonized spectrum for private broadband networks in Europe. EUWENA will develop the approach, strategy and undertake necessary actions to achieve this goal. - Supply Ecosystem Working Group: Supply and availability of a diverse eco-system of technology will enable the full benefits of private 4G\/5G spectrum for the users A 5th Working group related to 'use cases' is under definition. In relation to the Standards Working Group and 3GPP, EUWENA members, who are as well 3GPP members, are committed to actively contribute in the 3GPP activities related to Private Cellular Networks or Non Public Networks in particular in the following 3GPP work","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10280,"status":"noted","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, TSG RAN, TSG CT","Cc":"SA WG1, SA WG2, SA WG6, RAN WG1, RAN WG2, RAN WG3, RAN WG4, CT WG1, CT WG6","lsoriginalls":"LS EUWENA","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201941.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201945","title":"LS from RAN WG2: LS on how to receive the first PC5-S unicast message during PC5-S connection setup procedure","source":"RAN WG2","contact":"Hao Xu","contact-id":85477,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 had discussed the issue on how to receive the first PC5-S unicast signalling in AS layer during PC5-S connection setup procedure. RAN WG2 would like to ask SA WG2 to confirm that RX UE cannot know the peer UE's source L2 ID for the following scenarios: {. . .} RAN WG2 have discussed whether there would be some problem for related AS layer functions (e.g. MAC addressing filtering, SLRB handling, etc.), if in any above cases a UE cannot know the peer UE's Source L2 ID in advance. In case SA WG2 confirms the aforementioned issue exists for any of above scenario, RAN WG2 had already made WAs to solve related problems, and thus do not expect any impact\/change caused to SA WG2 Specs.","secretary_remarks":"Response drafted in S2-2202376. Final response in S2-2203024","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10360,"status":"replied to","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"R2-2203691","lsreply":"S2-2203024, S2-2203024","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201945.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201950","title":"LS from RAN WG2: Reply LS on opens issues for NB-IoT and eMTC support for NTN","source":"RAN WG2","contact":"Ping Yuan","contact-id":81389,"tdoctype":"LS in","for":"Information","abstract":"RAN WG2 thanks RAN WG3 for the LS R3-221406. Concerning the question to RAN WG2: RAN WG3 assumes that the LTE-M NTN capable UE indicates category M1 or M2 in its UE Radio Capability, which then the eNB will indicate to the CN as LTE-M Satellite Indication in the UE CAPABILITY INFO INDICATION message. RAN WG3 would ask RAN WG2 and SA WG2 to confirm this assumption. RAN WG2 confirms that LTE-M NTN capable UE indicates category M1 or M2 in its UE Radio capability and also IoT-NTN support as separate capability indication, so the eNB can set the LTE-M Satellite Indication in the UE CAPABILITY INFO INDICATION message based on these indications.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10030,"status":"noted","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"SA WG2","lsoriginalls":"R2-2204108","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201950.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201951","title":"LS from RAN WG2: LS on EPS fallback enhancements","source":"RAN WG2","contact":"rui wang","contact-id":91183,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 is discussing solutions to reduce EPS fallback latency for IDLE\/INACTIVE UE in TEI17. The motivation is that some operators and venders feel the current EPS fallback procedure is relative long which has negative impact on UE experience of voice service, thus prefer to reduce the latency. However, considering legacy EPS fallback procedure involves both of core network and RAN, there are concerns that the candidate solutions discussed in RAN WG2 may create impact on upper layer signalling or core network procedures which is not RAN WG2's intention for TEI17. The solutions includes two aspects, i.e. enhancements for MT case, and enhancements for MO case. The brief introduction is as blow: 1. MT case: When network indicates EPS fallback for voice service, the idle\/inactive UE goes directly to E-UTRA for connection establishment upon paging in NR. There are two candidate alternatives for the EPS fallback indication, i.e. Alt 1: The EPS fallback indication is included in paging message. Upon gNB receiving paging indicating voice service type from core network (as same as agreed for MUSIM), gNB can decide to perform EPS fallback for the UE, and indicate EPS fallback in Uu paging message. (see details in R2-2202818.) Alt 2: The EPS fallback indication is included in SIB. The detailed indication could be VoNR support indication (see details in R2-2202505) or E-UTRA frequency information (see details in R2-2202791). When EPS fallback is indicated in SIB and voice service type is indicated in Uu paging message, the idle\/inactive UE can assume network triggering EPS fallback for it. 2. MO case: The EPS fallback indication in SIB as proposed in Alt 2 can apply to MO case, i.e. when idle\/inactive UE initiating MO call, if EPS fallback is indicated in SIB, it goes directly to E-UTRA for connection establishment. In RAN WG2 discussion there is no consensus whether SA WG2\/CT WG1 existing procedures and specification can support these candidate solutions without any change, therefore RAN WG2 would like to request SA WG2 and CT WG1 to evaluate and inform RAN WG2 whether there is any impact foreseen. If there is, indicating the detailed impact would be helpful to RAN WG2. In RAN WG2 discussion there are also concerns raised that adding paging cause\/SIB indication for EPS fallback will have security issues. RAN WG2 would like to request SA WG3 to evaluate and inform RAN WG2 whether there are security issues if there is a new EPS fallback indicator included in paging or SIB. Action: RAN WG2 kindly asks SA WG2, CT WG1 and SA WG3 to take into consideration the information above and provide answers to the questions above.","secretary_remarks":"Responses drafted in S2-2201997 and S2-2202366. Final response in S2-2203590","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10290,"status":"replied to","reservation_date":"2022-03-25 17:03:58","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, CT WG1, SA WG3","Cc":"","lsoriginalls":"R2-2204236","lsreply":"S2-2203590, S2-2203590","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201951.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201958","title":"LS from SA WG3: Reply LS on opens issues for NB-IoT and eMTC support for NTN","source":"SA WG3","contact":"Wei Lu","contact-id":90295,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 would like to thank RAN WG3 for their LS R3-221406 on opens issues for NB-IoT and eMTC support for NTN. Regarding the question whether a coarse-grained location is sufficient for UEs using only CP CIoT EPS optimization in release 17, SA WG3 believes that the answer needs to be provided by SA WG2. From SA WG3's point of view, there is no security or privacy issue that a coarse grained location such as CGI is provided in the ULI to the MME, as backhaul security is available for protecting such information in NGAP messages. Action: SA WG3 kindly asks RAN WG3 and SA WG2 to take the above feedback into account.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10040,"status":"noted","reservation_date":"2022-03-25 17:03:59","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"RAN WG2, SA WG2","lsoriginalls":"S3-220543","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201958.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201960","title":"LS from SA WG4: LS on Traffic Identification within 5G Media Streaming","source":"SA WG4","contact":"Thorsten Lohmar","contact-id":59317,"tdoctype":"LS in","for":"Action","abstract":"SA WG4 has executed a study on 5G Media Streaming extensions within Release 17. The study is about to be concluded. Among other key issues, SA WG4 has studied the use of Traffic Identification. A number of different 5G Media Streaming features rely on the 5G System being able to identify traffic flows corresponding to media sessions. However, multimedia streaming applications might not be able to uniquely identify the 5-tuples of a streaming session, because IP addresses and port numbers often change as a result of load balancing, CDN distribution, multiple concurrent HTTP requests for different types of resources, etc. This aspect of the study addressed how to use the available 5G System application detection functions e.g. for QoS profile usage. Action: SA WG4 kindly asks SA WG2 and CT WG3 to review specifically clause 5.3.5 of TR 26.804.","secretary_remarks":"Response drafted in S2-2202188. This was postponed.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"postponed","reservation_date":"2022-03-25 17:03:59","uploaded":"2022-03-28 10:15:39","revisionof":"","revisedto":"S2-2203628","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, CT WG3","Cc":"","lsoriginalls":"S4-220305","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201960.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201962","title":"LS from ETSI ISG MEC: LS to 3GPP on MEC Federation and interest to collaborate","source":"ETSI ISG MEC","contact":"Pekka Kuure","contact-id":68365,"tdoctype":"LS in","for":"Information","abstract":"Further to the joint workshop organized by GSMA Operator Platform Group (OPG), on 21\/01\/2022, ETSI MEC would like to reiterate their interest to collaborate with 3GPP to create consistent standards in avoidance of work duplication. ETSI MEC understand LS exchange to be the most suitable mechanism, coupled with common members participation and contribution in the relevant 3GPP groups. ETSI MEC considers the time is right to align efforts, starting from the alignment on the SDOs API mapping and work-split. This is expected to show complementary coverage of OP architecture and benefit the entire ecosystem, under the guidance from the OPG on the overall collaboration framework. In order for ETSI MEC to progress its work, such a technical alignment with 3GPP is considered timely (and also to some extent not only motivated by the GSMA needs for federation, even if this is a main driver). So, the present LS is not intended to substitute to any communication from GSMA (that we expect to arrive soon) on the collaboration, but for the sake of technical progress on the details of the standard alignment between ETSI MEC and 3GPP. ETSI ISG MEC would like to share the public location of the group's slides presented at the workshop (here) and inform 3GPP about the latest progress of our work, also described in the recent ETSI press release (here). In particular: - The ISG has recently published the following deliverables: MEC 003 v3.1.1 (here), MEC 010-2 v2.2.1 (here) and MEC 021 v2.2.1 (here). The latest advances to these GS capture the MEC Architecture with variant for MEC Federation, bug fixing on MEC Application lifecycle management, and updates on Application Mobility Service API. - ETSI GS MEC 040 work item on 'MEC Federation Enablement APIs' is continuously evolving and each new iteration is being made available in the MEC Open Area (https:\/\/docbox.etsi.org\/ISG\/MEC\/Open) in a dedicated folder (here). Latest advances of MEC 040 include updates related to OP architecture, e.g.: registration of MEC system(s) to the federation, MEC Service discovery, Application package management, Application instance lifecycle management and also data type definition related to the information provided by MEC orchestrator as a part of the 'Registration of MEC system to the federation'. All these updates are coherent with the approach proposed at the workshop (slides 4-10, here). Further clauses 6 and 7 are intended for normative API design, and will be added later, also based on the collaboration with GSMA. - Also the ETSI GS MEC 011 drafts are available in a dedicated folder of the MEC Open Area (here), and it is another important enabler for MEC in the view of aligning with 3GPP, not only for federation purposes. The latest advance of MEC 011 includes the introduction of data type AppInfo representing the information provided by a MEC application instance as part of the 'application registration request' message. This data type is intended to allow registration of MEC applications, also for those where LCM is not performed by MEC system (e.g. EASs). Moreover, for the sake of progress in the normative work to address the GSMA OP requirements, we would like to propose some topics for collaboration with 3GPP groups: - the synergy between Mp1 and EDGE-3 in SA WG6; - clarification of the ETSI MEC specifications and their role for the OP-EWBI\/OP-NBI APIs; - how to reuse existing specs from 3GPP and ETSI MEC, perhaps it will be useful that both SDOs will work together e.g. to bring an example of the proposed \u00abpackaging approach\u00bb (see ETSI MEC slides at the workshop), as this could help a common understanding, especially from OPG side; To summarize, ETSI ISG MEC is willing to foster a collaboration with SA WG6 on this topic and look forward to further coordination and alignment among the two standard bodies. We hope that the above information on our current and finalized work area would be helpful for your work, and in case needed, we are happy to provide fur","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10050,"status":"noted","reservation_date":"2022-03-25 17:03:59","uploaded":"2022-03-28 11:58:00","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"TSG SA, SA WG5, SA WG2, ETSI NFV, GSMA OPG, GSMA OPAG","lsoriginalls":"MEC(22)000127r5","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201962.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201964","title":"LS from ETSI EMTEL: LS response to 3GPP SA1 on IMS emergency communication improvement - SMS to emergency centre","source":"ETSI EMTEL","contact":"Merieme EL Orch","contact-id":64548,"tdoctype":"LS in","for":"Action","abstract":"ETSI EMTEL followed the exchanges between SA WG1 and GSMA NRG with regards to the extension of SMS to emergency services in Roaming in the scope of the enrichment and improvement IMS emergency communications. ETSI EMTEL has performed a study in the past - see ETSI TR 102 444 v1.1.1 - on the Analysis of the Short Message Service (SMS) and Cell Broadcast Service (CBS) for Emergency Messaging applications. GSMA request proposes resolution of main issue identified by the study: - The subscriber roaming temporarily in a country other than their home country requires local emergency assistance by sending a Short Message would require that subscribers home network operator SC having to route the emergency Short Message to a PSAP local to the subscriber. The LBO data roaming connection enables this capability to route the Short Message to the PSAP local. ETSI EMTEL sees Short Message Service to emergency centre as a complementary solution to emergency messaging communication services - to complies to part of the European Accessibility Act, moreover, to provide alternative emergency communication in case of the type of emergency doesn't allow an emergency voice call. SMS to emergency centre could benefit of the IMS emergency registration procedure, the low implementation impacts of the service already operational for a wide commercial use and can often succeed in poor radio conditions where voice calls cannot, or in conditions of voice congestion in the network. In addition, the member states are mandates to transpose the European Electronic Communications Code Directive 2018\/1972 by December 2020, recital 285 of this directive: (285) '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. \u2026'. Action: ETSI EMTEL confirm the support to GSMA request to standardise SMS to emergency centres, whilst roaming, and kindly asks the 3GPP to consider adding the requirements with regards to this request in the appropriate specifications.","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-03-25 17:03:59","uploaded":"2022-03-29 05:18:07","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2, CT WG1","Cc":"","lsoriginalls":"EMTEL(22)000042","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201964.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201970","title":"LS from GSMA: LS to 3GPP SA2 on VoLTE Roaming GBR Handling","source":"GSMA","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"GSMA NG NRG kindly requests SA WG2 to provide a functionality for VPLMN to apply its own QoS policy for bearer setup process in VoLTE roaming, including the GBR parameter values. Action: GSMA NG NRG kindly requests SA WG2 to take into account the request above and define a solution which allows VPLMN to be fully in charge of the QoS policy for VoLTE\/VoNR inbound roaming service by having possibility to override also the GBR parameter value sent by HPLMN during the bearer setup process.","secretary_remarks":"Response drafted in S2-2202185. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10400,"status":"postponed","reservation_date":"2022-03-25 17:03:59","uploaded":"2022-03-29 16:30:37","revisionof":"","revisedto":"S2-2203630","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"NRG 13_201r2","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201970.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201983","title":"Generalizing NAS transport between 5G and W-AGF to accommodate latest BBF developments","source":"Ericsson, Nokia, Nokia Shanghai Bell","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Generalize the call flow in TS 23.316 to work with different ways to carry AS parameters and NAS PDUs. The concept of W-CP protocol is already used in 23.316 to represent a generic protocol that is then further defined by BBF and Cablelabs. This should fit also Cablelabs deployments since the protocol between RG and W-AGF becomes generic and simply refer to BBF and Cablelabs.","secretary_remarks":"Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10520,"status":"agreed","reservation_date":"2022-03-26 00:33:03","uploaded":"2022-03-29 21:03:02","revisionof":"","revisedto":"S2-2203737","release":"Rel-17","crspec":"23.316","crspecversion":"17.2.0","workitem":[{"winame":"5WWC"}],"crnumber":2063.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201983.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201984","title":"Reply LS on EAP-5G change","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Replies to incoming LS from BBF regarding EAP-5G","secretary_remarks":"Response to S2-2201938. r00 agreed. Revised to S2-2203017","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10790,"status":"revised","reservation_date":"2022-03-26 00:33:03","uploaded":"2022-03-29 21:03:02","revisionof":"","revisedto":"S2-2203017","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5WWC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"BBF","Cc":"CT WG4, CT WG1, CableLabs","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201984.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201996","title":"Requirement for signalling separate IMEI for each network subscription","source":"Qualcomm Incorporated","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Introduce requirement that the UE shall use a separate PEI for each network subscription when it registers to the network","secretary_remarks":"Revision of (Postponed) S2-2200386 from S2#149E. r01 agreed. Revised to S2-2203026","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10530,"status":"revised","reservation_date":"2022-03-27 19:19:16","uploaded":"2022-03-29 18:45:05","revisionof":"S2-2200386","revisedto":"S2-2203026","release":"Rel-16","crspec":"23.501","crspecversion":"16.12.0","workitem":[{"winame":"Vertical_LAN"}],"crnumber":3496.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201996.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2201997","title":"Reply LS on EPS fallback enhancements","source":"Qualcomm","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS out","for":"Approval","abstract":"Replies to LS R2-2204236","secretary_remarks":"Response to S2-2201951. r09 agreed. Revised to S2-2203590.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10300,"status":"revised","reservation_date":"2022-03-27 19:25:02","uploaded":"2022-03-29 18:45:05","revisionof":"","revisedto":"S2-2203590","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2","Cc":"CT WG1, SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2201997.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202046","title":"Reply LS on Mapped NSSAI","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS from CT WG1 on Mapped NSSAI","secretary_remarks":"Response to S2-2201936. r07 agreed. Revised to S2-2203022","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10140,"status":"revised","reservation_date":"2022-03-28 09:22:57","uploaded":"2022-03-29 14:51:13","revisionof":"","revisedto":"S2-2203022","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5GProtoc17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202046.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202047","title":"Clarification on Mapped NSSAI","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarification on Mapped NSSAI","secretary_remarks":"Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10110,"status":"agreed","reservation_date":"2022-03-28 09:22:57","uploaded":"2022-03-29 14:51:13","revisionof":"","revisedto":"SP-220561","release":"Rel-17","crspec":"23.501","crspecversion":"17.4.0","workitem":[{"winame":"eNS"},{"winame":" TEI17"}],"crnumber":3583.0,"crrevision":"","crcategory":"F","tsg_crp":"SP-220414","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202047.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202048","title":"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":"LS Reply on ATC to CT WG4.","secretary_remarks":"Response to S2-2201925. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10240,"status":"noted","reservation_date":"2022-03-28 09:22:58","uploaded":"2022-03-29 14:51:13","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_150E_Electronic_2022-04\/Docs\/S2-2202048.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202170","title":"[DRAFT] LS on LS on 5GC Support of DHCP signaling for RG","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"[draft] LS on LS on 5GC Support of DHCP signaling for RG; Response to S2-2009340","secretary_remarks":"Response to S2-2201939. r01 agreed. Revised to S2-2203029","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10820,"status":"revised","reservation_date":"2022-03-28 16:37:57","uploaded":"2022-03-29 19:09:54","revisionof":"","revisedto":"S2-2203029","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5WWC"},{"winame":" TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"BBF","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202170.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202171","title":"Alignment to BBF LS 512 (Frame route, BBF references)","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Update the BBF References, keeping only one reference to TR-456 SMF can select a UPF supporting Framed Routes.","secretary_remarks":"r02 agreed. Revised to S2-2203030","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10550,"status":"revised","reservation_date":"2022-03-28 16:37:57","uploaded":"2022-03-29 19:09:54","revisionof":"","revisedto":"S2-2203030","release":"Rel-17","crspec":"23.316","crspecversion":"17.2.0","workitem":[{"winame":"5WWC"},{"winame":" TEI17"}],"crnumber":2064.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202171.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202172","title":"Alignment to BBF LS 512 (Frame route, BBF references)","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Update the BBF References SMF can select a UPF supporting Framed Routes.","secretary_remarks":"r02 agreed. Revised to S2-2203031","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10570,"status":"revised","reservation_date":"2022-03-28 16:37:59","uploaded":"2022-03-29 19:09:54","revisionof":"","revisedto":"S2-2203031","release":"Rel-17","crspec":"23.501","crspecversion":"17.4.0","workitem":[{"winame":"5WWC"},{"winame":" TEI17"}],"crnumber":3591.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202172.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202182","title":"[DRAFT] Reply to LS handling of packet filters when the supported number is exceeded","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"This paper replies CT WG3 which NF decides PCC rules for TFT filter allocation to avoid reaching limit","secretary_remarks":"Response to S2-2201937. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10680,"status":"postponed","reservation_date":"2022-03-28 16:56:13","uploaded":"2022-03-29 21:08:07","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1-CT"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202182.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202183","title":"Number of TFT filters exceeding allowed limit for 5GS to EPS interworking","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: 4.11.1.1: PCF indicates in PCC rule whether the PCC rule can be skipped in TFT filter derivation\/allocation and SMF+PGW-C removes PCC rule(s) if TFT filter allocation is skipped due to number of TFT filters exceeding limit. 4.11.1.2.1 & 4.11.1.3.2: add text that SMF+PGW-C informs PCF of the PCC rule removal if there are still PCC rules that did not have allocated TFT filter.","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10720,"status":"postponed","reservation_date":"2022-03-28 16:56:13","uploaded":"2022-03-29 21:08:07","revisionof":"","revisedto":"S2-2203836","release":"Rel-17","crspec":"23.502","crspecversion":"17.4.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3430.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202183.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202184","title":"Number of TFT filters exceeding allowed limit for 5GS to EPS interworking","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add a new indication in PCC rule that the PCC rule can be skipped for TFT filter allocation if the number of TFT filters reaches the limite (i.e.16)","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10730,"status":"postponed","reservation_date":"2022-03-28 16:56:15","uploaded":"2022-03-29 21:08:07","revisionof":"","revisedto":"S2-2203837","release":"Rel-17","crspec":"23.503","crspecversion":"17.4.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":712.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202184.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202185","title":"[DRAFT] Reply LS to GSMA NRG on ARP override and GBR alignment for VoLTE roaming","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"TThis paper replies GSMA on ARP override and GBR downgrade","secretary_remarks":"Response to S2-2201940 and S2-2201970. r01 agreed. Revised to S2-2203023","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10260,"status":"revised","reservation_date":"2022-03-28 16:56:16","uploaded":"2022-03-29 21:08:07","revisionof":"","revisedto":"S2-2203023","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA","Cc":"CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202185.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202186","title":"Handling of ARP and GBR for IMS voice service in home routed roaming","source":"Ericsson, Deutsche Telekom","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Allow ARP override and GBR downgrade for IMS voice service at home routed roaming.","secretary_remarks":"r06 agreed. Revised to S2-2203027","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10590,"status":"revised","reservation_date":"2022-03-28 16:56:16","uploaded":"2022-03-29 21:08:07","revisionof":"","revisedto":"S2-2203027","release":"Rel-17","crspec":"23.401","crspecversion":"17.4.0","workitem":[{"winame":"TEI17"}],"crnumber":3695.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202186.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202187","title":"Handling of ARP and GBR for IMS voice service in home routed roaming","source":"Ericsson, Deutsche Telekom","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Allow ARP override and GBR downgrade for IMS voice service in home routed roaming.","secretary_remarks":"r07 agreed. Revised to S2-2203028","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10610,"status":"revised","reservation_date":"2022-03-28 16:56:17","uploaded":"2022-03-29 21:08:07","revisionof":"","revisedto":"S2-2203028","release":"Rel-17","crspec":"23.501","crspecversion":"17.4.0","workitem":[{"winame":"TEI17"}],"crnumber":3593.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202187.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202188","title":"[DRAFT] Reply LS on Traffic Identification within 5G Media Streaming","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"This paper replies SA WG4 about ToS\/TC over N33","secretary_remarks":"Response to S2-2201960. This was postponed.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10340,"status":"postponed","reservation_date":"2022-03-28 16:56:17","uploaded":"2022-03-29 21:08:07","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG4","Cc":"CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202188.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202189","title":"Traffic Identification using ToS\/TC for 5G Media Streaming","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Change 'flow description' to 'flow information' clarifying the content of flow information is as specified in clause 5.7.6 of TS 23.501 Add note that if ToS\/TC is to be used for service data flow detection, network configuration needs to ensure there is no ToS\/TC re-marking applied from the application to the PSA UPF and the specific ToS\/TC values are managed properly to avoid potential collision with other usage.","secretary_remarks":"This was postponed.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10360,"status":"postponed","reservation_date":"2022-03-28 16:56:17","uploaded":"2022-03-29 21:08:07","revisionof":"","revisedto":"S2-2203843","release":"Rel-17","crspec":"23.502","crspecversion":"17.4.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3431.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202189.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202190","title":"RRC state terminology alignment","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Replace all variants with one single variant as per RAN spec TS 38.331, these are RRC_IDLE, RRC_INACTIVE, RRC_CONNECTED","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10630,"status":"postponed","reservation_date":"2022-03-28 16:56:19","uploaded":"2022-03-29 21:08:07","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"17.4.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3594.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202190.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202191","title":"RRC state terminology alignment","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: When RRC states are described, use 'RRC_INACTIVE' to replace e.g., 'RRC Inactive', 'RRC-Inactive', use 'RRC_CONNECTED' to replace e.g., 'RRC Connected', 'RRC-Connected', use 'RRC_IDLE' to replace e.g. 'RRC IDLE' and 'RRC-IDLE'.","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10640,"status":"postponed","reservation_date":"2022-03-28 16:56:20","uploaded":"2022-03-29 21:08:07","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.502","crspecversion":"17.4.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3432.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202191.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202238","title":"Discussion paper on Mapped NSSAI handling.","source":"Apple","contact":"Robert Zaus","contact-id":85311,"tdoctype":"discussion","for":"Discussion","abstract":"Related to incoming LS on Mapped NSSAI from CT WG1 in S2-2201936","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10090,"status":"noted","reservation_date":"2022-03-28 18:49:15","uploaded":"2022-03-29 11:58:50","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202238.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202239","title":"[DRAFT] Reply LS on Mapped NSSAI","source":"Apple (UK) Limited","contact":"Robert Zaus","contact-id":85311,"tdoctype":"LS out","for":"Approval","abstract":"Proposed response to incoming LS on Mapped NSSAI from CT WG1","secretary_remarks":"Response to S2-2201936. 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-03-28 18:53:46","uploaded":"2022-03-29 11:58:50","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202239.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202240","title":"Correction of description of Mapped NSSAI handling","source":"Apple","contact":"Robert Zaus","contact-id":85311,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarifications are added that the VPLMN shall determine a mapped S-NSSAI value for each S-NSSAI value to be used in the VPLMN, and that all the mapped S-NSSAI values are to be signalled to the UE. Further, it is added that the NSSF or AMF checks whether the mapping from Requested NSSAI to Mapped NSSAI provided by the UE is correct, and that the NSSF or AMF performs a subscription check of the Requested NSSAI based on the Subscribed S-NSSAIs.","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-03-28 18:57:40","uploaded":"2022-03-29 11:58:50","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"17.4.0","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":3598.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202240.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202241","title":"Additional support for selecting UPF collocated with W-AGF","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify that the AMF provides the AGF information, if available in AMF, also when PDU Session ie established in 3GPP access. This allows the SMF to use it for UPF selection.","secretary_remarks":"r02 agreed. Revised to S2-2203025","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10650,"status":"revised","reservation_date":"2022-03-28 19:37:40","uploaded":"2022-03-29 21:10:21","revisionof":"","revisedto":"S2-2203025","release":"Rel-17","crspec":"23.316","crspecversion":"17.2.0","workitem":[{"winame":"5WWC"}],"crnumber":2065.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202241.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202242","title":"[DRAFT] Reply LS on ATSSS and Co-located AGF-UPF procedures","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Replies to incoming LS from BBF regarding selection of colocated AGF and UPF","secretary_remarks":"Response to S2-2202784. r00 agreed. Revised to S2-2203021","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10490,"status":"revised","reservation_date":"2022-03-28 19:37:41","uploaded":"2022-03-29 21:10:21","revisionof":"","revisedto":"S2-2203021","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5WWC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"BBF","Cc":"CableLabs","lsoriginalls":"BBF LIAISE-519","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202242.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202366","title":"[DRAFT] Reply LS on EPS fallback enhancements","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"This LS provides response regarding EPS fallback.","secretary_remarks":"Response to S2-2201951. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10320,"status":"noted","reservation_date":"2022-03-29 07:32:05","uploaded":"2022-03-29 12:54:06","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2","Cc":"CT WG1, SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202366.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202369","title":"[DRAFT] Reply LS on Mapped NSSAI","source":"QUALCOMM Europe Inc. - Italy","contact":"Stefano Faccin","contact-id":57487,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1. CC:","secretary_remarks":"Response to S2-2201936. 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-03-29 07:36:31","uploaded":"2022-03-29 15:55:17","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202369.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202375","title":"Discussion on Source Layer-2 ID of first PC5-S unicast message.","source":"CATT, LG Electronics, Deutsche Telekom","contact":"Qiang Deng","contact-id":74437,"tdoctype":"discussion","for":"Discussion","abstract":"This paper discussed the Source Layer-2 ID of the first PC5-S unicast message based on RAN WG2 LS (R2-2203691\/S2-2201945) and proposed answers accordingly.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10660,"status":"noted","reservation_date":"2022-03-29 07:41:03","uploaded":"2022-03-29 08:25:48","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.287","crspecversion":"","workitem":[{"winame":"eV2XARC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202375.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202376","title":"[DRAFT] Reply LS on how to receive the first PC5-S unicast message during PC5-S connection setup procedure","source":"CATT","contact":"Qiang Deng","contact-id":74437,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS to R2-2203691.","secretary_remarks":"Response to S2-2201945. r00 agreed. Revised to S2-2203024","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10370,"status":"revised","reservation_date":"2022-03-29 07:41:03","uploaded":"2022-03-29 08:25:48","revisionof":"","revisedto":"S2-2203024","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"eV2XARC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202376.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202378","title":"Discussion on the mapped S-NSSAI in VPLMN.","source":"Qualcomm Incorporated","contact":"Stefano Faccin","contact-id":57487,"tdoctype":"discussion","for":"Discussion","abstract":"This contribution discusses the LS from CT WG1.","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-03-29 07:45:45","uploaded":"2022-03-29 15:55:17","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202378.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202448","title":"[DRAFT] LS OUT on handling of packet filters when the supported number is exceeded; Response to S2-2201937","source":"Nokia, Nokia Shanghai Bell","contact":"Pallab Gupta","contact-id":87959,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG3. CC:","secretary_remarks":"Response to S2-2201937. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10690,"status":"postponed","reservation_date":"2022-03-29 08:46:54","uploaded":"2022-03-29 12:37:18","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202448.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202449","title":"Handling of number of supported Packet Filters for signalled QoS rules for the PDU Session with EPS IWK","source":"Nokia, Nokia Shanghai Bell","contact":"Pallab Gupta","contact-id":87959,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: If SMF has indicated that the PDU Session supports EPS interworking, the PCF shall ensure that the sum of the packet filters used by all PCC rules which trigger the generation of signalled QoS rules does not exceed the maximum number of packet filters for signalled QoS rules that is supported in EPS (i.e. 16).","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10740,"status":"postponed","reservation_date":"2022-03-29 08:46:54","uploaded":"2022-03-29 12:37:18","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.503","crspecversion":"17.4.0","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":713.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202449.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202450","title":"Handling of number of supported Packet Filters for signalled QoS rules for the PDU Session with EPS IWK","source":"Nokia, Nokia Shanghai Bell","contact":"Pallab Gupta","contact-id":87959,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: The SMF may indicate to the PCF that EPS IWK is possible for the PDU session","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10750,"status":"postponed","reservation_date":"2022-03-29 08:46:55","uploaded":"2022-03-29 12:37:18","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.502","crspecversion":"17.4.0","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":3444.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202450.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202451","title":"Handling of number of supported Packet Filters for signalled QoS rules for the PDU Session with EPS IWK","source":"Nokia, Nokia Shanghai Bell","contact":"Pallab Gupta","contact-id":87959,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clause 5.7.1.4 is updated to specify that when EPS IWK applies, the SMF shall ensure that the sum of the Packet Filters used by all signalled QoS rules for a PDU Session does not exceed 16.","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10760,"status":"postponed","reservation_date":"2022-03-29 08:46:56","uploaded":"2022-03-29 12:37:18","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"17.4.0","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":3608.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202451.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202576","title":"[DRAFT] Reply LS on Mapped NSSAI","source":"Lenovo, Motorola Mobility","contact":"Genadi Velev","contact-id":70944,"tdoctype":"LS out","for":"Approval","abstract":"This LS is a reply to incoming LS on Mapped NSSAI from CT WG1 (C1-222095).","secretary_remarks":"Response to S2-2201936. 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-03-29 10:12:38","uploaded":"2022-03-29 20:25:21","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202576.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202662","title":"[DRAFT] Reply LS on Mapped NSSAI","source":"ZTE","contact":"Jinguo Zhu","contact-id":32987,"tdoctype":"LS out","for":"Approval","abstract":"Response LS to S2-2201936","secretary_remarks":"Response to S2-2201936. 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-03-29 12:14:57","uploaded":"2022-03-29 14:07:37","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"eNA_Ph2"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202662.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202775","title":"Reply LS on mandatory SSC modes supported by UE","source":"CT WG1","contact":"Mikael Wass","contact-id":42217,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 thanks SA WG2 for the LS on mandatory SSC modes supported by UE. CT WG1 has discussed SSC mode related requirements in current specification under CT WG1 control, and concluded the following: - support of at least one SSC mode is mandated; - mandatory support for any specific SSC mode is not explicitly stated in CT WG1 stage 3 specification; - functional requirements indicate that SSC mode 1 is the only SSC mode that is mandated to be supported by all UEs. CT WG1 further notes the recent LS from SA WG2 (S2-2201274 \/ C1-221751) with attached CRs that update stage 2 such that SSC mode 1 is mandatory to support for UEs supporting PDU connectivity, whereas SSC modes 2 and 3 are optional. These requirements are not captured in current CT WG1 specification, but CT WG1 intends to address these with corresponding updates in a future meeting. Action: CT WG1 kindly requests SA WG2 to 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":10410,"status":"noted","reservation_date":"2022-03-29 15:34:29","uploaded":"2022-03-29 17:47:55","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG6","lsoriginalls":"C1-222033","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202775.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202780","title":"LS from CT WG4: Reply-LS on Deletion of ME support of SOR-CMCI indicator during Nudm_SDM_Get","source":"CT WG4","contact":"Varini Gupta","contact-id":83459,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 thanks CT WG1 for the Reply-LS in C4-221017 \/ C1-220559 on Deletion of 'ME support of SOR-CMCI' indicator during Nudm_SDM_Get. CT WG4 would like to provide the following comments on actions: ? CT WG1 kindly asks SA WG2 and CT WG4 to confirm if the solution agreed in C1-220558 is acceptable. [CT WG4] The solution is acceptable to CT WG4. ? CT WG1 kindly asks SA WG2 and CT WG4 to update the spec to allow the 'emergency registration' to be provided over the Nudm_UECM_Registration service operation, and make it mandatory for the AMF to provide the UDM with the 'initial registration' and the 'emergency registration'. [CT WG4] CT WG4 has agreed to attached CR (C4-220065) to reflect this change. Action: CT WG4 kindly requests CT WG1 and SA WG2 to take above responses into account.","secretary_remarks":"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-03-29 15:34:29","uploaded":"2022-03-29 17:47:55","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1, SA WG2","Cc":"","lsoriginalls":"C4-221079","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202780.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202781","title":"LS from CT WG4: Reply LS On User Consent Updating","source":"CT WG4","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"CT WG4 thanks RAN WG3 for their LS on User Consent Updating (R3-221210\/C4-221020). CT WG4 provides the answer to the following question: 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. CT WG4 Answer: Accordingly to stage 2, the AMF subscribes to the UDM SDM API to get notifications on any changes of the UE AM subscription data, including the changes on MDT user consent information which is part of the UE AM subscription data. The AMF can subsequently signal the updated MDT User Consent Information to the RAN when being notified by the UDM.","secretary_remarks":"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-03-29 15:34:29","uploaded":"2022-03-29 17:47:55","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"SA WG2, SA WG5, SA WG3","lsoriginalls":"C4-221413","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202781.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202783","title":"LS from BBF: 3GPP TS 29.244","source":"BBF","contact":"Lincoln Lavoie","contact-id":39231,"tdoctype":"LS in","for":"Information","abstract":"Dear colleagues, You may be aware that Broadband Forum Technical Report TR-459 (https:\/\/www.broadband-forum.org\/marketing\/download\/TR-459.pdf) has selected PFCP as the CUPS protocol for the DBNG State Control interface (SCi) and has been using it to program subscriber forwarding state and control packet redirection rules. We are in the process of defining Issue 2 of TR-459 and we need a PFCP procedure that shall be used by the UP function to report information to the CP function which is not related to a specific PFCP session. 3GPP TS 29.244 defines a 'PFCP Node Report Procedure' for this purpose and this is suitable to meet the TR-459 Issue 2 requirements. To make use of the PFCP Node Report Request, we examined the Information elements in PFCP Node Report Request {. . .} However, to support the new conditional BBF Node Report IE, we cannot use re-use any of the currently defined triggers in this mandatory IE. It seems we need an additional bit that indicates this is a custom (i.e. non-3GPP defined) Node report. If the non-3GPP bit is set, the device would look for a subsequent IE with the non-3GPP content. The first content of this IE would contain an Organization Unique Identifier (OUI) so there is no ambiguity as to which organization is responsible for defining the encoding, similar to other PFCP Information Elements that use OUI. BBF would kindly ask CT WG4 to consider the request in the above information and provide feedback on the proposal. If CT WG4 would like to discuss the issue further and cooperate on details, the BBF would be happy to do so. We look forward to our continued cooperation and fruitful exchange. Sincerely, 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":10470,"status":"noted","reservation_date":"2022-03-29 15:34:29","uploaded":"2022-03-29 17:47:55","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4, SA WG2, SA WG3","Cc":"","lsoriginalls":"LIAISE-507-02","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202783.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202784","title":"LS from BBF: ATSSS and Co-located AGF-UPF procedures","source":"BBF","contact":"Lincoln Lavoie","contact-id":39231,"tdoctype":"LS in","for":"Information","abstract":"Dear colleagues, During the course of our deliberations we have come to realize that there are some potential issues with the use of ATSSS with a supporting UPF that is collocated with a W-AGF. 1) In the scenario where a multi access 5G-RG is registered on both a 3GPP access and a WWC non-3GPP access it is not clear that the AMF will have wAGF identities information available to present to the selected SMF if an MA-PDU session is initiated on the 3GPP access. The only references to the availability of wAGF identities information is when it is included in the N2 UPLINK NAS TRANSPORT container for the PDU session establishment transactions. We believe that it is essential\/beneficial\/required to ensure that a UPF collocated with AGF can be selected also in this scenario. One option to achieve this would be that the AMF would need to retain wAGF identities information obtained during the registration process in wireline access such that it is available to the selected SMF irrespective of the access used for MA-PDU session establishment. 2) In the scenario where a multi-access equipped 5G-RG initially is registered on a 3GPP access and the WWC non-3GPP access is unavailable, wAGF identities information will not be available and therefore selection of a collocated AGF-UPF would appear to be impossible. When the WWC non-3GPP access returned to availability one method of redress would be to force any MA-PDU capable PDU sessions to be torn down and re-established to ensure proper UPF selection. We would note that one potential generalized solution would be the retention of the most recent wAGF identifies information in some form of persistent storage such that it was available for UPF selection in any of the cases above. This would address the majority of cases for co-located UPF selection and preserve session continuity, but would not completely eliminate the requirement for procedures to force UPF reselection. Your feedback on the scenarios and options for resolution outlined above would be appreciated. On the assumption that a solution is forthcoming, can you please advise as to a potential timeline for publication. We look forward to continuing our fruitful relationship. Thanks, Lincoln Lavoie Broadband Forum Technical Committee Chair","secretary_remarks":"Response drafted in S2-2202242. Final response in S2-2203021","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10480,"status":"replied to","reservation_date":"2022-03-29 15:34:29","uploaded":"2022-03-29 17:47:55","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CableLabs","lsoriginalls":"LIAISE-519","lsreply":"S2-2203021, S2-2203021","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202784.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202789","title":"LS from RAN WG3: Reply LS on paging subgrouping and PEI","source":"RAN WG3","contact":"Jiajun Chen","contact-id":84462,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 thanks RAN WG2 for LS on the paging subgrouping and PEI. In order to support enhanced UE power saving in Rel17, RAN WG3 has agreed to introduce PEIPS Assistance Information into PAGING message and Core Network Assistance Information for RRC INACTIVE IE over NGAP, and introduce PEIPS Assistance Information into Xn\/F1 paging message. The UEID based subgrouping support information and last used cell information are also added into F1AP paging message.The corresponding stage2 and stage3 work in RAN WG3 are completed.","secretary_remarks":"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-03-29 15:34:29","uploaded":"2022-03-29 17:47:55","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2","Cc":"SA WG2, CT WG1, RAN WG1","lsoriginalls":"R3-222874","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202789.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202793","title":"LS from SA WG3: Reply LS on User Consent Updating","source":"SA WG3","contact":"Wei Lu","contact-id":90295,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 would like to thank RAN WG3 for their LS R3-221210 on user consent updating. SA WG3 is made aware of the RAN WG3 agreed working assumption of optionally including the Management Based MDT PLMN List IE in the NG: UE CONTEXT MODIFICATION REQUEST message, with which a change of user consent information in 5GC can be updated to the NG-RAN. SA WG3 would like to provide the following answer regarding the specific question asked by RAN WG3: SA WG3 believes that the update of user consent information shall be signalled to the RAN as soon as the update occurs.","secretary_remarks":"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-03-29 15:34:29","uploaded":"2022-03-29 17:47:55","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"SA WG2, SA WG5, CT WG4","lsoriginalls":"S3-220474","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202793.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202798","title":"LS on Alignment concerning 5G RG requirements and its remote management","source":"TSG SA","contact":"Kurt Bischinger","contact-id":26063,"tdoctype":"LS in","for":"Information","abstract":"TSG SA thanks BBF for their LS on Alignment concerning 5G RG requirements and its remote management. SA WG1 has completed their work on PIRates by end of last year and respective requirements were included in TS 22.261. The latest version of the specification can be found here: https:\/\/portal.3gpp.org\/desktopmodules\/Specifications\/SpecificationDetails.aspx?specificationId=3107 Please refer to clause 6.38 of TS 22.261 for the relevant requirements. SA WG1 has identified requirements for integration of mobile services in a Customer Premises Network (CPN) including the Residential Gateway (eRG). SA WG2 has started their architecture work and it is up to them to determine which requirements, in particular for operator policies and control, might impact the management of the eRG. TSG SA fully acknowledges the responsibility of BBF for requirements for Residential Gateway related to Customer Premises Network and for remote management of the Residential Gateway and kindly asks you to review the stage 1 requirements. Please provide feedback on specific requirements if BBF believes SA WG1 has gone beyond specifying service requirements needed for converged mobile communication in a CPN, and where SA WG1 can refer to related BBF specifications with service requirements. TSG SA envisages that BBF and SA WG2 coordinate and take up the further work on Residential Gateways very much in the same way like BBF and SA WG2 have collaborated in the past. TSG SA is looking forward to continuing the fruitful cooperation with BBF.","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-03-29 15:34:29","uploaded":"2022-03-29 17:47:55","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"BBF","Cc":"SA WG2, SA WG1","lsoriginalls":"SP-220347","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202798.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202823","title":"Clarification on the TFT exceeding 16 for 5GS-EPS interworking","source":"ZTE","contact":"Zhendong Li","contact-id":38521,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: During PDU Session establishment and GBR QoS Flow establishment, the SMF+PGW-C locally determine what packet filters will be part of the TFT allocation. During EBI allocation, the SMF+PGW-C may remove packet filters which has been sent to UE to gurantee the total packet filters number which will be sent to UE will not exceeds the number supported in EPS for this PDU session.","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10770,"status":"postponed","reservation_date":"2022-03-29 16:03:10","uploaded":"2022-03-29 16:57:40","revisionof":"","revisedto":"S2-2203822","release":"Rel-16","crspec":"23.502","crspecversion":"16.12.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI16"}],"crnumber":3455.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202823.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202824","title":"Clarification on the TFT exceeding 16 for 5GS-EPS interworking","source":"ZTE","contact":"Zhendong Li","contact-id":38521,"tdoctype":"CR","for":"Approval","abstract":"Rel-17 mirror CR: Summary of change: During PDU Session establishment and GBR QoS Flow establishment, the SMF+PGW-C locally determine what packet filters will be part of the TFT allocation. During EBI allocation, the SMF+PGW-C may remove packet filters which has been sent to UE to gurantee the total packet filters number which will be sent to UE will not exceeds the number supported in EPS for this PDU session.","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10780,"status":"postponed","reservation_date":"2022-03-29 16:03:11","uploaded":"2022-03-29 16:57:40","revisionof":"","revisedto":"S2-2203823","release":"Rel-17","crspec":"23.502","crspecversion":"17.4.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI16"}],"crnumber":3456.0,"crrevision":"","crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202824.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202825","title":"[DRAFT] Reply LS On handling of packet filters when the supported number is exceeded","source":"ZTE","contact":"Zhendong Li","contact-id":38521,"tdoctype":"LS out","for":"Approval","abstract":"Proposes a Reply LS On handling of packet filters when the supported number is exceeded","secretary_remarks":"Response to S2-2201937. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10700,"status":"postponed","reservation_date":"2022-03-29 16:03:12","uploaded":"2022-03-29 16:57:40","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202825.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2202876","title":"[DRAFT] Reply LS on Mapped NSSAI","source":"MediaTek Inc.","contact":"Guillaume Sebire","contact-id":45073,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1. CC:","secretary_remarks":"Response to S2-2201936. 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-03-29 17:01:20","uploaded":"2022-03-29 17:31:35","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5GProtoc17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2202876.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203017","title":"Reply LS on EAP-5G change","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Replies to incoming LS from BBF regarding EAP-5G","secretary_remarks":"Revision of S2-2201984r00. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10800,"status":"approved","reservation_date":"2022-04-13 09:51:45","uploaded":"2022-04-13 15:41:12","revisionof":"S2-2201984","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5WWC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2201938","lsto":"BBF","Cc":"CT WG4, CT WG1, CableLabs","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203017.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203021","title":"[DRAFT] Reply LS on ATSSS and Co-located AGF-UPF procedures","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Replies to incoming LS from BBF regarding selection of colocated AGF and UPF","secretary_remarks":"Revision of S2-2202242r00. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10500,"status":"approved","reservation_date":"2022-04-13 09:51:45","uploaded":"2022-04-13 15:41:12","revisionof":"S2-2202242","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5WWC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2202784","lsto":"BBF","Cc":"CableLabs","lsoriginalls":"BBF LIAISE-519","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203021.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203022","title":"Reply LS on Mapped NSSAI","source":"SA WG2","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1. Attachments: TS 23.501 CR 3583","secretary_remarks":"Revision of S2-2202046r07. Approved. Incorrect attachment provided. Revised to S2-2203151.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10150,"status":"revised","reservation_date":"2022-04-13 09:51:45","uploaded":"2022-04-13 15:41:12","revisionof":"S2-2202046","revisedto":"S2-2203151","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5GProtoc17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203022.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203023","title":"Reply LS to GSMA NRG on ARP override VoLTE roaming","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"TThis paper replies GSMA on ARP override and GBR downgrade","secretary_remarks":"Revision of S2-2202185r01. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10270,"status":"approved","reservation_date":"2022-04-13 09:51:45","uploaded":"2022-04-13 15:41:12","revisionof":"S2-2202185","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2201940","lsto":"GSMA","Cc":"CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203023.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203024","title":"[DRAFT] Reply LS on how to receive the first PC5-S unicast message during PC5-S connection setup procedure","source":"CATT","contact":"Qiang Deng","contact-id":74437,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS to R2-2203691.","secretary_remarks":"Revision of S2-2202376r00. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10380,"status":"approved","reservation_date":"2022-04-13 09:51:45","uploaded":"2022-04-13 15:41:12","revisionof":"S2-2202376","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"eV2XARC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2201945","lsto":"RAN WG2","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203024.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203025","title":"Additional support for selecting UPF collocated with W-AGF","source":"Ericsson, Nokia, Nokia Shanghai Bell","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify that the AMF provides the W-AGF information, if available in AMF, also when PDU Session ie established in 3GPP access. This allows the SMF to use it for UPF selection.","secretary_remarks":"Revision of S2-2202241r02. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10660,"status":"agreed","reservation_date":"2022-04-13 09:51:45","uploaded":"2022-04-14 09:01:19","revisionof":"S2-2202241","revisedto":"","release":"Rel-17","crspec":"23.316","crspecversion":"17.2.0","workitem":[{"winame":"5WWC"},{"winame":" TEI17"}],"crnumber":2065.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-220411","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203025.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203026","title":"Requirement for signalling separate IMEI for each network subscription","source":"Qualcomm Incorporated","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Introduce requirement that the UE shall use a separate PEI for each network subscription when it registers to the network","secretary_remarks":"Revision of S2-2201996r01. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10540,"status":"agreed","reservation_date":"2022-04-13 09:51:46","uploaded":"2022-04-14 09:01:19","revisionof":"S2-2201996","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.12.0","workitem":[{"winame":"Vertical_LAN"}],"crnumber":3496.0,"crrevision":2.0,"crcategory":"F","tsg_crp":"SP-220390","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203026.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203027","title":"Handling of ARP for IMS voice service in home routed roaming","source":"Ericsson, Deutsche Telekom","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Allow ARP override for IMS voice service at home routed roaming.","secretary_remarks":"Revision of S2-2202186r06. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10600,"status":"agreed","reservation_date":"2022-04-13 09:51:48","uploaded":"2022-04-14 09:01:19","revisionof":"S2-2202186","revisedto":"","release":"Rel-17","crspec":"23.401","crspecversion":"17.4.0","workitem":[{"winame":"TEI17"}],"crnumber":3695.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-220411","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203027.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203028","title":"Handling of ARP for IMS voice service in home routed roaming","source":"Ericsson, Deutsche Telekom","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Allow ARP override for IMS voice service in home routed roaming.","secretary_remarks":"Revision of S2-2202187r07. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10620,"status":"agreed","reservation_date":"2022-04-13 09:51:49","uploaded":"2022-04-14 09:01:19","revisionof":"S2-2202187","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"17.4.0","workitem":[{"winame":"TEI17"}],"crnumber":3593.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-220411","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203028.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203029","title":"[DRAFT] LS on LS on 5GC Support of DHCP signaling for RG","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"[draft] LS on LS on 5GC Support of DHCP signaling for RG; Response to S2-2009340","secretary_remarks":"Revision of S2-2202170r01. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10830,"status":"approved","reservation_date":"2022-04-13 09:51:50","uploaded":"2022-04-13 15:41:12","revisionof":"S2-2202170","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5WWC"},{"winame":" TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2201939","lsto":"BBF","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203029.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203030","title":"Alignment to BBF LS 512 (Frame route, BBF references)","source":"Nokia, Nokia Shanghai Bell, Ericsson","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Update the BBF References, keeping only one reference to TR-456 SMF can select a UPF supporting Framed Routes.","secretary_remarks":"Revision of S2-2202171r02. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10560,"status":"agreed","reservation_date":"2022-04-13 09:51:50","uploaded":"2022-04-14 09:01:19","revisionof":"S2-2202171","revisedto":"","release":"Rel-17","crspec":"23.316","crspecversion":"17.2.0","workitem":[{"winame":"5WWC"},{"winame":" TEI17"}],"crnumber":2064.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-220411","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203030.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203031","title":"Alignment to BBF LS 512 (Frame route, BBF references)","source":"Nokia, Nokia Shanghai Bell, Ericsson","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Update the BBF References SMF can select a UPF supporting Framed Routes.","secretary_remarks":"Revision of S2-2202172r02. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10580,"status":"agreed","reservation_date":"2022-04-13 09:51:51","uploaded":"2022-04-14 09:01:19","revisionof":"S2-2202172","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"17.4.0","workitem":[{"winame":"5WWC"},{"winame":" TEI17"}],"crnumber":3591.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-220411","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203031.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203151","title":"Reply LS on Mapped NSSAI","source":"SA WG2","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1. Attachments: TS 23.501 CR 3583","secretary_remarks":"Revision of S2-2203022","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10160,"status":"approved","reservation_date":"2022-04-13 09:52:32","uploaded":"2022-04-21 05:11:16","revisionof":"S2-2203022","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5GProtoc17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2201936","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203151.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2203590","title":"Reply LS on EPS fallback enhancements","source":"Qualcomm","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS out","for":"Approval","abstract":"Replies to LS R2-2204236","secretary_remarks":"Revision of S2-2201997r09. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10310,"status":"approved","reservation_date":"2022-04-13 09:55:39","uploaded":"2022-04-13 15:41:16","revisionof":"S2-2201997","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2201951","lsto":"RAN WG2","Cc":"CT WG1, SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_150E_Electronic_2022-04\/Docs\/S2-2203590.zip","group":"S2","meeting":"S2-150-e","year":2022,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]