[{"name":"S2-2001789","title":"LS from SA WG4: Reply LS on Support for ECN in 5GS","source":"SA WG4","contact":"Nikolai Leung","contact-id":38562,"tdoctype":"LS in","for":"Action","abstract":"SA WG4 thanks SA WG2 for the LS and provides answers to the following questions in the LS: SA WG2 would like to ask SA WG4 whether there is an expectation for support of ECN when UE's MTSI client is operating over 5GS, and whether mobility between EPS and 5GS raises any issues related to ECN handling in scenarios where ECN is supported and used over EPS, but is not supported or used over 5GS. The support of ECN in MTSI terminals is optional ('may') in TS 26.114 and is specified based on the access bearer technology known to the MTSI client, and not on the type of the core network. For the NR access bearer technology, ECN support is not as fully specified as for E-UTRAN or UTRA\/HSPA. During the Rel-15 and Rel-16 work to specify support for MTSI operation over NR and E-UTRAN, TS 26.114 was updated to recommend (from 'may' to 'should') the use of RAN-Assisted Codec Rate Adaptation (i.e., access network bitrate recommendation\/ANBR in TS 26.114). This was seen as a more robust solution when the main cause of congestion comes from the radio access bearers and SA WG4 recommends the use of ANBR for MTSI moving forward for NR and E-UTRAN in Release 16 and beyond. If an MTSI terminal using ECN for media rate adaption hands-off between an eNB that supports ECN to a gNB that does not, then the MTSI terminal will not receive early congestion indications from the gNB. This may cause the MTSI terminal to have to rely on packet jitter, delays, or even loss, to make necessary rate adaptations if the MTSI terminal, gNB or both does not support RAN-Assisted Codec Adaptation. SA WG2 would like to ask SA WG4 whether there is any other use of ECN beyond bitrate adaptation for MTSI. As of this time, SA WG4 has not studied the use of ECN for any other purposes. Action: SA WG4 asks SA WG2 to take the above responses into consideration.","secretary_remarks":"Postponed","agenda_item_sort_order":16,"ainumber":"6.5","ainame":"QoS concept and functionality","tdoc_agenda_sort_order":10760,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"RAN WG2, RAN WG3, CT WG1","lsoriginalls":"S4-200298","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2001789.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001804","title":"ARP handling at PDU Session establishment","source":"Orange","contact":"Antoine Mouquet","contact-id":38438,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: 'ARP priority level' replaced by ARP. Removal of paragraph on handling of the ARP pre-emption capability and the ARP pre-emption vulnerability.","secretary_remarks":"Noted","agenda_item_sort_order":16,"ainumber":"6.5","ainame":"QoS concept and functionality","tdoc_agenda_sort_order":10770,"status":"noted","reservation_date":"2020-02-10 14:49:28","uploaded":"2020-02-18 16:05:21","revisionof":"","revisedto":"","release":"Rel-15","crspec":"23.501","crspecversion":"15.8.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2129.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2001804.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001805","title":"ARP handling at PDU Session establishment","source":"Orange","contact":"Antoine Mouquet","contact-id":38438,"tdoctype":"CR","for":"Approval","abstract":"Rel-16 mirror CR: Summary of change: 'ARP priority level' replaced by ARP. Removal of paragraph on handling of the ARP pre-emption capability and the ARP pre-emption vulnerability.","secretary_remarks":"Noted","agenda_item_sort_order":16,"ainumber":"6.5","ainame":"QoS concept and functionality","tdoc_agenda_sort_order":10780,"status":"noted","reservation_date":"2020-02-10 14:53:26","uploaded":"2020-02-18 16:05:21","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.3.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2130.0,"crrevision":"","crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2001805.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002120","title":"Default ARP values for dedicated QoS Flows","source":"Huawei, HiSilicon, Ericsson","contact":"Marco Spini","contact-id":8356,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: The description of the default value setting for the ARP sub-parameters is corrected for QoS Flows not associated with the default QoS rule when dynamic PCC is not deployed. Furthermore, the description is reworded to clarify that ARP sub-parameters have to be set according to the values provided by the PCF if dynamic PCC is deployed. A similar rewording is done for the Session-AMBR description. The description is also updated by clarifying that the UDM provides all ARP sub-parameters.","secretary_remarks":"Revision of agreed S2-2001101 from S2#136AH. Noted","agenda_item_sort_order":16,"ainumber":"6.5","ainame":"QoS concept and functionality","tdoc_agenda_sort_order":10790,"status":"noted","reservation_date":"2020-02-18 07:57:44","uploaded":"2020-02-18 14:40:46","revisionof":"S2-2001101","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.3.0","workitem":[{"winame":"5GS_Ph1"},{"winame":"TEI16"}],"crnumber":2056.0,"crrevision":3.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2002120.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002121","title":"New QoS parameter Additional QoS Flow Information","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: The QoS parameter Additional QoS Flow Information is added.","secretary_remarks":"Revision of unhandled S2-2000511 from S2#136AH. Noted","agenda_item_sort_order":16,"ainumber":"6.5","ainame":"QoS concept and functionality","tdoc_agenda_sort_order":10800,"status":"noted","reservation_date":"2020-02-18 07:57:44","uploaded":"2020-02-18 14:40:46","revisionof":"S2-2000511","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.3.0","workitem":[{"winame":"5GS_Ph1"},{"winame":"TEI16"}],"crnumber":2058.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2002121.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]