[{"name":"R5-197721","title":"Device Under Test Configuration for OTA Antenna Performance Assessments","source":"GCF SG ITAOTA Task Force","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"1. Issue\nLate last year GCF identified that evolutions and enhancements to Antenna and RF Front End technologies used in Smartphones, means there are a number of circumstances which can lead to measurement error or inaccuracies if the 3GPP method for measuring OTA Antenna Performance is strictly adhered to, and no account is taken of these technologies within the configuration of the Device under test or test environment.\nIn particular, the following issues have been identified by GCF:\n2. GCF Task Force recommendations\nGCF has over the last 9 months been running a task force to quantify, assess and make recommendations in relation to the above, so that we can ensure GCF Antenna OTA conformance and performance measurements continue to be of value to the industry.\nCurrently the task force position in relation to the above issues is as follows:\n1 TAS - Adopt a similar method of measurement to that recommended by CTIA in their OTA test plan, e.g. measure TRP for each TX antenna separately, and then provide a combined or aggregated set of results based on the best TRP values obtained.\n2 Dynamic Tuning \u2013 As GCF is providing a \u2018Global\u2019 certification we feel it unrealistic and uneconomic to measure a device in Optimised state, as this would involve multiple set of results for each device to reflect the potential different states of Optimisation based on relevant combinations of location, MNO, attached band etc.\nTherefore, the GCF TF has recommended that GCF results will represent minimum anticipated performance for a device. We believe this offers value to the industry and complements bilateral testing between OEM and MNO (which will provide Optimised performance results for that MNO\u2019s core operational bands).\nTo achieve this \u2018non Optimised\u2019 state for the DUT, GCF is recommending that no dynamic tuning is triggered, except where self tuning of the RFFE is relevant to the attached band. e.g. for GCF no account taken of location, MNO or other external factors for the DUT.\n3 TX Power Backoff \u2013 The Task Force initially recommended that TX power backoff must be implemented for BHH mode to ensure accurate and representative TRP value is established. The only intervention required here is to ensure that the mechanism to trigger TX power backoff is activated whilst the DUT is in the chamber, e.g. the IR or proximity sensors needs to be activated (something we understand the Phantom head will not always do)\nHowever a number of OEM have concerns that this configuration of the DUT would invalidate the 3GPP method for measuring TRP, and so think TRP should be measured without implementing the device Power Backoff algorithm, this would require specific intervention to ensure the TX power being used is set to maximum.\nThis has caused concerns for some MNO\u2019s who question how, even with provision by the OEM of a table of backoff values, we could be sure this represented a true \u2018minimum \u2018expected\u2019 TRP, as it is possible that without RFFE optimisation (point 2) SAR backoff would not be implemented. Thus we would not know when to apply a Backoff table value or not.\n4 Variable TX power \u2013 The Task Force has not been able to find a recommendation on how to ensure accurate measurement of TRP in devices that employ this technology.","secretary_remarks":"","agenda_item_sort_order":17,"ainumber":"4.5.3","ainame":"\tOther open issues from joint sessions - original A.I. retained","tdoc_agenda_sort_order":77210,"status":"noted","reservation_date":"2019-10-15 13:03:13","uploaded":"2019-10-16 17:38:49","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"S-19-149_LS to 3GPP on Device Under Test Configuration for OTA Antenna Performance Assessments","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-197721.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-198256","title":"PRD17 update proposal","source":"Rapporteur (BlackBerry)","contact":"Claude Arzelier","contact-id":14266,"tdoctype":"discussion","for":"Approval","abstract":"For a closed WI, if a subclause is not listed in the prd17 (because the corresponding WI was closed before the creation of the prd17, or because the subclause is not a test\/general test procedure specifically introduced for a WI), general practice is that if the WI code of a change is known, it is added on the CR coversheet after TEIn_Test (for visibility of the feature impacted).\nHowever, the current phrasing of the prd17 may be read as restrictive in this area, i.e. actually forbidding to add the original WIC if it is known.\nIn addition, there is no text in RAN5 that indicates what to do if the CR updates something else than a test\/general test.\nThe proposal is hence to allow to add the original WI Code if it is known (and not listed in the prd17).\nNote that this proposal is not suggesting to change the scope of the prd17 with regards to the what it lists (it will keep listing only tests\/general test procedure that are specifically introduced for WIs after they are closed).\n\n2\t Specific text proposal\nUpdate the top of the prd17 text as below:\nFor Prose\/Applicability\/TTCN CRs on closed Work Items:\n- If the WI code is known or listed with a corresponding test case below, the CR cover sheet shall use the 'TEIn_Test' WI code where 'n' refers to the applicable release of the change, followed by the associated WI code, i.e. as 'TEIn_Test, WI code\u2019.\n- Otherwise, the CR cover sheet shall use the 'TEIn_Test' WI code (where 'n' refers to the applicable release of the change).\nNote: Title of test cases in this document is only indicative and may not reflect the latest status in the source test specification. Please refer to the relevant test specification for the latest updates to titles.","secretary_remarks":"","agenda_item_sort_order":17,"ainumber":"4.5.3","ainame":"\tOther open issues from joint sessions - original A.I. retained","tdoc_agenda_sort_order":82560,"status":"approved","reservation_date":"2019-11-06 16:51:54","uploaded":"2019-11-07 10:31:31","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-198256.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]