[{"name":"S2-2004336","title":"LS from IEEE 802.1: Response to LS on TSN support in 3GPP Release-16 stage 2 completion","source":"IEEE 802.1","contact":"Glenn Parsons","contact-id":17960,"tdoctype":"LS in","for":"Action","abstract":"Dear Colleagues, The IEEE 802.1 Working Group would like to thank TSG SA Working Group 2 (SA WG2) for the information provided in liaison statement S2-2003508 on the completion of the 5G Release-16 stage 2 specifications in support of IEEE 802.1 Time-Sensitive Networking (TSN). We thank you for using our standards as normative references in the manner that they were intended. This has prompted us to make detailed comments in the spirit of cooperation. Our comments to the sections of the documents sent for review are attached. We look forward to maintaining the dialogue and cooperation between our organizations. Note that the IEEE 802 work is open and contribution-driven. Participation is on an individual basis and technical discussion can be conducted based on individual contributions. We have regular calls, details on TSN Task Group calls are available at https:\/\/1.ieee802.org\/tsn-calls. Respectfully submitted, Glenn Parsons Chair, IEEE 802.1 Working Group","secretary_remarks":"","agenda_item_sort_order":17,"ainumber":"4.2","ainame":"Common issues and Incoming LSs - Phase 2","tdoc_agenda_sort_order":16880,"status":"available","reservation_date":"2020-06-03 17:21:02","uploaded":"2020-06-03 17:21:47","revisionof":"","revisedto":"S2-2004782","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"liaison-response-TSN-support-in-3GPP-Release-16","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_139e_Electronic\/Docs\/S2-2004336.zip","group":"S2","meeting":"S2-ah-38172","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2004337","title":"LS from RAN WG2: Reply LS on assistance indication for WUS","source":"RAN WG2","contact":"Mungal Singh Dhanda","contact-id":84552,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 thanks SA WG2 for their reply LS on assistance indication for WUS and the agreed CRs which restrict the use of WUS to the last used cell. RAN WG2 would like to provide the following feedback: - If the eNB where UE accesses is WUS capable, it is always possible for the eNB to determine whether the UE supports WUS via either UE Radio Capability IE delivered from MME\/AMF or UE capability enquiry. - During eNB change due to handover or reestablishment, the source eNB provides the UE-CapabilityRAT-ContainerList to the target eNB but the UE-RadioPagingInfo(-NB) IE is not passed from source to target eNB. This means, after inter-eNB connected mode mobility the target eNB does not know whether UE supports WUS. RAN WG2 has made the following agreement regarding this issue to avoid additional radio interface signalling: ? RAN WG2 strongly recommends to avoid relying on UE capability enquiry to retrieve the capability - From RAN WG2 point of view, it is not necessary for a WUS capable eNB to know whether the UE in connected mode supports WUS. Action: RAN WG2 respectfully asks SA WG2 and RAN WG3 to take into consideration the above response.","secretary_remarks":"","agenda_item_sort_order":17,"ainumber":"4.2","ainame":"Common issues and Incoming LSs - Phase 2","tdoc_agenda_sort_order":16890,"status":"available","reservation_date":"2020-06-03 17:21:02","uploaded":"2020-06-03 17:21:47","revisionof":"","revisedto":"S2-2004783","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, RAN WG3","Cc":"CT WG1","lsoriginalls":"R2-2005939","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_139e_Electronic\/Docs\/S2-2004337.zip","group":"S2","meeting":"S2-ah-38172","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2004338","title":"LS from SA WG6: LS on IP address to GPSI translation","source":"SA WG6","contact":"Nishant Gupta","contact-id":62473,"tdoctype":"LS in","for":"Action","abstract":"In the SA WG6 architecture for enabling Edge Applications, the Edge Enabler Server (EES) and the Edge Configuration Server (ECS) utilize 3GPP core network capabilities. The EES also facilitates use of 3GPP core network capability exposure by the Edge Application Servers (EAS). For this purpose, the EES, acting as trusted or untrusted application function, requires the ability to translate a UE's IP address to its GPSI. If the UE's IP address is provided by the EAS, it could be its private (i.e. non-NAT'd) IP address or public (i.e. NAT'd) IP address, in case NAT systems are employed by the 3GPP network. To SA WG2: 1. Is there a core network supported method to provide a UE's GPSI to an EAS directly? 2. Does the core network provide an API to translate a UE's IP address (private and public) to its GPSI, and if not, would it be feasible to provide such functionality in Rel-17 in order to address the SA WG6 requirement for UE IP address translation? 3. While providing the functionality requested in bullet 1, is it feasible to provide application-specific GPSIs, to ensure that a single GPSI can not be used to track an end user's activity across applications (EASs), to protect end user privacy? To SA WG3: Since the GPSI may be used by EASs to obtain sensitive information about a UE, such as its location, SA WG6 kindly asks SA WG3 to ensure that user consent is secured before providing the GPSI or any other sensitive information about the UE to an EAS. Action: SA WG6 requests SA WG2 to kindly consider the above questions and provide feedback accordingly.","secretary_remarks":"","agenda_item_sort_order":17,"ainumber":"4.2","ainame":"Common issues and Incoming LSs - Phase 2","tdoc_agenda_sort_order":16900,"status":"available","reservation_date":"2020-06-03 17:21:02","uploaded":"2020-06-03 17:21:47","revisionof":"","revisedto":"S2-2004784","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG3","Cc":"","lsoriginalls":"S6-200947","lsreply":"S2-2004845, S2-2005255","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_139e_Electronic\/Docs\/S2-2004338.zip","group":"S2","meeting":"S2-ah-38172","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2004339","title":"LS from SA WG6: Reply LS on QoS Sustainability Analytics","source":"SA WG6","contact":"Niranth Amogh","contact-id":39608,"tdoctype":"LS in","for":"Information","abstract":"SA WG6 thanks 5GAA WG2 for the LS on QoS Sustainability Analytics. SA WG6 likes to inform 5GAA WG2 that the suggestion provided in the LS has been considered in the on-going study, but no conclusion has been reached on the viability of such a solution. Currently, SA WG6 is in completion phase of the study on Enhancements to application layer support for V2X services (FS_eV2XAPP). The study is captured in the technical report, 3GPP TR 23.764 and the latest version is available at https:\/\/www.3gpp.org\/DynaReport\/23764.htm.","secretary_remarks":"","agenda_item_sort_order":17,"ainumber":"4.2","ainame":"Common issues and Incoming LSs - Phase 2","tdoc_agenda_sort_order":16910,"status":"available","reservation_date":"2020-06-03 17:21:02","uploaded":"2020-06-03 17:21:47","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"5GAA WG2","Cc":"SA WG2","lsoriginalls":"S6-200948","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_139e_Electronic\/Docs\/S2-2004339.zip","group":"S2","meeting":"S2-ah-38172","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2004340","title":"LS from SA WG4: LS on Media Feature Tag for IMS Data Channel","source":"SA WG4","contact":"Bo Burman","contact-id":16624,"tdoctype":"LS in","for":"Information","abstract":"SA WG4 would like to inform CT WG1 and CT WG3 that SA WG4 discovered that it is ambiguous what streaming media feature tag to use for the recently introduced IMS data channel media in MTSI. Since this media uses the 'application' media type, using only that information from RFC 3840 as a media feature tag would be too unspecific. This drawback is already recognized and mitigated by IETF RFC 5688, introducing an 'app-subtype' media feature tag that can take individual application media format values. SA WG4 notes that IETF RFC 5688 is already referenced and used by TS 24.229. SA WG4 also notes that TS 24.229 specifies use of media feature tags in a media agnostic fashion, not detailing or mandating what individual media feature tag values to use beyond the above-mentioned references. Due to this ambiguity in the IMS data channel media feature tag value and media-agnostic handling of media feature tags in TS 24.229, SA WG4 has chosen to amend the IMS data channel media handling specification in TS 26.114 to specify what media feature tag value to use for IMS data channel media (see attached CR 26.114).","secretary_remarks":"","agenda_item_sort_order":17,"ainumber":"4.2","ainame":"Common issues and Incoming LSs - Phase 2","tdoc_agenda_sort_order":16920,"status":"available","reservation_date":"2020-06-04 06:18:02","uploaded":"2020-06-04 06:18:22","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1, CT WG3","Cc":"SA WG2","lsoriginalls":"S4-200908","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_139e_Electronic\/Docs\/S2-2004340.zip","group":"S2","meeting":"S2-ah-38172","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2004631","title":"LS from SA WG5: LS on network data analysis energy saving","source":"SA WG5","contact":"Jean Michel Cornily","contact-id":7599,"tdoctype":"LS in","for":"Action","abstract":"In S5-201169 \/ S2-1912770 (LS on analytics support for energy saving), SA WG2 describes the following use case related to energy saving in the 5GC: ' In particular, the network data analysis may indicate that all the UEs served by some UPF instances are low priority UEs. Based on this information, the SMF can intentionally re-allocate the low priority UEs among fewer dedicated UPF instances which are used only for serving the low priority UEs at night and running on fewer dedicated servers. As a result, there can be more UPF instances having no UE allocated to them and can be removed by the NFV orchestrator. Consequently, there can be more physical resources, such as servers, to be shut down at night and less energy to be consumed. '. As part of its Rel-17 study item 'Study on new aspects of EE for 5G networks' (FS_EE5G), SA WG5 has studied this use case. From SA WG5 point of view, some points are to be clarified, including: 1. It is not clear: a. how UEs are characterized as low or high priority and on which criteria (e.g. user profile, etc.), b. where NWDAF gets this information from, c. whether UE priority is relative to within a given network slice (i.e. priority amongst UEs of a given network slice) or across network slices (i.e. priority amongst UEs of different network slices); 2. It is not clear if the main criteria for reallocating traffic from some UPF instances to fewer UPF instances is the UE priority or the time of the day (the above text mentions 'at night') or service level parameters. In other words, can't the reallocation of traffic from some UPF instances to fewer UPF instances be decided only based on the traffic load at some time of the day \/ night? 3. Since UEs can be attached to up to eight network slices simultaneously and UPF instances either belong to a single network slice (in such a case, traffic reallocation can be done only between UPF instances of the same network slice) or are shared amongst two or more network slices (in such a case, traffic reallocation can be done between UPF instances of different network slices serving the low priority UEs), the re-allocation of the traffic from some UPF instances to some other UPF instances must take this into consideration, implying that the NWDAF must have this knowledge prior to taking any decision; 4. Is it necessary that NWDAF have the information about which UPF instances are susceptible to receive traffic from other UPF instances? If yes, how does it obtain this information? 5. Migrating the traffic from some UPF instances to other UPF instances so as to switch off some servers requires interacting with NFV MANO functions (e.g. for VNF instance migration \/ termination). How NWDAF interacts with NFV MANO function(s) and via which reference point(s) is not specified. The reference point Os-Ma-Nfvo is for interactions between NFV Orchestrator and OSS\/BSS and, consequently, can't be used by NWDAF; 6. Reallocating traffic from some UPF instances to other UPF instances may have to take into consideration additional information such as e.g.: a. When ordering a network slice to his Network Slice Provider (NSP), a Network Slice Customer (NSC) may express isolation requirements such as e.g. 'I want my UPF instances be physically isolated from any other UPF instances allocated to other NSCs'. NWDAF has no knowledge of this, only OSS can have such information; b. All concerned UPF instances may not be on the same site \/ data centre, which potentially are not powered by the same source of energy. The network operator may be willing to privilege green sources of energy. In addition, the cost of energy may highly differ between sites \/ data centres. NWDAF has no knowledge of this, only OSS can have such information; c. All these UPF instances may be hosted on different types of servers, where some types of servers can be more energy efficient than others, so that the network operator may be willing to privilege these energy efficient servers. NWDAF has no knowledge","secretary_remarks":"Postponed","agenda_item_sort_order":17,"ainumber":"4.2","ainame":"Common issues and Incoming LSs - Phase 2","tdoc_agenda_sort_order":16930,"status":"postponed","reservation_date":"2020-06-04 13:38:19","uploaded":"2020-06-08 07:08:08","revisionof":"","revisedto":"S2-2004785","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"TSG SA","lsoriginalls":"S5-203360","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_139e_Electronic\/Docs\/S2-2004631.zip","group":"S2","meeting":"S2-ah-38172","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2004634","title":"LS from SA WG4: LS on AT Commands for Bit Rate Recommendation","source":"SA WG4","contact":"Imed Bouazizi","contact-id":84417,"tdoctype":"LS in","for":"Information","abstract":"SA WG4 has adopted the MAC-layer signalling for bitrate recommendation and bitrate recommendation query that are defined in TS 36.321 for LTE and 38.321 for 5G NR. These procedures are used for codec level adaptations for voice calls as defined in MTSI, TS 26.114. SA WG4 is currently also considering making use of this mechanism for network assistance to media streaming sessions. In addition to the typical query\/response usage, the bitrate recommendation may be triggered by the RAN, without a preceding query message. In such case, it is important to make this information available to the application without delay. SA WG4 is wondering whether this would be possible through the AT interface. Currently, this information is made available to the modem at the UE, which then passes the information to the application through proprietary mechanisms. SA WG4 believes that a standardized interface for the exchange of such information between the modem and the application would make this feature more accessible to applications and application developers. One way to address this gap could be through devising appropriate AT commands for this purpose. SA WG4 would like to kindly ask CT WG1 to consider extending the AT interface as defined in TS 27.007, to enable the exchange of bit rate recommendation and bit rate recommendation queries between the modem and the application. SA WG4 would appreciate CT WG1 sharing their opinion and keeping SA WG4 informed about the progress of this matter.","secretary_remarks":"Noted","agenda_item_sort_order":17,"ainumber":"4.2","ainame":"Common issues and Incoming LSs - Phase 2","tdoc_agenda_sort_order":16940,"status":"noted","reservation_date":"2020-06-09 05:23:01","uploaded":"2020-06-09 05:24:26","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"SA WG2, RAN WG2","lsoriginalls":"S4-200880","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_139e_Electronic\/Docs\/S2-2004634.zip","group":"S2","meeting":"S2-ah-38172","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2004635","title":"LS from CT WG4: LS on Clarification on AAA-Server address","source":"CT WG4","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"During the implementation of stage 3 NSSAA procedures, CT WG4 has observed that there is inconsistency in stage 2 specification on where the AAA-S address comes: In step 4 of clause 4.2.9.2 of TS 23.502, it mentions 'The AMF sends the EAP Identity Response to the AUSF in a Nausf_NSSAA_Authenticate Request (EAP Identity Response, AAA-S address, GPSI, S-NSSAI).', but in step4 of Figure 4.2.9.2-1 of 23.502 the AAA-S address is not included. Therefore CT WG4 would like to ask SA WG2 and SA WG3 to clarify the following questions: 1. Whether the AAA-S address is conveyed by AMF to the AUSF\/NSSAAF in step4? 2. In clause 5.15.3 of 23.501, there is the text 'the indication whether the S-NSSAI is subject to Network Slice-Specific Authentication and Authorization and associated AAA Server Address', does it imply that the AAA-S address is stored in UDM\/UDR and AMF gets the associated AAA Server Address from the UDM\/UDR? Or is there any other mechanism to get the associated AAA Server Address?. Action: CT WG4 kindly requests SA WG2 and SA WG3 to clarify the above questions.","secretary_remarks":"Postponed","agenda_item_sort_order":17,"ainumber":"4.2","ainame":"Common issues and Incoming LSs - Phase 2","tdoc_agenda_sort_order":16950,"status":"postponed","reservation_date":"2020-06-09 15:30:53","uploaded":"2020-06-09 15:31:21","revisionof":"","revisedto":"S2-2004786","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG3","Cc":"","lsoriginalls":"C4-203452","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_139e_Electronic\/Docs\/S2-2004635.zip","group":"S2","meeting":"S2-ah-38172","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2004636","title":"LS from IETF DRIP: Scope and goals of the Drone Remote ID Protocol Working Group (DRIP) of the Internet Engineering Task Force (IETF)","source":"IETF DRIP","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"Dear Sir, This email intents to share with 3GPP the scope and goals of the Drone Remote ID Protocol Working Group (DRIP) of the Internet Engineering Task Force (IETF). The remaining of this email contains a brief description of the DRIP Working Group as well as the IETF. If you have any questions or concerns, feel free to contact us, we would be more than happy to take them into account. The DRIP co-chairs: Mohammed Boucadair and Daniel Migault The Internet Area Director: Eric Vyncke","secretary_remarks":"Postponed","agenda_item_sort_order":17,"ainumber":"4.2","ainame":"Common issues and Incoming LSs - Phase 2","tdoc_agenda_sort_order":16960,"status":"postponed","reservation_date":"2020-06-09 16:01:57","uploaded":"2020-06-09 16:02:44","revisionof":"","revisedto":"S2-2004787","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"LSs_from_IETF_9June2020","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_139e_Electronic\/Docs\/S2-2004636.zip","group":"S2","meeting":"S2-ah-38172","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]