[{"name":"R5-205392","title":"LS on R15 signalling test on EPS NAS message container IE for inter-system change from S1 mode to N1 mode without N26","source":"TSG WG RAN5","contact":"Yuchun Wu","contact-id":77331,"tdoctype":"LS out","for":"Approval","abstract":"During the specification of conformance test cases for IDLE mode, RAN5 noticed a Rel-17 CR C1-205432 has been agreed by CT1 and the Rel-17 3GPP core specification has been modified as below. [..]\nRAN5 want to ask CT1 group to confirm whether R15\/16 UEs can implement in accordance with the Rel-17 TS 24.501 in this aspect, i.e., whether single-registration UEs to include TAU Request message during inter-system change from S1 mode to N1 mode without N26.\nActions: To CT1 group: RAN5 asks CT1 group to answer above question.","secretary_remarks":"","agenda_item_sort_order":748,"ainumber":"6.7","ainame":"Outgoing liaison statements for provisional approval","tdoc_agenda_sort_order":53920,"status":"withdrawn","reservation_date":"2020-10-28 01:59:31","uploaded":"2020-10-31 08:02:48","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_NR_LTE-UEConTest"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG WG CT1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_89_Electronic\/Docs\/R5-205392.zip","group":"R5","meeting":"R5-89-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-205451","title":"LS on R15 signalling test on EPS NAS message container IE for inter-system change from S1 mode to N1 mode without N26","source":"Huawei, Hisilicon","contact":"Yuchun Wu","contact-id":77331,"tdoctype":"LS out","for":"Approval","abstract":"","secretary_remarks":"","agenda_item_sort_order":748,"ainumber":"6.7","ainame":"Outgoing liaison statements for provisional approval","tdoc_agenda_sort_order":54510,"status":"withdrawn","reservation_date":"2020-10-28 02:30:17","uploaded":null,"revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_NR_LTE-UEConTest"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT1","Cc":"","lsoriginalls":"","lsreply":"","link":"","group":"R5","meeting":"R5-89-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-206258","title":"LS on inconsistency in specifying handling of MCPTT SIP 183 (Session Progress) response in TS 24.379","source":"TSG WG RAN5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Approval","abstract":"During the specification of the MCPTT Conformance testing RAN5 noticed the following inconsistency in the specified handling of MCPTT SIP 183 (Session Progress) response in TS 24.379.\nTS 24.379, subclause 6.3.2.2.5.2 specifies the need for the participating MCPTT function to generate a SIP 183 (Session Progress) response to the \"SIP INVITE request for terminating participating MCPTT function\" as follows\n6.3.2.2.5.2\tAutomatic commencement for On-Demand session\nWhen receiving a \"SIP INVITE request for terminating participating MCPTT function\" for an on-demand session that requires automatic commencement mode the participating MCPTT function:\n1)\tif:\na)\tthe incoming SIP INVITE request contained a Priv-Answer-Mode header field set to the value of \"Auto\";\nb)\tno Answer-Mode header field or Priv-Answer-Mode header field were received in the incoming SIP INVITE request and the Answer-Mode Indication received in the application\/poc-settings+xml MIME body received from the invited MCPTT client as defined in subclause 7.3.3 or subclause 7.3.4 is set to \"auto-answer\"; or\nc)\tthe incoming SIP INVITE request contained an Answer-Mode header field set to \"Auto\" and the Answer-Mode Indication received in the application\/poc-settings+xml MIME body received from the invited MCPTT client as defined in subclause 7.3.3 or subclause 7.3.4 is set to \"auto-answer\";\nthen:\na)\tshall generate a SIP 183 (Session Progress) response to the \"SIP INVITE request for terminating participating MCPTT function\" as specified in subclause 6.3.2.2.4.1;\nb)\tif the received SIP INVITE request contained an application\/vnd.3gpp.mcptt-info+xml MIME body with the <ambient-listening-type> element set to a value of \"remote-init\" shall include in the SIP 183 (Session Progress) response an alert-info header field set to a value of \"<file:\/\/\/dev\/null>\" according to IETF RFC 3261 [24] and as updated by IETF RFC 7462 [77]; and\nNOTE:\tThe SIP 183 (session Progress) response can be sent reliably or unreliably depending on the content of the received SIP INVITE request. Regardless of if the SIP 183 (Session Progress) response is sent reliably or unreliably, SDP is not included in the SIP 183 (Session Progress) response.\nHowever, handling of this message is not defined, nor mentioned, at the controlling function side (TS 24.379, subclauses 11.1.1.4.2 or 11.1.1.4.1).\nActions: To CT1 group: RAN5 asks CT1 for guidance and action in clarifying whether the SIP 183 (Session Progress) shall or shall not be sent by the terminating participating MCPTT function, and hence, will or will not be sent to the originating Client.","secretary_remarks":"","agenda_item_sort_order":748,"ainumber":"6.7","ainame":"Outgoing liaison statements for provisional approval","tdoc_agenda_sort_order":625800,"status":"approved","reservation_date":"2020-11-22 12:48:17","uploaded":"2020-11-22 12:51:21","revisionof":"","revisedto":"","release":"Rel-14","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG WG CT1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_89_Electronic\/Docs\/R5-206258.zip","group":"R5","meeting":"R5-89-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-206259","title":"LS on failing initial registration attempt without Retry-After header field","source":"TSG WG RAN5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Approval","abstract":"TS 24.229 clause 5.1.1.2.1 contains the following text:\nAfter a first unsuccessful initial registration attempt, if the Retry-After header field was not present and the initial registration was not performed as a consequence of a failed reregistration, the UE shall not wait more than 5 minutes before attempting a new registration.\nAfter a maximum of 2 consecutive unsuccessful initial registration attempts, if the Retry-After header field was not present in failure responses of those unsuccessful initial registration attempts, the UE shall start to implement the mechanism defined in subclause 4.5 of RFC 5626 [92] for determination of the retry delay time before each new registration attempt. The UE shall use the values of the parameters max-time and base-time, of the algorithm defined in subclause 4.5 of RFC 5626 [92]. If no values of the parameters max-time and base-time (if all failed) have been provided to the UE by the network, the default values defined in subclause 4.5 of RFC 5626 [92] shall be used.\nThe values of max-time and base-time (if all failed) may be provided by the network to the UE using OMA-DM with the management objects specified in 3GPP TS 24.167 [8G]. Other mechanisms may be used as well and are outside the scope of the present specification.\nFor each 4xx, 5xx or 6xx response received without a Retry-After header field to the REGISTER request, the UE shall:\na)\tmark the currently used P-CSCF address as unavailable for the last duration of the retry delay time computed by the algorithm defined in subclause 4.5 of RFC 5626 [92] plus 5 minutes; and\nb)\tinitiate an initial registration as specified in subclause 5.1.1.2 after the amount of time of the last retry delay time computed by the algorithm defined in subclause 4.5 of RFC 5626 [92]; and\n[..]\nRAN5 is unclear on how the UE should behave when, after sending an initial registration attempt, being confronted with a 503 Service Unavailable response without a Retry-After header. Two different interpretations are being discussed:\nA.\tThe UE shall not wait more than 5 minutes before attempting a new registration (on the same P-CSCF), i.e. it follows the first of above quoted paragraphs. \nIf more unsuccessful registration attempts happen (at a maximum of 2), the UE uses RFC 5626, i.e., it follows the second and third of the above paragraphs in order to determine the wait time for the next initial registration attempts.\nIf that initial registration attempt failed as well, the last paragraph is applied, using a new P-CSCF\nB.\tThe UE shall follow the first and fourth  paragraph starting with \u201cFor each 4xx, 5xx or 6xx \u2026\u201d  in order to determine the available P-CSCF (not on current P-CSCF) and the retry delay time for the consecutive initial registration attempt based on RFC 5626. If the consecutive initial registration attempt(at a maximum of 2) was confronted with 4xx, 5xx or 6xx response without Retry-After header field, then the UE reset the retry delay time and follows the second, third and fourth of the above paragraphs in order to determine the available P-CSCF and the retry delay time for the next initial registration attempts based on RFC 5626.\nThe reasoning for the two different interpretations are as follows:[..]\nActions: To CT WG1group: RAN WG5 asks CT WG1 which of the above interpretations is to be applied upon described scenario.","secretary_remarks":"","agenda_item_sort_order":748,"ainumber":"6.7","ainame":"Outgoing liaison statements for provisional approval","tdoc_agenda_sort_order":625900,"status":"approved","reservation_date":"2020-11-22 12:48:17","uploaded":"2020-11-22 12:51:21","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG WG CT1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_89_Electronic\/Docs\/R5-206259.zip","group":"R5","meeting":"R5-89-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-206273","title":"LS on integrity and confidentiality protection of xcap-diff and pidf documents in MCPTT (TS 24.379)","source":"TSG WG RAN5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Approval","abstract":"Subclause 6.6.3.1 in TS 24.379 defines a list of XML MIME bodies used for SIP signalling in that TS that can be integrity protected.\nNeither \"application\/pidf+xml\" nor \u201capplication\/xcap-diff+xml\u201d XML MIME bodies are listed there, so that it can be argued whether any SIP request\/response with a pidf document or xcap-diff (and no other xml documents) needs to be signed or even can be signed.\nHowever, xcap-diff documents sent in the NOTIFY contain sensitive data according to TS 24.379 clause 4.8 (e.g. the MCPTT ID). Therefore confidentiality (and integrity protection) should be enabled and hence applied to the xcap-diff documents.\nAdditionally, in TS 24.484 clause 6.3.13.2.2 it states \"Upon receiving a SIP NOTIFY request ... if identity hiding is required, the CMC shall perform the confidentiality protection procedures and integrity protection procedures defined in 3GPP TS 24.379 [9] for MC client\"\nSimilarly, for pidf documents TS 24.379 seems to be also contradictory as a pidf document contains sensitive information according to clause 4.8 (e.g. the client id) therefore according to clause 4.8 it should be encrypted and signed. Furthermore, TS 33.180 Section 9.3.5 just mentions generically \"When integrity protection is enabled, all XML MIME bodies transported in SIP requests and responses are integrity protected.\"\nAccording to the core specification then can and\/or shall pidf and xcap-diff MIME bodies be ciphered (and signed when integrity protection is on)?\nActions: to TSG CT WG1 group: TSG RAN WG5 asks TSG CT WG1 to clarify the above ambiguity.","secretary_remarks":"","agenda_item_sort_order":748,"ainumber":"6.7","ainame":"Outgoing liaison statements for provisional approval","tdoc_agenda_sort_order":627300,"status":"approved","reservation_date":"2020-11-22 12:48:32","uploaded":"2020-11-22 12:51:21","revisionof":"","revisedto":"","release":"Rel-14","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG WG CT1","Cc":"TSG WG SA3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_89_Electronic\/Docs\/R5-206273.zip","group":"R5","meeting":"R5-89-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-206274","title":"LS on reporting of SINR measurements for serving cell","source":"TSG WG RAN5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Approval","abstract":"Reference 1: TS 38.331 clause 5.5.3.1 contains the following text: [..]\nReference 2: TS 38.331 clause 5.5.5.1 contains the following text: [..]\nRAN5 is unclear on how the UEs supporting SINR measurements should behave when reporting serving cell metrics if SINR is not included as trigger quantity and\/or reporting quantity. Two different interpretations are being discussed:\nA.\tUEs supporting SINR measurements can include SINR metrics for serving cell based on reference 2 unconditionally (per UE implementation) in the measurement report, and reference 1 is just to mandate the UEs to derive SINR measurement if configured as a trigger quantity and\/or reporting quantity. \nB.\tThe UE shall only derive SINR if configured as a trigger quantity and\/or reporting quantity, otherwise the SINR metric shall not be reported for the serving cell irrespective if the UE supports capability \u2018ss-SINR-meas\u2019 or not.\nActions: To RAN WG2 group. RAN WG5 asks RAN WG2 group which of the above interpretations is to be applied upon described scenario.","secretary_remarks":"","agenda_item_sort_order":748,"ainumber":"6.7","ainame":"Outgoing liaison statements for provisional approval","tdoc_agenda_sort_order":627400,"status":"approved","reservation_date":"2020-11-22 12:48:33","uploaded":"2020-11-22 12:51:21","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG WG RAN2","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_89_Electronic\/Docs\/R5-206274.zip","group":"R5","meeting":"R5-89-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]