[{"name":"C3-214365","title":"Reply LS on Clarification on the API design principles","source":"CT4","contact":"Achraf Khsiba","contact-id":92474,"tdoctype":"LS in","for":"Discussion","abstract":"SCHEDULED FOR 1ST WEDNESDAY SESSION\n\nQuestion 1) Which HTTP method (a standard HTTP GET or a custom HTTP POST) should be used by the NF service consumer to retrieve information from the service producer in the scenario where the NF service producer does not own the information requested by the consumer and the service producer needs to further fetch the information from other services?\n[CT4 Answer] Use of HTTP GET or custom operation based on HTTP POST mainly depends on whether the request is safe\/idempotent or unsafe\/non-idempotent. It does not necessarily depend on whether the retrieved information is \u201cowned\u201d by the service producer or not.\nQuestion 2) If a custom operation is used, then what is the criteria to decide whether associated resource is needed or not?\n[CT4 Answer] A custom operation without associated resource is not expected to modify any resource in the server. \nRefer Annex C.4 of 3GPP TS 29.501:\nWhen the custom operation is not associated with any resource but with the service, it acts as an executable function with input parameters and returns the result of the executed function in the response body, not modifying any resource.\nCT4 would like to highlight that according to guidelines in 29.501, it is highly recommended to use REST-style service operations where possible. It is good to associate a resource with an operation wherever possible; this is also useful when additional operations may be defined on the parent resource in future. This also should be evaluated on a case-by-case basis.\nQuestion 3) whether a resource can be associated only with a custom operation?\n [CT4 Answer] There is nothing that prevents a resource to be associated only with custom operations. Such design choice should be evaluated on a case-by-case basis.\n\nAction proposed by Chair:\nCheck if the reply allows CT3 to apply the design principles in our APIs or if any further information is needed. Take this information into account when deciding on the services operations for our services.","secretary_remarks":"Contact person: \tVarini Gupta \n\tvarini.gupta@samsung.com\n\nWork Item:\tSBIProtoc17","agenda_item_sort_order":15,"ainumber":"6","ainame":"Received Liaison Statements","tdoc_agenda_sort_order":43650,"status":"noted","reservation_date":"2021-08-11 15:37:58","uploaded":"2021-08-11 18:31:20","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"Clarification on the API design principles","lsto":"CT3","Cc":"CT1, SA4, SA5","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG3_interworking_ex-CN3\/TSGC3_117e\/Docs\/C3-214365.zip","group":"C3","meeting":"C3-117-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"C3-214366","title":"Reply LS to CT4 on Information on the port number allocation solutions","source":"RAN3","contact":"Achraf Khsiba","contact-id":92474,"tdoctype":"LS in","for":"Discussion","abstract":"RAN3 would like to thank CT4 for their LS on Information on the port number allocation solutions. RAN3 had discussions the different solutions in the TR, and reached the following understandings:\nFrom RAN3 perspective:\n-\tBoth Solutions 1 and 2 are feasible.\n-\tRAN3 also noticed that Solution 11 is a once-and-for-all solution that can be considered, though its adoption is not entirely under 3GPP control. It requires IETF endorsement.\n-\tThe rest of the solutions are not desirable.\nAction proposed by Chair:\nNo action required in CT3. The LS can be NOTED.","secretary_remarks":"Name:\tXudong Yang\nTel. Number:\t+86-21 3890808\nE-mail Address:\tyangxudong@huawei.com\nWork Item:\tFS_PortAl (Unique identifier: 890002)","agenda_item_sort_order":15,"ainumber":"6","ainame":"Received Liaison Statements","tdoc_agenda_sort_order":43660,"status":"noted","reservation_date":"2021-08-11 15:48:49","uploaded":"2021-08-11 18:31:20","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"LS R3-211411\/C4-211806 on Information on the port number allocation solutions","lsto":"CT4","Cc":"SA4, CT3, SA5, SA, CT, RAN, SA2, RAN2","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG3_interworking_ex-CN3\/TSGC3_117e\/Docs\/C3-214366.zip","group":"C3","meeting":"C3-117-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"C3-214367","title":"LS Reply on NSI ID on N7 interface","source":"SA2","contact":"Achraf Khsiba","contact-id":92474,"tdoctype":"LS in","for":"Discussion","abstract":"SA2 would like to answer the questions as below. \n\nQ1:\tHow does the SMF determine the NSI ID in this context? In this sense, please also clarify the meaning of the mention \"if available\".\n\nSA2 Answer: Stage 2 specifications currently consider that SMF is not aware of the NSI ID of a PDU Session.  So, SMF cannot provide the corresponding NSI ID to the PCF. SA2 agrees to correct this as in the attachments. \n\nQ2:\tWhat is the foreseen use case behind it? In other words, how this parameter is expected to be used by the PCF in the frame of the Npcf_SMPolicyControl service?\n\nSA2 Answer:  NSI ID from SMF to PCF was introduced in S2-187506 so that PCF could use it to retrieve slice instance load information from NWDAF during Rel-15. \n\nAction proposed by Chair:\nPostponed from the previous meeting. There are related submitted CRs in this meeting. Check if they are aligned with the reply.","secretary_remarks":"","agenda_item_sort_order":15,"ainumber":"6","ainame":"Received Liaison Statements","tdoc_agenda_sort_order":43670,"status":"noted","reservation_date":"2021-08-11 15:53:13","uploaded":"2021-08-11 18:31:20","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"LS (S2-2102090\/C3-210310) on NSI ID on N7 interface from CT3","lsto":"CT3","Cc":"CT4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG3_interworking_ex-CN3\/TSGC3_117e\/Docs\/C3-214367.zip","group":"C3","meeting":"C3-117-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"C3-214368","title":"LS Response on the input parameters of the LCS subscription request from an AF via NEF","source":"SA2","contact":"Achraf Khsiba","contact-id":92474,"tdoctype":"LS in","for":"Discussion","abstract":"S2-2101595 provides answers to the LS from CT3 on the input parameters of the LCS subscription request from an AF via NEF. In the paper, it is stated:\nQ3:\tIf the answer to Q1 is no, then how these parameters are derived by the NEF? Should these parameters only be stored and derived by the GMLC? In this case, this would mean that these parameters should be removed from the list of possible input parameters to be provided by the NEF in the Ngmlc_Location_ProvideLocation request.\n\nANSWER:   The parameter \"External Client Type\" may be provisioned in the NEF or GMLC per AF. It is used for privacy authorization in GMLC (23.273 6.1.2) or NEF (23.273 6.5.1). \nIf provisioned in the NEF, when AF sends location request to NEF, based on the AF ID, NEF derive the \u201cExternal (LCS) Client Type\u201d and include it in Ngmlc_Location_ProvideLocation request.\nIf not provisioned in NEF, NEF simply forwards the location request message from AF to the GMLC.\nSA2 will continue to work the issue whether it is NEF or GMLC to determine the \u201cExternal (LCS) Client Type\u201d, in case the location request is sent by AF via N33 interface. It is expected SA2 will define a single solution.\n\nThe highlight texts has been further discussed by SA2 and conclusion is as follows:\nWhen AF requests location to the NEF, NEF derives the LCS client type of the AF and provides to the GMLC in the same PLMN. In case of roaming, HPLMN GMLC will also provide the LCS client type of the AF to the V-GMLC. \n\nThe LCS client type of the AF is a mandatory parameter for GMLC, If the GMLC does not receive it from NEF, GMLC will reply an error indication to NEF.\n\nAction proposed by Chair:\nPostponed from the previous meeting. There are related submitted CRs in this meeting. Check if they are aligned with the reply.","secretary_remarks":"Work item: 5G_eLCS\n\nContact Person:\t\nName:\tRunze Zhou\nTel. Number:\t\nE-mail Address:\tzhourunze AT huawei DOT com","agenda_item_sort_order":15,"ainumber":"6","ainame":"Received Liaison Statements","tdoc_agenda_sort_order":43680,"status":"noted","reservation_date":"2021-08-11 17:12:48","uploaded":"2021-08-11 18:31:20","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"(S2-2100020\/C3-205448) LS on the input parameters of the LCS subscription request from an AF via NEF","lsto":"CT3","Cc":"CT4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG3_interworking_ex-CN3\/TSGC3_117e\/Docs\/C3-214368.zip","group":"C3","meeting":"C3-117-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"C3-214369","title":"LS on 5G capabilities exposure for factories of the future","source":"CCSA","contact":"Achraf Khsiba","contact-id":92474,"tdoctype":"LS in","for":"Discussion","abstract":"SA2  discussed the LS from 5G-ACIA, and would like to:\n1.\tSuggest that TSG SA co-ordinates the answers from SA1, SA2, SA3 and SA6 to provide a single response from 3GPP perspective,\n2.\tInform SA plenary that SA2 plans to provide its technical input from SA2#146E August meeting i.e. for the September TSG SA plenary.\n\nAction proposed by Chair:\nNo action required in CT3. The LS can be NOTED.","secretary_remarks":"Contact Person:\t\nName:\t Laurent Thiebaut\nE-mail Address:\t Laurent.thiebaut@nokia.com\n\n\n(revision of S2-2104787r03)","agenda_item_sort_order":15,"ainumber":"6","ainame":"Received Liaison Statements","tdoc_agenda_sort_order":43690,"status":"noted","reservation_date":"2021-08-11 17:24:57","uploaded":"2021-08-11 18:31:20","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"(relates with LS 1 # 5G-ACIA-LS-2021-001 from 5G-ACIA: 5G capabilities exposure for factories of the future - revised)","lsto":"3GPP TSG SA, SA1, SA3, SA6","Cc":"SA5, CT3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG3_interworking_ex-CN3\/TSGC3_117e\/Docs\/C3-214369.zip","group":"C3","meeting":"C3-117-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"C3-214370","title":"Reply LS on Support of UAVs authentication\/authorization in 3GPP systems and interfacing with USS\/UTM","source":"SA2","contact":"Achraf Khsiba","contact-id":92474,"tdoctype":"LS in","for":"Discussion","abstract":"SA2 thanks GSMA-ACJA for the LS on \u201cSupport of UAVs authentication\/authorization in 3GPP systems and interfacing with USS\/UTM.\u201d\nSA2 has developed mechanisms in TS 23.256 based on Network Exposure Function (NEF) to support interfacing between the MNO network and the USS using WebAPI interfaces, and no EAP-Diameter solutions have been adopted.\n\nAction proposed by Chair:\nNo action required in CT3. The LS can be NOTED.","secretary_remarks":"Contact person:\tStefano Faccin\n\tsfaccin@qti.qualcomm.com","agenda_item_sort_order":15,"ainumber":"6","ainame":"Received Liaison Statements","tdoc_agenda_sort_order":43700,"status":"noted","reservation_date":"2021-08-11 17:31:20","uploaded":"2021-08-11 18:31:20","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2103730","lsto":"GSMA-ACJA","Cc":"SA WG3, SA WG6, CT WG1, CT WG3, CT WG4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG3_interworking_ex-CN3\/TSGC3_117e\/Docs\/C3-214370.zip","group":"C3","meeting":"C3-117-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"C3-214371","title":"Reply-LS on the Security consideration to support L2TP with CUPS","source":"SA3","contact":"Achraf Khsiba","contact-id":92474,"tdoctype":"LS in","for":"Discussion","abstract":"SA3 thanks CT4 for the LS C4-210171\/S3-211378 on the Security consideration to support L2TP with CUPS. SA3 would like to provide the following feedback:\nFor protection of the information transferred from the CP function to the UP function, a security mechanism shall be used.\nAccording to TS 33.501, clause 9.9, and TS 33.401, clause 11, NDS\/IP as specified in TS 33.210 is the existing security mechanism for the N4 interface and the Sxb interface. NDS\/IP shall be used unless security is provided by other means, e.g. physical security.\nThe existing mechanism NDS\/IP is sufficient to protect usernames and passwords on the N4 and Sxb interfaces, since it already provides confidentiality, integrity and replay protection. \nHence the first mechanism (i.e. Relying on the Network domain security) proposed by CT4 shall be used.\n\nAction proposed by Chair:\nCT3 is copied. There are related submitted CRs in this meeting. Check if they are aligned with the reply.","secretary_remarks":"Contact person:\tChristine Jost\n\tchristine.jost@ericsson.com\n\nWork Item:\tBEst Practice of PFCP (BEPoP)","agenda_item_sort_order":15,"ainumber":"6","ainame":"Received Liaison Statements","tdoc_agenda_sort_order":43710,"status":"noted","reservation_date":"2021-08-11 17:53:17","uploaded":"2021-08-11 18:31:20","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"LS C4-210171\/S3-211378 on the Security consideration to support L2TP with CUPS from CT4","lsto":"CT4","Cc":"SA2, CT3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG3_interworking_ex-CN3\/TSGC3_117e\/Docs\/C3-214371.zip","group":"C3","meeting":"C3-117-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"C3-214372","title":"Reply-LS on Secondary AUTH for 5GS interworking with EPS","source":"SA3","contact":"Achraf Khsiba","contact-id":92474,"tdoctype":"LS in","for":"Discussion","abstract":"SA3 would like to provide the following replies to the question raised by CT3. The replies provided by SA2 are included for convenience.\nCT3 Q1: Whether EAP based secondary authorization\/ authentication is also applicable for EPS, when the UE supports EAP.\n[SA2 reply in S2-2101305]: EAP based secondary authorization\/ authentication has only been defined for 5GS and is thus not applicable to EPS in existing releases. SA2 expects that in case EAP based secondary authorization\/ authentication is to be introduced in EPS it would require a new work item in SA2.]\nSA3 reply: SA3 confirms SA2's reply. In case EAP-based secondary authentication is to be introduced in EPS, it would require a new work item in SA3 as well. SA3 currently has no plans to initiate such a work item, and no requirements for such a work item have been raised in SA3.\nCT3 Q2: When the DN-AAA server initiates EAP based re-authorization but UE has moved from 5GS to EPS, whether such re-authorization will be supported.\n[SA2 reply in S2-2101305: If the re-authorization is associated with EAP based re-authentication procedure, then the re-authorization will not be supported since EAP-based re-authentication cannot be performed when the UE is in EPS in existing releases. However, if based on local policy the DN-AAA server initiates DN-AAA re-authorization without performing re-authentication, then a DN-AAA re-authorization (without EAP-based re-authentication) can be supported even when UE is in EPS: this may be used. to provide new parameters from the DN-AAA server to SMF+PGW-C.]\nSA3 reply: SA3 confirms SA2's reply.\nCT3 Q3: If only PAP\/CHAP based secondary authorization\/authentication is applicable in EPS, how to handle the case when the DN-AAA server initiates EAP based re-authorization but UE has moved from 5GS to EPS.\n[SA2 reply in S2-2101305: SA2 assumes that CT3 refers to the re-authorization associated with EAP-based re-authentication procedure scenario. SA2 expects that in such case the SMF+PGW-C, that receives the re-authentication request from the DN-AAA, can inform the DN-AAA server that the UE is not available for EAP-based re-authentication at the moment. The SMF+PGW-C should not initiate PDN connection release: the DN-AAA can decide based on the reply from SMF+PGW-C and based on local policy what actions to take in that case, but this is out of 3GPP scope.]\nSA3 reply: SA3 confirms SA2's reply.\nSA3 believes that updates agreed by SA2 (S2-2101312, CR 2475r2 to TS 23.502) address the necessary changes to stage-2 specifications and no additional updates to specifications under the remit of SA3 are necessary.\n\nAction proposed by Chair:\nAsk the WG if any further action is required based on this reply.","secretary_remarks":"Contact person:\tChristine Jost\n\tchristine.jost@ericsson.com","agenda_item_sort_order":15,"ainumber":"6","ainame":"Received Liaison Statements","tdoc_agenda_sort_order":43720,"status":"noted","reservation_date":"2021-08-11 17:57:59","uploaded":"2021-08-11 18:31:20","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"LS S3-211376\/C3-210377 on LS on Secondary AUTH for 5GS interworking with EPS","lsto":"CT3, SA2","Cc":"CT1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG3_interworking_ex-CN3\/TSGC3_117e\/Docs\/C3-214372.zip","group":"C3","meeting":"C3-117-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"C3-214373","title":"Reply LS to SA2 on UE Data Collection","source":"SA4","contact":"Achraf Khsiba","contact-id":92474,"tdoctype":"LS in","for":"Discussion","abstract":"SA4 thanks SA2 for the LS  which contains 1) answer to SA4 questions in our previous outgoing LS, 2) information on previously SA4-specified QoE metrics now defined in TS 23.288 as Service Experience information for exposure by the AF to NWDAF, 3) stated expectation for SA4 to define the mechanisms for AF collection of cited Collective Behaviour and Service Experience information, and 4) request to SA4 on information and possible support for defining a general UE data collection\/data reporting solution in the R17 timeframe.\n\nWith respect to item 3, SA4 will need more time to understand and evaluate the corresponding information types, sources of that data, and availability of defined network interfaces and procedures for collection by the AF of those collective behaviour and service experience information (for subsequent offering as event exposure services). We may contact SA2 on related questions in the process.\n\nWith regards to item 4, SA4 has agreed the EVEX Work Item (see attachment) at SA4#114-e, for SP approval.  We wish to point out that one of the objectives of the work item is to \u201cDefine a generic architecture within which media-specific solutions for the configuration and subsequent operation of data collection and data reporting (via event exposure) by the AF can be specified\u201d. We think that this task should address the question and request from SA2 on SA4 definition of a general purpose architecture in support of SA2\u2019s R17 requirements on data collection and reporting. We would however like to point out that such to-be-defined generic architecture is mainly intended to enable media services specific functions of configuration, data collection and subscription-based notification to consumer entities in addition to the NWDAF, such as the ASP. While we expect to engage in frequent communications with SA2 (and likely other 3GPP WGs) during the WI process towards informing about as well as seek guidance on our work, it will be SA2\u2019s decision (and that of other WGs) on adoption of our generic architecture.\nSA4 kindly asks CT3 whether you have any questions or other feedback about the EVEX Work Item.\n\nAction proposed by Chair:\nAsk the WG if there are questions to be asked to SA4 on EVEX WI. Otherwise note the LS and monitor the progress of the work in SA4 & related actions in SA2.\n\nEricsson is planning a reply for next CT3 meeting.","secretary_remarks":"Contact Person:\t\nName:\tCharles Lo\nTel. Number:\t+1 858-651-5674\nE-mail Address:\tclo@qti.qualcomm.com","agenda_item_sort_order":15,"ainumber":"6","ainame":"Received Liaison Statements","tdoc_agenda_sort_order":43730,"status":"postponed","reservation_date":"2021-08-11 18:03:47","uploaded":"2021-08-11 18:31:20","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S4-210963 (S2-2104864)","lsto":"SA2","Cc":"CT3, RAN2, SA3, SA6","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ct\/WG3_interworking_ex-CN3\/TSGC3_117e\/Docs\/C3-214373.zip","group":"C3","meeting":"C3-117-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]