[{"name":"S6-200967","title":"Reply LS on limiting the number of simultaneous log ins of an MCX user","source":"SA1","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"1. Overall Description:\nSA1 thanks CT1 for their LS in C1-202819.\nSA1 have discussed the issue.\n\nWith respect to the question from CT1: \nDoes requirement [R-5.10-001a] of 3GPP TS 22.280 require that a different limit can be applied to each MCX User?\nSA1 have discussed the issue and the answer is No.\n\nThe existing requirement should be interpreted as meaning \"a single system limit per MCX service shall be applied to all users within the MCX service, which aligns with the existing stage 2 architecture defined by SA6 for Release 16 in TS 23.379.\"\nAttached you\u2019ll find the Release 16 and Release 17 (mirror) CRs to TS22.280 clarifying the existing requirement to be a system wide limit. One additional CR adds a new requirement in Rel-17 to allow for different limits per MCX user.\n\n2. Actions:\nTo CT1 group.\nACTION: \tSA1 asks CT1 to take the information provided into account for their further work.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9670,"status":"noted","reservation_date":"2020-06-30 21:45:45","uploaded":"2020-06-30 23:28:49","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT1","Cc":"SA6","lsoriginalls":"S1-202280","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200967.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200968","title":"Reply to LS on Clarification of the definition of a UAS","source":"SA1","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Action","abstract":"1. Overall Description:\nSA1 has considered the incoming LS from SA6 requesting clarification on stage 1 requirements, as copied below.\n\nThe text in the definition of a UAS and other normative text in TS 22.125 is not aligned with the informative Annex A. Further, it can be noted that there is text in the informative Annex A that is normative.\n\nSA1 has discussed the definition of a UAS and come to the conclusion that an update of TS 22.125 is needed, see the attached agreed CR.\n\n2. Actions:\nTo SA2 and SA6 groups.\nACTION: \tSA1 requests SA2 and SA6 to take the above into account in their work and update their specifications as necessary.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9680,"status":"noted","reservation_date":"2020-06-30 21:45:45","uploaded":"2020-06-30 23:28:49","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA2, SA6","Cc":"","lsoriginalls":"S1-202267","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200968.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200969","title":"LS on requirement for 5GMSG in broadcast scenario","source":"SA1","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Action","abstract":"1. Overall Description:\nSA1 thanks SA6 for the question if requirement [R-5.5.2-002] applies to all UE types, i.e. UE B, UE C and UE D as defined in TS 22.262 or only to UE types that support the broadcast message.\n\nThe MSGin5G Service for MIoT needs to support broadcast message delivery in order to handle massive communications efficiently with a latency less than [500] ms as specified in requirement [R-5.5.2-001]. This requirement cannot be achieved with point-to-point message delivery. Therefore, the requirement applies to UEs that support the broadcast message.\n\n2. Actions:\nTo SA6 group.\nACTION:\tSA1 asks SA6 to take the above information into account.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9690,"status":"noted","reservation_date":"2020-06-30 21:45:45","uploaded":"2020-06-30 23:28:49","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"5GMSG"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA6","Cc":"","lsoriginalls":"S1-202269","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200969.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200970","title":"Reply LS on Clarification of requirements for UAS application enablement","source":"SA1","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Action","abstract":"1. Overall Description:\nSA1 thanks SA6 for the LS requesting clarification on stage 1 requirements, copied bellow.\n\nSA6 has discussed potential key issues on:\n\n\u2022\tWhether and how to enable flight route support in 3GPP network\n\u2022\tWhether and how to control a UAV fly route under 3GPP network\n\u2022\tWhether and how to enable NOTAM\/TFR support under 3GPP network\n\nSA6 asks SA1 to kindly guide SA6 on the requirements for the use cases mentioned above and also the necessity to explicitly refer to application-aware parameters. SA6 kindly asks SA1 to update their specification if necessary.\n\nSA1 has discussed pointed out requirements [R-5.1-003] and [R-5.1-004] from TS 22.125:\n\n[R-5.1-003] The 3GPP system shall enable a UAS to send UTM the UAV data which can contain: unique identity (this may be a 3GPP identity), UE capability of the UAV, make & model, serial number, take-off weight, position, owner identity, owner address, owner contact details, owner certification, take-off location, mission type, route data, operating status.\n\n[R-5.1-004] The 3GPP system shall enable a UAS to send UTM the UAV controller data which can contain: unique identity (this may be a 3GPP identity), UE capability of the UAV controller, position, owner identity, owner address, owner contact details, owner certification, UAV operator identity, UAV operator license, UAV operator certification, UAV pilot identity, UAV pilot license, UAV pilot certification and flight plan.\n\nThese requirements are coming from use case for initial authorization to operate. The use case and derived requirements indicate 3GPP system shall enable data communication between UAS and UTM. Indicated parameters show by which means the UAV and UAV controller shall be identified and inform that list of identification data sent towards the UTM could be quite long.\nSA6 discussions on potential key issues described above which enable 3GPP to control UAV flight route and NOTAM\/TFR are outside the scope of the service requirements for UAS support in 3GPP.\n\n2. Actions:\nTo SA6 group.\nACTION: \tSA1 kindly asks SA6 to take the above information into account.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9700,"status":"noted","reservation_date":"2020-06-30 21:45:45","uploaded":"2020-06-30 23:28:49","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA6","Cc":"SA2","lsoriginalls":"S1-202270","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200970.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200971","title":"Reply LS on Application Architecture for enabling Edge Applications","source":"SA2","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Action","abstract":"1. Overall Description:\nSA2 thanks SA6 for the LS on Application Architecture for enabling Edge Applications (S2-2002608\/S6-192399), and would like to provide the following feedback. \nSA2 understood that the \u201cApplication architecture\u201d in clause 6.2 in TR 23.758 reuses SA2 defined reference points of EPS or 5GS for retrieval of network capability information. SA2 would like to highlight that SA2 supports Edge Computing specific functions only in 5GS.\nSA2 understood that some solutions in TR 23.758 have dependencies on SA2 work as listed in Table 11.3.1-1 of the TR. SA2 hasn\u2019t discussed whether any new SA2 features are needed to support these solutions. SA6 is welcome to send LS in case specific dependencies on SA2 are identified.\n2. Actions:\nTo SA6 group.\nACTION: \tSA2 kindly asks SA6 to take above feedback into consideration.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9710,"status":"noted","reservation_date":"2020-06-30 21:45:45","uploaded":"2020-06-30 23:28:49","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_enh_EC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA6","Cc":"SA3, SA5","lsoriginalls":"S2-2004386","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200971.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200972","title":"Reply LS on provisioning \"\"EDN connection info\"\" by Edge Configuration Server","source":"SA2","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Action","abstract":"1. Overall Description:\nSA2 thanks SA6 about the LS on provisioning \"EDN connection info\" by Edge Configuration Server (S2-2003201\/S6-200617). SA2 discussed the questions and agreed the following answers.\n\nQ1: SA6 kindly requests that SA2 comment on whether SA6\u2019s understanding that a UE Application may provide a DNN is correct?\n\nSA2 answer: SA2 considers the UE application mentioned in Q1 means upper layer to NAS (URSP handling) layer and SA2 confirms that the UE Application may provide a DNN that is used for matching Traffic descriptor(s) in the URSP rules.\n\nQ2: SA6 kindly requests that SA2 comment on how to handle the scenario when parameters provisioned by Edge Configuration Server create a conflict with URSP rules, ANDSP rules or UE local configuration?\n\nSA2 answer: According to TS 23.503, the association of an application to a PDU Session is based on either URSP (if provisioned by the operator) or UE Local Configuration. \nSA2 treats the parameters provisioned by Edge Configuration Server as UE Local Configuration. The handling precedence between URSP and UE Local Configuration is defined in TS 23.503 clause 6.1.2.2.1.\n\nQ3: SA6 kindly requests that SA2 comment on whether S-NSSAI can be provisioned by 3rd party via the application layer?\n\nSA2 answer: According to TS 23.503, the association between application traffic and S-NSSAI associated to a PDU Session (by evaluating either URSP or UE Local Configuration) should be controlled by the operator to ensure that only expected service traffic flows are transferred via a specific slice. The UE Local Configuration (e.g. the operator specific configuration including S-NSSAI) can be configured by the operator (or operator\u2019s contracted partner), however it is out of scope of SA2 how UE Local Configuration is configured in UE.\n\nAs an alternative to UE Local Configuration, some solutions are under discussion in TR 23.748 for Rel-17 to support the application layer (e.g. ECS) to influence the URSP rules that the network provisions to the UE. \n\n2. Actions:\nTo SA6 group.\nACTION: \tSA2 kindly asks SA6 to take above information into consideration.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9720,"status":"noted","reservation_date":"2020-06-30 21:45:45","uploaded":"2020-06-30 23:28:49","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_enh_EC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA6","Cc":"","lsoriginalls":"S2-2004387","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200972.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200973","title":"Liaison from IETF Scope and goals of the  Drone Remote ID Protocol Working Group (DRIP) of the Internet Engineering Task Force (IETF)","source":"IETF DRIP","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"Dear Sir, \nThis 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).\n\nThe remaining of this email contains a brief description of the DRIP Working Group as well as the IETF. \n\nIf you have any questions or concerns, feel free to contact us, we would be more than happy to take them into account.\n\nThe DRIP co-chairs: Mohammed Boucadair and Daniel Migault\nThe Internet Area Director: Eric Vyncke.\n\nFor the complete presentation please refer to the original LS available in S6-200973.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9730,"status":"postponed","reservation_date":"2020-06-30 21:45:45","uploaded":"2020-06-30 23:28:49","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA6","Cc":"","lsoriginalls":"IETF LS 9th June2020","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200973.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200974","title":"LS on SA5 Rel-17 work on SLA","source":"SA5","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"","abstract":"1. Overall Description:\nSA5 has cooperated with GSMA 5GJA on implementing NG.116 (v2.0) GST SLA attributes as network slice ServiceProfile attributes in the 3GPP Network Resource Model (NRM) (TS 28.541 clauses 6.3.3, 6.4.1) in the Rel-16 work item Management Aspects of 5G Service-Level Agreement. This work item has been finalised in Rel 16, and a continuing Rel-17 work item Enhancement of Management Aspects of 5G Service-Level Agreement (SP-200190) has been approved. In Rel-17, SA5 will continue working on implementing updated GST SLA attributes, as GSMA 5GJA will continue working on NG.116. \n\nIn addition, SA5 will work on breaking down SLA requirements to NetworkSliceSubnet to update the SliceProfile in the 3GPP NRM, which can provide clear requirements to CN, RAN and TN (TS 28.541 clauses 6.3.4, 6.4.1).\n\n2. Actions:\nTo GSMA 5GJA:\nSA5 respectfully requests GSMA 5GJA to take this information into account and provide feedback, if necessary.\n\nTo SA2 group:\nSA5 respectfully requests 3GPP SA2 to take this information into account and provide feedback, if necessary.\n\nTo RAN3 group:\nSA5 respectfully requests 3GPP RAN3 to take this information into account and provide feedback, if necessary.\n\nTo IETF TEAS WG:\nSA5 respectfully requests IETF TEAS WG to take this information into account and provide feedback, if necessary.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9740,"status":"noted","reservation_date":"2020-06-30 21:45:45","uploaded":"2020-06-30 23:28:49","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"EMA5SLA"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA 5GJA, 3GPP SA2, RAN3, IETF TEAS WG","Cc":"3GPP SA, SA1, SA6, RAN2, ETSI ISG ZSM","lsoriginalls":"S5-203370","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200974.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200975","title":"LS on Key Management procedure in SEAL","source":"CT3","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"1. \tOverall description\nAs specified in the clause 5.3 of TS 33.434 v0.4.0, the VAL server may request key material applicable to particular SEAL service, VAL client or user. CT3 seeks clarifications on SEAL KM Request message from VAL server to Key Management server, as specified in the clause 5.3.2. \nCT3 asks SA3 to clarify the following:\nQ1. Need clarity on the \u201cVersion\u201d information element. What is the purpose of this version? Is it used to identify a key version or a message version for the reference point? \nQ2. On ClientID that maps to the VAL client, there is no explicit requirement in TS 23.434 requiring a VAL server to support VAL client id. Is ClientID needed only for KM-UU? Or it is also applicable for KM-S reference point? \nQ3. Except for identifying the late requests and responses, is there any other requirement of date\/time in the KM request and the corresponding KM request response? \nQ4. As per SEAL KM request procedure, the KMS shall verify the SKMSUri is the SKM-S URI of the target SEAL KMS. It is not clear if the SKMSUri is the URI where the key information are storedor it is a URI on the target KMS that the receiving KMS needs to further use\/contact the target KMS via SEAL-E reference point by using the SkmsURI?\nQ5. In SEAL KM response message, why is \u201cPayload\u201d optional and what is the meaning of \u201cif the request does not require a payload\u201d in its description? Are these to indicate there is no provisioned key material specific to the VAL service, VAL user\/ue\/client in the SEAL KM request? If so, what is the expected behavior for the VAL server, VAL user\/ue\/client after receiving the response without key?\n\n2. \tActions\nTo SA WG3 group: \nACTION: \tCT3 kindly asks SA3 to answer the above questions.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9750,"status":"noted","reservation_date":"2020-06-30 21:45:45","uploaded":"2020-06-30 23:28:49","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"SEAL"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA3","Cc":"SA6, CT1","lsoriginalls":"C3-203588","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200975.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200976","title":"LS to 3GPP RAN5 on Requirement for Mission Critical Services (MCX) Testing and Certification 3GPP Release level","source":"GCF-TCCA Joint Taskforce","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9760,"status":"noted","reservation_date":"2020-06-30 21:45:45","uploaded":"2020-06-30 23:28:49","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN5","Cc":"MCC TF160, 3GPP SA6","lsoriginalls":"MCC-JTF-20-062r2","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200976.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200977","title":"LS on location reporting triggers","source":"CT3","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Action","abstract":"1\t. Overall description\nAs defined in clause 9.3.5 of TS 23.434, the VAL server configures the location reporting trigger to the location management server to activate a location reporting procedure for obtaining the location information of location management client. It\u2019s unclear that whether it is a one-time configuration or not.\nAlso as defined in clause 9.3.6 of TS 23.434, the location management server may cancel the location reporting triggers configuration to the location management client. \nCT3 asks SA6 to clarify the following:\nQ1:\tIf the VAL server has configured the reporting event triggers to the location management server, can the VAL server update the configuration information later, e.g. extend Triggering criteria?\nQ2:\tIf the VAL server has configured the reporting event triggers to the location management server, can the VAL server cancel the configurations at a later time?\nAlso, in TS 29.549, for SS_GroupManagement API, CT3 updated \u201cConfigure_Group_Info\u201d service operation\u2019s name to \u201cUpdate_Group_Info\u201d. CT3 kindly asks SA6 to take this information into consideration and update their specification.\n\n2. \tActions\nTo SA WG6 group:\nACTION: \tCT3 kindly asks SA6 to answer above questions and update their specification if necessary.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9770,"status":"replied to","reservation_date":"2020-07-01 01:11:10","uploaded":"2020-07-01 01:14:17","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"SEAL"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA6","Cc":"","lsoriginalls":"C3-202441","lsreply":"S6-201259","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200977.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200978","title":"LS on limiting the number of simultaneous log ins of an MCX user","source":"CT1","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9780,"status":"noted","reservation_date":"2020-07-01 01:11:11","uploaded":"2020-07-01 01:14:17","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"MONASTERY2"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA1","Cc":"SA6","lsoriginalls":"C1-202819","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200978.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-200979","title":"5G capabilities exposure for factories of the future","source":"5G-ACIA","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"1. Overall Description:\nOver the last two years, 5G-ACIA has collected and analysed many industrial use cases. These use cases \u2013 as well as inferred communication service characteristics \u2013 have been documented by 3GPP in TS 22.104 and TS 22.261. 5G-ACIA has further refined and analysed operational use cases that are needed by factory operators to manage and maintain 5G-enabled devices and 5G Non-Public Networks (NPN) in a simple and efficient manner.\n \n5G-ACIA believes the service exposure requirements derived from the aforementioned operational use cases are valuable input for upcoming contributions addressing ongoing work in 3GPP, such as the study items documented in TR 23.700 and TR 23.745. These requirements have been published in the 5G-ACIA white paper Exposure of 5G capabilities for connected industries and automation applications (www.5g-acia.org\/publications), which is also attached to this LS.\n\nThis white paper focuses on operational use cases pertaining to device management, for example use cases that enable factory operators to manage the life cycle of devices, and e.g. to change and monitor the devices\u2019 connectivity. In order to execute these operational use cases efficiently, the industrial systems require a set of well standardised and published APIs that hide a great deal of 3GPP complexity and yet provide the needed flexibility to the factory operator.\nThese capabilities are needed by factories of the future and expected from 5G NPN and 5G-enabled devices. 5G-ACIA would like to highlight the importance of these refined requirements for industrial operations and would appreciate it very much, if 3GPP considered the provided information to ongoing and upcoming specification work.\n5G-ACIA would be eager to receive 3GPP\u2019s feedback on these new exposure interface requirements and related Stage-2 and Stage-3 work.\n\n2. Actions:\nTO             3GPP TSG SA \nACTION:   Consider the content of the white paper and advice any related 3GPP WG on needed study items or actions and provide feedback to 5G-ACIA on planned activities.","secretary_remarks":"","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":9790,"status":"noted","reservation_date":"2020-07-01 10:27:58","uploaded":"2020-07-01 11:13:23","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"3GPP TSG SA","Cc":"3GPP SA1, SA2, SA3, SA5, SA6, CT3, IEC TC65, oneM2M TP, OPC Foundation, PI, IEEE TSN, TM Forum, ETG","lsoriginalls":"5G-ACIA-LS-2020-WI039","lsreply":"S6-201093, S6-201175","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_038-e\/Docs\/S6-200979.zip","group":"S6","meeting":"S6-38-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]