[{"name":"S6-181599","title":"LS on Observations from 2nd MCPTT Plugtests","source":"CT1","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"1. \tOverall description\n3GPP CT1 have received your liaison \u201cObservations on standards and technical constraints from 2nd MCPTT Plugtests\u201d (C1-186346) and wish to extend our appreciation for this input to our work.\n3GPP CT1 member companies have begun to work on the problems noted in your liaison. We wish to inform you that several fixes were applied at the current meeting (3GPP CT WG1 Meeting 112bis), and more fixes are expected at upcoming meetings.\nWe welcome this input. We also would note that the delegates at Plugtest are probably the experts most familiar with the problems found and the solutions that may apply. Accordingly, it would be most efficient if the 3GPP member companies present in Plugtest directly prepare change requests to 3GPP specifications and bring them to the appropriate 3GPP working groups as direct company contributions. While Plugtest reports from ETSI CTI are indeed welcome, such direct company contributions are likely to produce specifications with the correct solutions most quickly.\n3GPP CT1 look forward to further inputs from Plugtest, especially as direct company contributions from your experts most familiar with the problems found.\n2. \tActions\nTo ETSI CTI \nACTION: Please note the appreciation of 3GPP CT1 for this input.","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":15990,"status":"noted","reservation_date":"2018-10-31 07:48:08","uploaded":"2018-10-31 08:15:08","revisionof":"","revisedto":"","release":"Rel-14","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ETSI CTI","Cc":"3GPP CT, SA, SA3, SA6","lsoriginalls":"C1-186964","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181599.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-181600","title":"LS on ROHC support","source":"SA4","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"1. Overall Description:\nSA4  thanks CT3 for the LS on ROHC (C3-185174\/S4-181020) which provides a set of proposals for ROHC. These different propositions have been reviewed and implemented in the CR 0611 (S4-181195).\nSA4 kindly asks CT3 to review the changes and update stage 3 if needed.\n\n2. Actions:\nTo CT3 group.\nACTION: \tSA4 kindly asks CT3 to review the changes and update stage 3 if needed.","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":16000,"status":"noted","reservation_date":"2018-10-31 07:48:08","uploaded":"2018-10-31 08:15:08","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT3","Cc":"SA6","lsoriginalls":"S4-181207","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181600.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-181601","title":"LS to 3GPP TSG-SA WG6 on Use of ITS Dedicated Spectrum within V2X UE","source":"ETSI TC ITS","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Action","abstract":"ETSI TC ITS would like to thank 3GPP TSG-SA WG6 for the liaison statement on use of ITS dedicated spectrum (i.e. 5.9 GHz) within V2X UE.  ETSI TC ITS would like to share the following opinions as response to your questions:\n(1)\tDo 5GAA, ETSI ITS, SAE think the issue of improper use of ITS dedicated spectrum within a V2X UE should be solved?\nAnswer from ETSI TC ITS: \nThe issue has been solved. The 5.9 GHz ITS frequency band (5875 MHz \u2013 5905 MHz) is harmonized in European Union for safety-related applications of ITS according to Commission Decision 2008\/671\/EC. Any equipment operating in this band needs to comply with the Radio Equipment Directive (2014\/53\/EU). Radio equipment which is in conformity with harmonised standards or parts thereof the references of which have been published in the Official Journal of the European Union is presumed to be in conformity with the essential requirements set out in Article 3 of Directive 2014\/53\/EU covered by those standards or parts thereof. However, there are also other possibilities to demonstrate the conformity with the essential requirements.\nIt is the responsibility of the market surveillance authorities of the Member States of the European Union to enforce Directive 2014\/53\/EU for products on the European market.  \nWhere the market surveillance authorities of a Member State have sufficient reason to believe that radio equipment covered by Directive 2014\/53\/EU presents a risk to the health or safety of persons or to other aspects of public interest protection covered by Directive 2014\/53\/EU, they carry out an evaluation in relation to the radio equipment concerned covering all relevant requirements laid down in Directive 2014\/53\/EU. Chapter 5 of Directive 2014\/53\/EU laydown the Union market surveillance, control of radio equipment entering the Union market and Union safeguard procedures. \n(2)\tHave 5GAA, ETSI ITS, SAE considered to address the above issue in some fashion?\n\nAnswer from ETSI TC ITS: \nYes. ETSI has developed the harmonized standard EN 302 571 for the 5.9 GHz band, where references of which have been published in the Official Journal of the European Union. It is the responsibility of the market surveillance authorities and the law enforcement agencies to enforce these regulations. \n(3)\tAre 5GAA, ETSI ITS, SAE expecting any assistance from the underlaying layers (e.g., V2X application enabler layer defined in 3GPP TR 23.795) to solve the above issue?\n\nAnswer from ETSI TC ITS: \nNo. ETSI TC ITS considers that incompliance  to regulations or misuse of the dedicated ITS spectrum needs to be addressed and solved through law enforcement. \n\nETSI TC ITS understood that the SA6 questions were related to ITS spectrum management, however one company understood these questions were application and service related, if it was the case ETSI TC ITS invites SA6 further clarify, if needed.\n\nETSI TC ITS would kindly ask 3GPP TSG-SA WG6 to take above opinions into account in the related work.","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":16010,"status":"noted","reservation_date":"2018-10-31 07:48:08","uploaded":"2018-10-31 08:15:08","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA6","Cc":"5GAA, SAE, 3GPP SA1, SA2, SA3","lsoriginalls":"ITS(18)032030r1","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181601.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-181602","title":"LS on Security method negotiation","source":"CT3","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"CT3 would like to ask SA3 regarding the granularity of the security method negotiation for the services exposed by the AEFs.\n\nIn TS 33.122, 6.3.1, it says:\n\n2.\tThe API invoker may send CAPIF-2\/2e security capability information to the CAPIF core function in the Security Method Request message, indicating the list of security methods that the API invoker supports over CAPIF-2\/2e reference point for each AEF.\n3.\tThe CAPIF core function shall select a security method to be used over CAPIF-2\/2e reference point for each requested AEF, taking into account the information from the API invoker in step 2, access scenarios and AEF capabilities.\n\n\nAnd in TS 33.122, A.1:\n\nAEFPSK shall be derived by the API invoker and the CAPIF core function based on Service API interface information and CAPIF-1e TLS session parameters. Length and format of TLS session parameters used for key derivation are as specified in TLS 1.2 [9].\n\n\nQuestion: As an AEF may have multiple interfaces (i.e. multiple IP address and port combinations) exposed to offer services to the API invokers, are the security methods associated with the AEF level or the AEF interface level?\n\n\n2. Actions:\nTo SA3 group.\nACTION: \tCT3 kindly asks SA3 to provide answer to above question.","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":16020,"status":"noted","reservation_date":"2018-11-02 08:22:50","uploaded":"2018-11-02 09:11:14","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA3","Cc":"SA6","lsoriginalls":"C3-186335","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181602.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-181603","title":"LS on API Invoker Onboarding","source":"CT3","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Action","abstract":"1. Overall Description:\nDuring stage 3 work for CAPIF, CT3 found there might have contradicting requirements in SA3 and SA6 thus CT3 would like to ask for clarification.\n\nIn TS 23.222, 8.1.2.2, API information may be included in the onboarding response:\n\nTable 8.1.2.2-1: Onboard API invoker response\n\nAPI information\t O (NOTE 1) \tList of APIs and the types of APIs that the API invoker can access\n\nAnd in 8.1.3, the procedure says:\n\n2.\tThe CAPIF core function begins the onboarding process by verifying whether all the necessary information has been provided to onboard the API invoker, and further initiates a grant process. Successful onboarding results in provisioning API invoker profile which includes identity for the API invoker. The authorization information and the list of APIs and the types of APIs that the API invoker can access subsequent to successful onboarding may also be created. \n\nIn TS 33.122, 6.3.1 Authentication and Authorization:\n\nFor authentication of the CAPIF-1e reference point, mutual authentication based on client and server certificates shall be performed between the CAPIF core function and the API invoker using TLS.\n\u2026\n1.\tMutual authentication based on client and server certificates shall be established using TLS between the API invoker and the CAPIF core function. The client certificate that was provided to the API invoker as the result of successful onboarding is used based on the description in subclause 6.1 of the present document.\n2.\tThe API invoker may send CAPIF-2\/2e security capability information to the CAPIF core function in the Security Method Request message, indicating the list of security methods that the API invoker supports over CAPIF-2\/2e reference point for each AEF.\n3.\tThe CAPIF core function shall select a security method to be used over CAPIF-2\/2e reference point for each requested AEF, taking into account the information from the API invoker in step 2, access scenarios and AEF capabilities.\n4.\tThe CAPIF core function shall send Security Method Response message to the API invoker, indicating the selected security method for each AEF, any security information related to the security method. The API invoker shall use this method in the subsequent communication establishment with the API exposing function over CAPIF-2\/2e reference point, as described in subclause 6.5 of the present document.\n\nAfter successful authentication between API invoker and CAPIF core function, the CAPIF core function shall decide whether the API invoker is authorized to perform discovery based on API invoker ID and discovery policy.\n\nQuestion: SA3 requirement in 6.3.1 mandates that the discovery is performed after authentication and authorization between the API invoker and CAPIF core function (i.e. Security Method Request\/ Response). But SA6 allows the API information to be included even during onboarding (i.e. before Security Method Request\/ Response). If SA3 requirement shall be satisfied, it seems API information in the onboarding response should not include the full API information (including interface details) which will be discovered during discovery later, or maybe just the a list of API types (e.g. RPC type for API 1, 2 and 3 and REST type for API 4, 5 and 6) should be included in the onboarding response.\n\nCould SA6 further clarify \u201cList of APIs and the types of APIs\u201d? Could it be literally interpreted as the Service API information in TS 23.222, 8.7.2.2?\nTable 8.7.2.2-1: Service API discover response\n\n If not, what information should be included for the API information in the onboarding response? \n\n2. Actions:\nTo SA6 group.\nACTION: \tCT3 kindly asks SA6 to provide corresponding answer to above question.","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":16030,"status":"replied to","reservation_date":"2018-11-02 08:22:50","uploaded":"2018-11-02 09:11:14","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA6","Cc":"SA3","lsoriginalls":"C3-186414","lsreply":"S6-181817","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181603.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-181721","title":"LS on Security method negotiation","source":"SA3","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"1. Overall Description:\nSA3 would like to thank CT3 for the LS on security method negotiation.\n\nQuestion from CT3: As an AEF may have multiple interfaces (i.e. multiple IP address and port combinations) exposed to offer services to the API invokers, are the security methods associated with the AEF level or the AEF interface level?\n\nAnswer: Security methods are associated with the AEF level if AEF supports only a single security method for all the services exposed by the AEF. Otherwise, if the AEF supports different security methods on interfaces exposing same or different services, then the security methods are associated with the AEF interface level. \n\nIt is SA3's understanding that both deployment scenarios are possible.\n \n\n2. Actions:\nTo CT3 group.\nACTION: \tSA3 kindly asks CT3 to take the above clarification into consideration for the further stage 3 work.","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":16021,"status":"noted","reservation_date":"2018-11-21 14:31:29","uploaded":"2018-11-21 14:46:03","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT3","Cc":"SA6","lsoriginalls":"S3-183795","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181721.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-181722","title":"Reply LS on Reply LS from CT to SA5 on API specification and API version number maintenance","source":"SA5","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Information","abstract":"1. Overall Description:\nSA5 thanks CT for their LS on API specification and API version number maintenance.\n\nSA5 OAM would like to get the written proposal on the API specification and API version number to be able to consider what impacts it would have to the work in SA5 OAM.\nSA5 Charging has already considered the \"Principles and Guidelines for Services Definition\" TS 29.501 during their stage 3 work on 5G API. SA5 CH expects any new recommendations and guidelines further clarified and concluded by CT WGs to be reflected in a new version of this specification, which could also be considered as much as possible, whenever no issue is identified during the implementation.\n\n2. Actions:\nTo CT group.\nACTION: \tSA5 asks CT to provide the proposal mentioned in your LS so that an evaluation of it can be done in SA5 OAM.","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":17220,"status":"noted","reservation_date":"2018-11-21 14:31:29","uploaded":"2018-11-21 14:46:03","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT","Cc":"CT4, CT3, SA, SA6","lsoriginalls":"S5-187336","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181722.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-181723","title":"Cooperation on Generic Slice Template definition","source":"GSMA","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"LS in","for":"Action","abstract":"1.\tIntroduction\nThe GSMA 5G Joint Activity (5GJA) is responsible for all 5G related items and topics within the GSMA Networks Group (NG). The GSMA 5GJA will work in cooperation with GSMA working groups, GSMA programmes, as well as external organizations. The scope of the GSMA 5GJA focus on, although not limited to, the following topics:          \n\u2022\tUNI for operator-provided communication services (i.e. Voice, Video, messaging) over 5G \n\u2022\tGuidelines for technical aspects of deployment of 5G.\n\u2022\tGuidelines for 5G roaming and interconnection. \n\n2.\tDescription\nThe GSMA 5G Joint Activity would like to draw your attention to the document that defines and provides a description of the Generic Slice Template (GST). The GST is a set of attributes (e.g. supported throughput, supported functionality, provided application programming interfaces (APIs), etc.) that characterize any slice. It contains the attribute names, definitions and units. These attributes can be used by vendors, mobile network operators and slice customers, in addition to other proprietary attributes, if custom slices are desired. By filling the GST with values for all or a subset of the attributes it is possible to describe the structure of a network slice. A GST filled with values is called Network Slice Type (NEST). A NEST serves many purposes:\n\u2022\tVendors can use a NEST to define the features of their products\n\u2022\tVertical Industry customers (slice customers) can use a NEST as a reference to understand the contractual agreements with the network operator\n\u2022\tNetwork operators (slice providers) can use a NEST with their roaming partners, facilitating the definition\n\nMore details regarding to GST and NEST could be found at: https:\/\/www.gsma.com\/futurenetworks\/5g\/5g-network-slicing-report-august-2018\/ and in the document attached that will be taken as the baseline for a GSMA Permanent Reference Document expected to be published next year.\nGSMA intends to continue working in the following areas and would welcome a close cooperation with your organisation:\n\u2022\tGenerating a non-binding Permanent Reference Document (PRD) Note 1 containing the description of the GST.  \n\u2022\tProducing NEST(s) for the 3GPP defined standard slices (eMBB, URLLC, MIoT)\n\u2022\tProducing NEST(s) for customised network slices, e.g. automotive\nNote: Non-Binding Permanent Reference Document (PRD) is an informational guidance and recommendations from and to members and, in some cases, to the wider industry.\n\nACTIONS\nGSMA 5GJA would like to invite 3GPP SA6 to review the GST attributes set and assess if they are sufficient to define a network slice type addressing public safety and railway use cases and requirements. If SA6 believes it is necessary to add attributes to the GST, then  GSMA 5GJA endeavours to include them in the next update of the GST. \n\nMoreover, GSMA 5GJA would like to invite 3GPP SA6 to propose values for the GST attributes so that the NEST can serve public safety use cases.","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":17230,"status":"postponed","reservation_date":"2018-11-21 14:31:29","uploaded":"2018-11-21 14:46:03","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA6","Cc":"3GPP SA, SA1, SA2, SA3, RAN 3 and SA5","lsoriginalls":"5GJA05_110","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181723.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-181729","title":"Reply LS on the application layer support for V2X services","source":"SA4","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"other","for":"Discussion","abstract":"","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":17235,"status":"postponed","reservation_date":"2018-12-01 04:58:09","uploaded":"2018-12-03 14:12:15","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181729.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-181730","title":"LS on moving xMB to TS 26.348","source":"SA4","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"other","for":"Discussion","abstract":"","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":17240,"status":"postponed","reservation_date":"2018-12-01 04:58:09","uploaded":"2018-12-03 14:12:15","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181730.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S6-181731","title":"LS on ROHC support","source":"SA4","contact":"Bernt Mattsson","contact-id":14585,"tdoctype":"other","for":"Discussion","abstract":"","secretary_remarks":"","agenda_item_sort_order":8,"ainumber":"4.1","ainame":"Incoming LSs","tdoc_agenda_sort_order":17245,"status":"postponed","reservation_date":"2018-12-01 04:58:09","uploaded":"2018-12-03 14:12:15","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG6_MissionCritical\/TSGS6_027_WestPalmBeach\/Docs\/S6-181731.zip","group":"S6","meeting":"S6-27","year":2018,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]