[{"name":"C4-240075","title":"Elaborated LS reply to S3-234350 on Roaming Hub requirements as applicable to the Modified PRINS solution","source":"GSMA 5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"GSMA NG 5GMRR kindly requests 3GPP SA3:\n1.\tTo take the above GSMA definition for Roaming Hub into consideration as part of their work in TS 33.501.\n2.\tOn the topic of Modified PRINS as defined by 3GPP TS 33.501 for Roaming Hub by GSMA NG 5GMRR, we would like to highlight 3GPP SA3 to support the following requirements:\na.\tThe RH shall have the ability to intervene in roaming data sessions at any time, in order to limit roaming data usage by limiting throughput and\/or stopping ongoing data sessions as agreed with the client HPMN. This ability to intervene requires anchoring the media in this intermediary.\nb.\tAll N32 messages between client MNOs are transferred via the RH. This shall include the ability for the RH to prevent the establishment of, and the termination of N32-c and N32-f connections, for example if this is required due to contractual reasons","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":750,"status":"noted","reservation_date":"2024-01-02 07:36:23","uploaded":"2024-02-09 13:33:14","revisionof":"C4-235395","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA3","Cc":"SA, SA1, CT, CT4","lsoriginalls":"5GMRR Doc 45_13r7","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240075.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240076","title":"Elaborated LS reply to S3-234350 on IPX Service Hub requirements as applicable to the Modified PRINS solution","source":"GSMA 5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"GSMA NG 5GMRR would like to request 3GPP SA3:\n\n3.\tInclude definitions for IPX Service Hub and IPX Provider into consideration as part of their work on TS 33.501.\n4.\tOn the topic of Modified PRINS as defined by 3GPP TS 33.501 for IPX Service Hub by GSMA NG 5GMRR, we would like to highlight 3GPP SA3 to support the following requirements:\na.\tThe IPX Service Hub shall have the ability to intervene in roaming data sessions at any time, in order to limit roaming data usage by limiting throughput and\/or stopping ongoing data sessions as agreed with the client HPMN. This ability to intervene requires anchoring the media in this intermediary.\nb.\tFor the purposes of scalability and simplification, and without undermining security objectives, the IPX Service Hub shall be able to aggregate N32 signalling traffic and use common identities like FQDN and IP addresses.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":760,"status":"noted","reservation_date":"2024-01-02 07:36:44","uploaded":"2024-02-09 13:33:14","revisionof":"C4-235396","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA3","Cc":"SA, SA1, SA2, CT, CT4","lsoriginalls":"5GMRR Doc 45_14r7","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240076.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240077","title":"LS-Reply on N32 connection establishment for bilateral TLS","source":"SA3","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"SA3 has studied the detailed description for N32 connection establishment for bilateral TLS and provides a list of comments in S3-235112 as attached.\nSA3 kindly asks CT4 to check, if any action needs to be taken in 3GPP or whether further comments need to be provided to GSMA. \nSA3 kindly asks 5GMRR to align with 3GPP specification 29.573.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":770,"status":"noted","reservation_date":"2024-01-02 07:37:13","uploaded":"2024-02-09 13:33:14","revisionof":"C4-235399","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"Roaming5G"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA NG 5GMRR","Cc":"CT4","lsoriginalls":"S3-235068","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240077.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240095","title":"Reply LS Regarding Device Connection Efficiency Requirements for UEs","source":"CT WG1","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"CT1 thanks GSMA Terminal Steering Group (TSG) for the liaison statement and for asking guidance on the variety of UE actions upon receiving LTE and 5G network session management reject causes. \n\nCT1 discussed the issues mentioned on:\n-\tnetwork congestion resulting from receiving the reject cause values (#29, #26 and #38), due to UEs that repeatedly re-attempt session management procedures.\n-\tthe issue of UEs never re-attempt session management procedures, needing to switch OFF\/ON to gain services again.\n\nCT1 would like to inform GSMA that:\n-\tEPS \u2013 ESM back-off timer was introduced in Re-11 and Rel-12. Thus, UEs with software version prior to these releases do not support the ESM back-off timer.\n-\t5GS -5GSM back-off timer was introduced in Rel-15 and further enhancements were added in Rel-16. Thus, 5G UEs compliant to Rel-15 and onward releases will support the 5GSM back-off timer.\n-\tBack-off timer setting is specified in NAS specifications (TS 24.301 and TS 24.501), where:\n-\tIf the network sends a back-off timer then the UE shall respect the time indicated by the network.\n-\tIf the network does not send back-off timer then there are several options defined in NAS specification. Some of these options may allow UE a variety of implementations.\n-\tThe UE behaviour may depend on the combination of the mobility management and session management cause codes.\n-\tIn addition, CT4 has introduced recommendations for overload control mechanism for LTE and 5G to help mitigate the overload before it becomes of high severity. These recommendations are available in (TR29.809 - Diameter overload, TR 29.810 -Diameter load, TS 29.274 - clause 12.3, and TS 29.500 load\/overload support over SBIs).\n\nCT1 kindly requests additional details and the description of the test environment including, e.g.:\na)\t the standards release of the UE\nb)\twhen the ESM back-off timer is used, the values to be set for it\nc)\tstandalone PDU session request or piggy-backed with the attach procedure\nd)\tany mobility management mapping with session management cause codes\ne)\tand also the reaction of the UEs that are not compliant with the standards in re-attempting session management procedures\nf)\twhere the UE needs to be switched OFF\/ON to gain services again\nCT1 will then investigate each case and try to find solutions as applicable.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":950,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA Terminal Steering Group - TSG","Cc":"CT4","lsoriginalls":"C1-239667","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240095.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240096","title":"LS on defining new GTP-U Extension Header for PDU Set related information","source":"RAN WG3","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"RAN3 discussed and agreed to define a new GTP-U Extension Header \u201cPDU Set Information User Plane protocol\u201d in TS 38.415 to transfer the PDU Set Information and End of Data Burst Indication in the user plane protocol. \nRAN3 kindly asks CT4 to define a new type of Extension Header \u201cPDU Set Information User Plane protocol\u201d in their specifications.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":960,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"NR_XR_enh-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4","Cc":"SA2","lsoriginalls":"R3-237845","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240096.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240097","title":"LS Response on EAC Mode Subscription Optimization","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA2 would like to thanks CT4 for their LS on EAC Mode Subscription Optimization. SA2 discussed the questions and provides the answers as follows:\n\nQ1: Whether the AMF should be allowed to create and\/or modify the EAC mode subscription independently, instead of always relying on a service operation for UE NSAC?\n\nSA2 Answer: No. SA2 discussed this issue and concluded that only implicit EAC mode subscription, i.e. the existing mechanism, is supported in Rel-18. \n\nQ2: Will it be considered to have EAC Mode per access type, when per access type NSAC is configured in the NSACF?\n\nSA2 Answer: SA2 does not see any reason to define EAC Mode per access type.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":970,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"eNS_Ph2"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"3GPP CT4","Cc":"","lsoriginalls":"S2-2313274","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240097.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240099","title":"Reply LS on SNPN Identifier based N3IWF FQDN (Tdoc","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA2 thanks CT4 for the Reply LS on SNPN Identifier based N3IWF FQDN.\nAs per the agreed TS 23.003 CR in CT4\u2019s reply, SA2 has aligned the corresponding text in TS 23.501.\n\nThe Agreed TS 23.501 CR (S2-2313717) is attached.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":990,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"eNPN_Ph2"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4","Cc":"","lsoriginalls":"S2-2313718","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240099.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240100","title":"LS regarding the endorsed CRs that were part of S2-2311886","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA2 provides the following updates to CT4 for their LS on Support of TSN enabled Transport Network (C4-233170).\nThis LS is a short update to the S2-2311886\n\nSA2 has approved the attached Stage 2 CRs based on the answers provided in S2-2311886. Please note that SA2 has not described the TL-Container in PDU Session Release as there is no Stage 2 parameter (i.e., listed in Table M.2-1) that is required during the release. SA2 describes the aspect as the SMF\/CUC shall initiate to the CN-TL\/AN-TL the deletion of TN stream configurations.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1000,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"TRS_URLLC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4","Cc":"RAN3","lsoriginalls":"S2-2313734","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240100.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240101","title":"Further reply LS on NSACF Role and NSAC Service Area","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"Q3. It is not clear to CT4, whether a NSAC service area may be identified by TAI(s) or should be instead identified by a new NSAC service area identifier that may take the form of an operator defined string?\nSA2 reply: \nThe NSAC Service Area is a unique identifier assigned in a PLMN or SNPN. SA2 has agreed the attached CRs starting from Rel-17.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1010,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"eNS_Ph2"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4","Cc":"","lsoriginalls":"S2-2313821","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240101.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240102","title":"Reply LS on Clarification on Correlation ID in UP Notification","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA2 thanks CT WG4 for the LS on Clarification on Correlation ID in UP Notification. SA2 has discussed the LS and agrees the attached CR to address the concern in the LS.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1020,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"5G_eLCS_Ph3"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"","lsoriginalls":"S2-2313887","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240102.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240103","title":"LS to RAN2\/CT WGs on RAN&CT alignment issues","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"1. Overall Description:\nSA2 has sent a LS (S2-2311896) to RAN2 about whether some certain messages are transferred as SLPP messages or non-SLPP messages between LMF & Target UE \/ SL Reference UE \/ Located UE, between SL Positioning Server UE & Target UE \/ SL Reference UE \/ Located UE, between Target UE & SL Reference UE\/ Located UE and between SL Positioning Client UE & Target UE \/ SL Reference UE \/ Located UE.\nBased on some further discussions, SA2 would make a correction to SA2 Agreement 1 of S2-2311896 as below:\n-\tItem 2 will be developed by CT WGs as the LCS SS message, and CT WGs will decide how to design the message.\nAdditionally, SA2 has reached the following agreements:\n-\tSA2 Agreement 3: RSPP includes SLPP messages and Supplementary Service messages transferring between UE and LMF. Whether LCS Supplementary Service messages are reused or new Supplementary Service messages will be developed is determined by CT WGs. RSPP also includes SLPP messages and Supplementary RSPP signalling messages transferring over SR5. Supplementary RSPP signalling is assumed to be developed by CT WGs.\n-\tSA2 Agreement 4: For interactions between SL Positioning Server UE and Target UE \/ SL Reference UE \/ Located UE:\no\tSLPP is used between SL Positioning Server UE and UE1 for transferring capability, assistance data and Location estimate request\/response of UE1.\no\tSupplementary RSPP signalling is used between SL Positioning Server UE and UE1 for transferring capability, assistance data, Location info of UE2\/\u2026\/Uen, Application ID of UE2\/\u2026\/Uen, Ranging\/SL Positioning Service Request and any other information. \nO\tSLPP is used between UE1 and UE2\/\u2026\/Uen for transferring capability, assistance data and Location estimate request\/response of UE2\/\u2026\/Uen. \nO\tSupplementary RSPP signalling is used between UE1 and UE2\/\u2026\/Uen for transferring any information other than capability, assistance data and Location estimate request\/response of UE2\/\u2026\/Uen, e.g. absolute location of Located UE.\nO\tThere is no direct session between SL Positioning Server UE and UE2\/\u2026\/Uen via UE1.\n-\tSA2 Agreement 5: Message from Target UE to Located UE to request Located UE\u2019s absolute location, i.e. step 17 of 6.20.1 in TS 23.273 (CR 0416 of TS 23.273) is transferred as  Supplementary RSPP signalling message over SR5 \n-\tSA2 Agreement 6: Information of UE2\/\u2026\/Uen in the SL-MO-LR procedure documented in clause 6.20.1 of TS 23.273 is not defined as information of SLPP messages, and they will be defined as the Supplementary Service messages. \nThe detail message flows can be found from the attachments.\n***","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1030,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"Ranging_SL"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN2, CT1, CT4","Cc":"RAN3, SA3","lsoriginalls":"S2-2313889","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240103.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240104","title":"Reply LS on Proposed method for AMF discovery and subscription by the TSCTSF","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA2 thanks CT4 for their Reply LS on Proposed method for AMF discovery and subscription by the TSCTSF. Based on the CT4 suggestion in the LS, SA2 updated impacted clauses in both TS 23.501 and TS 23.502 accordingly.\nPlease note that SA2 has no consensus to adopt CT4\u2019s suggestion that \u201cthe Namf_EventExposure Subscribe request could support an optional parameter indicating the AMF to not propagate the group subscription to any target AMF during inter AMF mobility of group members\u201d.\nPlease see the attached CRs agreed by SA2 for details.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1040,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"TRS_URLLC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4","Cc":"","lsoriginalls":"S2-2313901","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240104.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240107","title":"Reply LS on RedCap UE MBS Broadcast reception","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"SA2 thanks RAN2 for the feedback. RAN2 has replied to SA2\u00b4s question 1:\nAn indication that an MBS broadcast session is intended to be received by both non-RedCap UE and RedCap UE may assist the gNB to decide when to transmit the session on both default and RedCap CFR and avoid waste of resources when this is not needed.\nSA2 would like to inform that it agreed the attached CR against TS 23.247 to reflect that reply.\nSA2 understands that for an MBS session intended for both RedCap and non-RedCap UEs separate radio resources may be allocated by RAN nodes for RedCap and non-RedCap UEs.\nIt is, however, unclear whether a single MBS Frequency Selection Area (FSA) ID can apply to RedCap UEs and non-RedCap UEs in the same MBS session. If it is not the case, whether it is feasible to adopt different MBS FSA IDs for RedCap and non-RedCap UEs.\n\nSA2 would thus like to ask RAN2 to answer the following related questions:\nQ1: SA2 would like to ask RAN2 to confirm the feasibility of having the same MBS FSA ID for the RedCap UEs and non-RedCap UEs in the same MBS session .\nQ2: If the answer to Q1 is no, could RedCap UEs and non-RedCap UEs in the same MBS session use separate MBS FSA ID(s)?\n\nSA2 would thus like to ask RAN3 to answer the following related question:\nQ3: If the answer to Q1 is no, and RedCap UEs and non-RedCap UEs in the same MBS session use separate MBS FSA ID(s), is there a need for CN to indicate to NG-RAN which FSA ID is aimed for RedCap UEs and which for non-RedCap UEs?","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1070,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"TEI18"},{"winame":" 5MBS_Ph2"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN2, RAN3","Cc":"CT3, CT4","lsoriginalls":"S2-2401506","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240107.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240108","title":"Reply LS on Rel-18 RedCap enhancements to address remaining ENs in TS 23.502","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"SA2 thanks RAN3 for the LS (R3-234725\/S2-2400004) on Rel-18 RedCap enhancements to address remaining ENs in TS 23.502.\n\n1.\tRAN3 would like to further inform SA2 that RAN3 agreed to rename the NGAP \u201cDL data notification\u201d message to \u201cRAN paging request\u201d message. RAN3 also agreed to include the \u2018DL signalling indication\u2019 in the \u201cRAN paging request\u201d message to differentiate DL signalling and DL data. \n\nAnswer 1: SA2 thanks RAN3 for the information and SA2 has approved the related CR to correct our specs accordingly. \n\n2.\tIn addition, RAN3 would like to inquire whether there is need to include the \u2018eRedCap indication\u2019 in the NGAP INITIAL UE MESSAGE message, \tto enable possible charging and policy control and differentiation of eRedCap devices, as was done in the past releases for Rel-17 RedCap UEs.\n\nAnswer 2: \n\nSA2 considers it useful to include an eREDCAP indication the NGAP INITIAL UE MESSAGE for use for e.g. subscription based access restrictions (for which SA2 has approved the attached CRs), etc.\n\nSA2 understands that the access stratum can differentiate the different types of UEs, i.e., RedCap vs. eRedCap and the UE radio capabilities are independently defined for RedCap UEs and eRedCap UEs.\n\nAs the radio capabilities are independently defined for a RedCap UE and an eRedCap UE the NAS Mobility Registration Update with UE Radio Capability Update as described in TS 23.501 clause. 5.4.4.1, would be triggered if a change occurred.\n\nSA2 would like to understand whether it is possible that a UE can have both REDCAP and eREDCAP capabilities and can change from a REDCAP UE to an eREDCAP UE (and vice versa)? \n\nIf the UE can change from a REDCAP UE to an eREDCAP UE (and vice versa), what is the expected behaviour of a UE with regards to REDCAP\/eREDCAP indication stated above in access stratum and provided during the RRC connection establishment procedure?","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1080,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"NR_redcap_enh-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN3, RAN2","Cc":"CT4","lsoriginalls":"S2-2401530","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240108.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240109","title":"Reply LS on Clarification on the AR media specification","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA2 would like to thank CT4 for the LS on Clarification on the AR media specification (C4-235475).\n\nSA2 has discussed the two questions indicated by CT4:\nQ1:\tWhat kind of information is included in the media processing specification for the AR media?\n\nQ3:\tDoes SA2 plan to update TS 23.228 with the media processing specification for the AR media as indicated in the above NOTE4 based on the input from the SA4?\n\nSA2 would like to provide the following feedback:\n\nAnswer to Q1 and Q3:\tSA2 has no plan to update the definition of media processing specification beyond what has been defined in Annex AA 2.5 of TS 23.228. SA2 will decide whether and how to update its specifications depending on SA4 plans.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1090,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"NG_RTC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4","Cc":"SA4","lsoriginalls":"S2-2401536","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240109.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240110","title":"LS reply on introduction of RAT-Dependent integrity","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"SA2 thanks RAN2 for their LS on introduction of RAT-Dependent integrity. To support RAN2 conclusion on RAT-Dependent integrity, SA2 agreed the CR in the attachment.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1110,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"5G_eLCS_Ph3"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN2","Cc":"CT4, RAN1","lsoriginalls":"S2-2401589","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240110.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240111","title":"Response to \u201cReply LS on the service requirement of restricting satellite access RAT type\u201d","source":"SA WG2","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"SA2 thanks SA1 and CT1 for being included in their LS exchange (C1-236567=S2-2310100 and the SA1 reply in S1-233296=S2-2400068) and SA2 notes SA1\u2019s reply on the existing generic SA1 requirements:\nSA1 has no explicit requirement to restrict the usage of satellite access in a PLMN. However, more generic requirements exist (in clauses 6.3.2 and 6.19 of TS 22.261, and clause 7.1 of TS 22.011 since Rel-15) that allow a network operator to restrict usage of specific access technology combinations within a PLMN.\nWe checked our specifications and realised that some inter-system mobility scenarios had been omitted that meant that restrictions for satellite access would not work correctly. \nAs a consequence, we have agreed the (attached) Rel 17 CR 5300 to TS 23.501 in order to support mobility restrictions from connected mode terrestrial NG-RAN to satellite access using EPC. \nSA2 expects that there are similar issues for mobility from connected mode terrestrial E-UTRA to 5GC based satellite access, however, SA2 has not prepared any CR to TS 23.401 because the mobility restrictions description in section 4.3.5.7 of TS 23.401 is (like the SA1 requirements) generic and already covers this situation.\nSA2 understands that CT4 specifications have recently been aligned, but SA2 anticipates that some updates to RAN3 specifications might be needed to meet the SA1 requirements and this SA2 CR.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1120,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"IoT_SAT_ARCH_EPS"},{"winame":" 5GSAT_ARCH"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN3","Cc":"CT1, CT4, SA1, RAN2","lsoriginalls":"S2-2401650","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240111.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240112","title":"LS-Reply on N32 connection establishment for bilateral TLS","source":"SA WG3","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1130,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"Roaming5G"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA NG 5GMRR","Cc":"3GPP CT WG4","lsoriginalls":"S3-235068","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240112.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240113","title":"LS on PDU Set marking configuration within the Policy APIs","source":"SA WG4","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA4 has completed the stage-2 work on the Real-Time media Communication (RTC) architecture (TS 26.506) and is currently working on the stage-3 APIs (TS 26.113). When defining the policy related API, SA4 is considering to define the PDU Set marking configuration inside the data model of the PolicyTemplate resource to be specified in TS 26.510. \nIn the case that the AS provides the PDU set information via the header extension of PDU set marking for RTP or SRTP, the PDU Set marking configuration contains the description of PDU Set configuration for the session, defined in Table 1. Note that this information is acquired by the Media AF (e.g. from the Media Session Handler in the UE) and is expected to be passed to the UPF through the PCF\/NEF as part of the request for a specific policy treatment to a particular PDU Set data flow. \n...\nSA4 would like to ask CT3\/CT4 to take the above information into account as part of the protocol description and to provide a response, particularly whether Policy APIs\/N4 rules are able to accommodate relaying the proposed PDU Set marking configuration parameters to the UPF via PCF\/SMF.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1140,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"iRTCW"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"3GPP CT3, 3GPP CT4","Cc":"","lsoriginalls":"S4-240001","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240113.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240114","title":"Reply LS on the clarification on the AR media specification","source":"SA WG4","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA4 thanks CT4 for their LS on Clarification on the AR media specification (C4-235475).\nSA4 provides the answer to the following question:\nQ1: What kind of information is included in the media processing specification for the AR media?\nSA4 Answer: From SA4 perspective, the AR media specification is an application-specific string that indicate how MF should assist the AR media rendering function. SA4 assumes that corresponding application media processing exists in both the device and AR media rendering function, and exactly how this is indicated does not need to be standardized.\n\nQ2: Is the media processing specification for the AR media already specified by SA4?\nA.\tIf the answer on Q2 is yes, CT4 kindly asks SA4 to provide TS identity.\nB.\tIf the answer on Q2 is no, does SA4 plan to specify the media processing specification for the AR media and in which time frame?\nSA4 Answer: This AR media processing specification is application specific, it should be self-defined at application level between the MF and the AR AS.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1100,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4","Cc":"SA2","lsoriginalls":"S4-240489","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240114.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240115","title":"Further Reply LS on Enhancement on the attribute for 5GLAN management","source":"SA WG5","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA5 thanks CT4 for the reply LS on Enhancement on the attribute for 5GLAN management. SA5 would like to provide CT4 with the following information.\n\nFirstly, purely appreciate for the clarification on the usage of the attribute internalGroupId and 5g-vn-groups. SA5 has been already working on management aspect of 5GLAN in R18 and has specified new performance measurement, related KPIs and attributes at the VN group level in TS 28.552 and TS 28.554. The consistent usage of Internal Group ID in different group of 3GPP can be more convenient for understanding.\n\nSecondly, SA5 also intends to specify the enhanced NRM to support the management of 5G LAN-type services, including the configuration management of 5G NF. Based on your feedback that \"CT4 didn't see the need to define the 5G LAN-type service in NRF for AmfInfo\/SmfInfo\/NrfInfo, since such information is not used for node selection.\", and the further information issued as follows:\n\nThe definition of AmfInfo\/SmfInfo\/NrfInfo\/TrustAfInfo in TS29.510 is used for node selection but not for identifying a 5G VN group. Since there is a 1:1 mapping between a 5G VN group and the combination of SNSSAI and DNN, the SNSSAI and DNN will be used for the SMF\/NRF selection in serving a 5G VN group member. That is why CT4 didn't define any 5G VN group-related information in SmfInfo\/NrfInfo. AMF node selection in serving a 5G VN group member is based on SNSSAI. The AmfInfo is only used by other SBI-based NF instances (e.g., SMF) to select AMF. So, CT4 does not need to define any 5G VN group-related information in AmfInfo.\n\nThis means that the existing NFInfo, SNSSAI, and DNN may already support the management of 5G LAN-type services. Therefore, SA5 will follow the conclusion of CT4 and complete the related work in R18 without any enhanced NRM for 5GLAN management.\n\nReference documentation:\n\u2022\t3GPP TS 28.552: Management and orchestration; 5G performance measurements\n\u2022\t3GPP TS 28.554: Management and orchestration; 5G end to end Key Performance Indicators (KPI)","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1150,"status":"noted","reservation_date":"2024-09-02 13:02:36","uploaded":"2024-02-09 13:06:16","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"5GLAN_Mgt"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"3GPP CT4","Cc":"3GPP SA2","lsoriginalls":"S5-238099","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240115.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240116","title":"LS reply to S3-233786 and S3-234296 on the introduction of the domain \u201cipxnetwork.org\u201d and clarifications of the Outsourced SEPP and Hosted SEPP deployment scenarios","source":"5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1160,"status":"noted","reservation_date":"2024-09-02 13:10:42","uploaded":"2024-02-09 13:30:12","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA3","Cc":"SA, SA1, SA2 and CT4","lsoriginalls":"5GMRR Doc 44_36r1","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240116.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240117","title":"LS \u201cN32-f lifetime and reconnection\u201d to 3GPP CT4\/SA3","source":"5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"3GPP is kindly asked to take the following actions:\nCT4\/SA3 to provide feedback on the assumptions that N32-f are long lived connections under control of the initiating client\nCT4 to indicate the preferred method (if any) to keep N32-f connections alive.\nCT4 to confirm or reject the actions to be taken if a connection fails after timeout.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":0,"status":"postponed","reservation_date":"2024-09-02 13:13:37","uploaded":"2024-02-09 13:30:12","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4, SA3","Cc":"","lsoriginalls":"5GMRR Doc 45_07r1","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240117.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240118","title":"N32-f N32-c correlation","source":"5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"3GPP is kindly asked to take the following actions:\nCT4\/SA3 to confirm the assumption that correlation and maintaining an N32 context or state is a requirement for a SEPP.\nCT4\/SA3 to provide further recommendation on how correlation should be achieved.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1190,"status":"postponed","reservation_date":"2024-09-02 13:16:08","uploaded":"2024-02-09 13:30:12","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4, SA3","Cc":"","lsoriginalls":"5GMRR Doc 45_08r1","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240118.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240119","title":"Educational paper on N32 connection establishment for bilateral TLS","source":"5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"3GPP is kindly asked to take the following actions:\nCT4\/SA3 to review the annex to this LS : 5GMRR Educational paper on N32 connection establishment for bilateral TLS v1.1 and confirm, reject or correct the understanding of 5GMRR with regards to conformity to the 3GPP specifications.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1200,"status":"noted","reservation_date":"2024-09-02 13:17:43","uploaded":"2024-02-09 13:30:12","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4, SA3","Cc":"","lsoriginalls":"5GMRR Doc 45_12r1","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240119.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240120","title":"LS on nested JSON structures and reply to LS S3-235067","source":"5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"Q1: What is the minimum number of nesting levels of JSON elements that a SEPP shall be able to process, and what error code shall be used if the maximum number of nesting levels supported is exceeded? \n\nQ2: Table 6.1.5.2.8-1 of TS 29.573 stipulates that only the JSON pointer of the leaf IEs are included. However, the finite \"IeList\" list necessarily defines an upper limit to the number of levels for nested JSON elements. Generally speaking, the cutoff may occur at a non-leaf. How to resolve this situation with respect to populating the \u201cIeList\u201d field of the \u201cApiIeMapping\u201d structure in cases similar to the example above? Should the field be populated with all possibilities of up to 32 nesting levels in such situations?","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":0,"status":"postponed","reservation_date":"2024-09-02 13:21:31","uploaded":"2024-02-09 13:30:12","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4 and SA3","Cc":"","lsoriginalls":"5GMRR Doc 46_08r1 - LS on nested JSON structures and reply to LS S3-235067","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240120.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240121","title":"LS on nested JSON structures and reply to LS S3-235067","source":"5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1220,"status":"noted","reservation_date":"2024-09-02 13:23:06","uploaded":"2024-02-09 13:30:12","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4 and SA3","Cc":"","lsoriginalls":"5GMRR Doc 46_08r1","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240121.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240122","title":"LS to 3GPP on data plane control by roaming hubs","source":"5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":1230,"status":"noted","reservation_date":"2024-09-02 13:25:09","uploaded":"2024-02-09 13:30:12","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA1 and SA2","Cc":"SA3, SA5, SA, CT4","lsoriginalls":"5GMRR Doc 47_14r1","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240122.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240123","title":"LS to 3GPP on PRINS security profiles","source":"5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"5GMRR asks 3GPP CT4 to update their specifications to allow for the flexibility to indicate profiles in general. To keep it flexible, please enable at least 256 profiles.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":2620,"status":"noted","reservation_date":"2024-09-02 13:28:19","uploaded":"2024-02-09 13:30:12","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4 and SA3","Cc":"","lsoriginalls":"5GMRR Doc 47_40","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240123.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240262","title":"LS to 3GPP CT4 on in-path and in-query parameters","source":"5GMRR","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":3210,"status":"noted","reservation_date":"2024-02-16 07:58:08","uploaded":"2024-02-16 08:00:04","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT4","Cc":"SA3","lsoriginalls":"5GMRR Doc 46_07","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240262.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240321","title":"Reply LS on in-path and in-query parameters","source":"Huawei","contact":"Caixia Qi","contact-id":56676,"tdoctype":"LS out","for":"Approval","abstract":"","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":5520,"status":"merged","reservation_date":"2024-02-17 03:00:12","uploaded":"2024-02-19 06:55:02","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA 5GMRR","Cc":"SA3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240321.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240552","title":"Reply LS on improved KPIs involving end-to-end data volume transfer time analytics","source":"SA5","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA5 thanks SA2 for the reply and their questions on improved KPIs involving end-to-end data volume transfer time analytics.\n\nAs for the actions to SA5, please find SA5\u2019s reply below inline:\na)\tAt the SA2 meeting #160, a decision was made to incorporate throughput KPIs to the end-to-end data volume transfer time analytics use case. For that, the Average DL\/UL UE throughput in the gNB per QoS level and per S-NSSAI KPI as specified in TS 28.552 clauses 5.1.1.3.1 and 5.1.1.3.3 was added. SA2 would like SA5 to also provide the same KPI for the Average UL\/DL UE throughput between PSA-UPF and the RAN. \nSA5 answer: SA5 will be happy to define these performance measurements as per SA2\u2019s request, and will inform SA2 once they are defined. \nb)\tAs part of SA5 development of the per UE RAN part UL\/DL packet delay and UL\/DL packet delay between PSA_UPF and UE, SA2 kindly asks SA5 to include a per UE per slice per QoS level granularity.  \nSA5 answer: SA5 acknowledges that SA5 has defined the above-mentioned UE level measurements at the per UE per slice per QoS level granularity. The detailed definitions can be found in the draft TS 28.558.\nc)\tSA2 would like to request SA5 to inform SA2 whether it anticipates any system architecture level impact for the requested support of the per UE delay measurements.\nSA5 answer: SA5 reuses MDT mechanisms for NG-RAN UE level measurements collection and extends the Trace mechanism for 5GC UE level measurements collection. To support signalling-based activation, and enable NWDAF to use it through interaction with the UDM, the Trace activation messages defined in 5GC needs to be extended with the specific configuration parameters for 5GC UE level measurements collection as specified in CR S5-240877 (potential CT3\/CT4 impact).","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":0,"status":"postponed","reservation_date":"2024-02-21 13:39:36","uploaded":"2024-02-21 13:43:06","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"AIMLsys"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA2, CT3, CT4, RAN2, RAN3","Cc":"","lsoriginalls":"S5-241086","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240552.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240553","title":"Reply to LS on String based Charging Identifier over SBI","source":"SA5","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS in","for":"Discussion","abstract":"SA5 would like to thank CT4 for the work done on the string-based charging identifier over SBI.\nSA5 has discussed and have concluded that informative annex added with 29.502 CR0714 is in line with the conclusions in SA5.\nSA5 has agreed the attached TS 32.291 CR0541 (Rel-18) referencing the new common data type for SMF Charging Identifier.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":55400,"status":"noted","reservation_date":"2024-02-21 13:42:03","uploaded":"2024-02-21 13:43:06","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"TEI18"},{"winame":" 5GS_Ph1-CT"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"C4-234657","lsto":"CT4","Cc":"CT3","lsoriginalls":"S5-241091","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240553.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240554","title":"Reply LS \u201cN32-f lifetime and reconnection\u201d","source":"CT4","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS out","for":"Approval","abstract":"","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":0,"status":"postponed","reservation_date":"2024-02-26 08:04:47","uploaded":null,"revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"5GMRR","Cc":"SA3","lsoriginalls":"","lsreply":"","link":"","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"C4-240800","title":"Reply LS on defining new GTP-U Extension Header for PDU Set related information","source":"CT4","contact":"Kimmo Kymalainen","contact-id":85426,"tdoctype":"LS out","for":"Approval","abstract":"","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4","ainame":"Input liaison statements: allocation to agenda items as appropriate","tdoc_agenda_sort_order":80000,"status":"approved","reservation_date":"2024-01-03 06:44:18","uploaded":"2024-03-01 06:51:07","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"NR_XR_enh-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN3","Cc":"SA2","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG4_protocollars_ex-CN4\/TSGCT4_121_Athens\/Docs\/C4-240800.zip","group":"C4","meeting":"C4-121","year":2024,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0}]