
Insights on AIML Data Collection Challenges and Solutions
"Explore the challenges and solutions in AIML data collection, including discussions on feasibility, controllability, and visibility. Key points address UP solutions for various options and the role of MNO in data collection processes."
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Summary on AIML (UE) Data Collection SA2#165 MediaTek Inc. (Moderator) 1
Background Background RAN#105 provided an LS to SA/ SA WGs (see RP-242389, S2-2409600) on AIML data collection, tasking SA WGs to initiate the work and at least for SA WG2 to provide inputs on solutions 1b, 2, and 3 by RAN#106. RAN2 could not reach consensus without input from SA groups on feasibility of MNO full controllability and full visibility (Note 5) for option 1b and couldn t reach consensus on the feasibility of UP solution for option 2 and option 3 (Note 7). Key points to address On feasibility of UP solution for Option 2 and Option 3 On full controllability and full visibility from MNO for Option 1b On full controllability and full visibility from MNO for Option 2 and Option 3 2
Summary of S2 Summary of S2- -2409634/35, ZTE 2409634/35, ZTE O#1: Option 3 is out of SA2 scope, So no needs to discuss the feasibility of Option 3. The controllability of options is up to SA3. O#2: Option 1a is the simplest and fastest way for UE data collection. The OTT server can collect data from UE directly via UP at any time. O#3: Option 2 uses NAS layer for UE training data collection, which may cause signalling congestion in control plan Network Functions(e.g. AMF) if the collection is frequent with large size of training data. However, this problem can be avoided by collecting UE training data in spare time(e.g. during night). O#4: For theFFS/study if and how to handle non-standardized data (i.e. partial visibility), if we put the training data in the container for transfer then it is difficult for operator to decode and monitor whether the training data collected is legal. So the training data should be fully controllable by MNO. O#5: It is not clear about the differences between option 1b and options 1a/2. If the Server for data collection refers to the AF inside CN, then it is same with option 2. If the Server for data collection refers to OTT server, then it is same with option 1a. Some clarifications from RAN2 are needed. O#6: The UP description of option 1b/2 is not clear. Dose it refer to use GTP-U header for training data collection or using DCAF(EVEX) framework? Some clarifications from RAN2 are needed. O#7: If we use PDU session for training data transfer, it is not clear about how to build or select appropriate PDU session with associated URSP rule, IP address, S-NSSAI. P#1: Using option 1a for UE training data collection. P#2: Using option 2 for non-frequent and small size UE training data collection in spare time AND the training data is to be standardized and to be transferred without any container. 3
Summary of S2 Summary of S2- -2409732, OPPO 2409732, OPPO P#1: SA2 only need to focus on study and analysis the feasibility of MNO full controllability and full visibility and the feasibility of UP solution for Option 2 and Option 3. P#2: For Option 2/3, full visibility is guaranteed so no need to have option B/C. For Option 1b) full visibility can be supported for standardized data, but cannot be supported for non-standardized data and also a mix of standardized and non-standardized data. [Moderator: Option B in P2 refers to Partial visibility for partially Standardized Data conent. Option C in P2 refers to no standardized visibility.] MNO has full controllability for Option 1b, Option 2 and Option 3. MNO has partial visibility for Option 1b, and full visibility for Options 2 and Option 3. 4
Summary of S2 Summary of S2- -2409735/36, vivo 2409735/36, vivo Only analyses Option 1b and Option 2. Option 3 is left to SA5 Comparison Table provided for Option 1b and Option 2 (CP/UP). For option 1b, full MNO controllability and visibility for MNO deployed DCAF. Partial MNO controllability and visibility for 3rd party deployed DCAF. For option 2, on controllability and visibility from MNO, the answer is Yes for CP/ UP. For option 2 , on feasibility UP solution, it is technically feasible (similar to CP). Integrity and confidentiality: (Option 1b/ Option 2 UP, out of 3GPP), (Option 2 CP, SBA/ NAS) Privacy, anonymity and user consent: All options (incl. Option 1b - MNO deployed) based on Annex V of TS 33.501. Note: Option 1b - 3rd partly deployed is out of 3GPP. Efficiency and extensibility: (Option 1b, TBD), (Option 2 CP/UP, better if DCCF/MFAF used) 5
Summary of S2 Summary of S2- -2410058/59, LGE 2410058/59, LGE O#1: For option 1a, since the UE data collection is outside the MNO, Controllability of MNO on data transfer and Visibility of data contents in MNO cannot be satisfied. O#2: For option 1b, mechanism defined in Clause 6.2.8 of TS 23.288 can be leveraged. Controllability of MNO can be achieved by reusing the DCAF architecture in TS 26.531 (inside the MNO). Visibility of data contents in MNO can be by defining data format like data reports in the DCAF defined in TS 26.532. O#3: For option 2, NAS message has limited message size. This has limited extendability and can cause signalling congestion. Using UP solution of option 2 can be considered similar to option 1b. O#4: For option 3, the discussion is mainly up to SA5. P#1: Considering the impact on the existing specification and to ensure the requirements agreed by RAN, use a solution based on option 1b, which leverages the existing data collection from the UE application defined in TS 23.288. 6
Summary of S2 Summary of S2- -2410118/S2 2410118/S2- -2410210, Nokia et al. / InterDigital 2410210, Nokia et al. / InterDigital C#1: A UP approach is feasible and can be developed by SA2 should RAN conclude on option 2. The CP and UP approaches are not mutually exclusive. The two approaches can coexist for the same use case, with configuration of data collection via CP, and data transfer either via CP or UP depending on the volume of data to be collected. Note SA2 also does not see any issue with developing a UP solution for option 3 in coordination with SA5 should RAN decide that this is the way to go for UE data collection for UE side model training. C#2: Option 1b does not allow full controllability on the data collection process nor full visibility on the collected data. C#3: Option 2 and option 3 allow full controllability on the data collection process and full visibility on the collected data. 7
Summary of S2 Summary of S2- -24010137/38, Qualcomm 24010137/38, Qualcomm O#1: It is possible to reuse the Data collection from the UE Application defined in clause 6.2.8 in TS 23.288 with further enhancements to support option 1b. O#2: It is feasible to support the MNO full controllability and full visibility for option 1b. SA2 need further study on how to tailor and enhance the existing solution to support 1b based on RAN s requirement. O#3: If the first termination entity is the LMF, both CP and UP solutions are feasible to support UE data collection for AI/ML based positioning. The existing security and user data privacy procedure in TS 23.273 can be reused for option 2. The MNO controllability and visibility for both CP and UP solutions are feasible. The LPP protocol is used for data collection for both CP and UP solutions. SA2 needs to study the enhancement to support AI/ML based positioning feature based on the existing procedure defined in TS 23.273. O#4: For CSI and beamforming use cases, there is no existing network entity in the 5GC to support the UE data collection termination and there is no existing procedure to support UE data collection via either CP or UP connection. SA2 needs to study which network entity is the first termination entity in 5GC and how to support the UE data collection procedure via either CP or UP solution for option 2 to fulfil RAN s requirements. O#5: It is proposed to remove the UP solution from option 3 and that the detailed technical analysis is to be discussed in SA5. 8
Summary of S2 Summary of S2- -2410268, CATT 2410268, CATT For option 1b (if the server for data collection for UE-side model training is a trusted AF in the MNO domain) and UP solution for option 2, MNO full controllability and full / partial visibility of UE-side data collection for UE-side model training cannot be supported by the existing specifications or small enhancements to the existing specifications. Further study is required, taking into account also the feedback from other WGs (e.g. SA5). In option 1b, if the server for data collection for UE-side model training is outside the MNO domain, MNO full controllability and full/partial visibility of UE data collection cannot be achieved without SLA. The feasibility of UP solution for option 3 is up to SA5 to discuss and decide. The CP solution for option 2 also needs further study considering the impacts to NAS signalling, 5GC NF services and possible impacts to the interfaces between 5GC and NG-RAN. To avoid the impacts to 5GC, the CP solution for option 3 is preferred for UE-side data collection for UE-side model training, if supported and specified in Rel-19. 9
Summary of S2 Summary of S2- -24010276/77, Samsung (1/2) 24010276/77, Samsung (1/2) P#1: SA2 asks RAN2 for further clarification on Controllability of MNO on data transfer, including (i) detailed scenario for initiating, terminating, and fully managing data transfer in each use cases, (ii) which entity is required to perform those operations (i.e., should have such controllability), and (iii) what kinds of management are required to achieve fully managing data transfer P#2: Controllability of MNO on data transfer for Option 1a and Option 1b should be marked as Full controllability is not possible, FFS: level of controllability . P#3: Description onsolution for network controllability of Option 3 should be updated as follows: Via RRC procedure or FFS additional procedure between OAM and gNB P#4: SA2 should ask SA1 for the following questions on options for visibility of AIML data: i) Whether is any requirement for visibility of AIML data collection specified? If yes, please provide details and how the possible options (Full visibility, Partial visibility, and No visibility) can be associated with the existing requirement ii) If no to Q1, what is SA1 s view on the definition of visibility for AIML data collection and on what level of visibility is required? 10
Summary of S2 Summary of S2- -24010276/77, Samsung (2/2) 24010276/77, Samsung (2/2) P#5: SA2 should ask RAN2 for further clarification on the visibility including: i) Which entity should have visibility ii) Whether the visibility is considered as fully guaranteed from RAN2 perspective only if the data content is standardized, although it may not be decoded by the entities in the MNO domain iii) Whether Partial visibility for partially standardized data content means, e.g., whether the data content is partially standardized, or whether the standardized data content can be partially decoded in the MNO domain, etc. P#6: SA2 should ask SA5 to provide views on Option 3 in RP-242389/S2-241048 regarding feasibility of UP tunnel establishment toward OAM entity, its usage on AIML data collection, and any potential impacts on SA2 stage 2 level architecture and procedures. P#7: SA2 should ask SA3 to provide views on whether the data collection options are feasible to satisfy the requirement described in RP-242389 [1], and any potential security issue that may require stage 2 level architectural impact. P#8: SA2 should ask SA3 to provide views on whether the data collection options are feasible to satisfy the requirement described in RP-242389 [1], and any potential security issue that may require stage 2 level architectural impact. [Moderator: Seems duplicate of P#7] P#9: It should be remarked that Option 2 and Option 3 are not futureproof and extendible. 11
Summary of S2 Summary of S2- -2410444, Apple 2410444, Apple It is proposed to agree the following architecture principles for user consent and privacy management for data collection and exposure through 5GC using either option 1b or option 2. P#1: The standardized data refers to the results of measurements performed by the UE in response to a measurement configuration provided by the network. P#2: 5GC provides an interface to AFs to provide requirements on measurement configurations for AIML operations. P#3: The purpose of measurement configuration (e.g., UE side model training) and the identity of the requesting AF should be informed to the UE. P#4: 5GC NF (responsible for data collection) enforces user consent check for collection and exposure of data outside of MNO domain. P#5: 5GC NF (responsible for data collection) applies privacy protecting methods as required before data exposure. 12
Full Summary Full Summary Option 1b Option 2 Option 3 UP Solution Feasibility N/A Yes: 11 Yes: 9 (SA5 coordination) No: No: Conditional: 1 (PoS) Conditional: 6 (SA5) MNO Full Controllability Yes: 3 Yes: 11 Yes: 10 No: 11 No: No: Conditional: 1 (DCAF deployment) Conditional: 1 (CP only) Conditional: 4 (SA5) MNO Full Visibility Yes: 2 Yes: 11 Yes: 10 No: 11 No: No: Conditional: 1 (DCAF deployment) Conditional: 1 (CP only) Conditional: 4 (SA5) Integrity/ confidentiality Outside 3GPP: 1 CP (NAS): 1 , UP: (Outside 3GPP): 1 SA3: 1 SA3: 1 SA3: 1 Privacy, User consent Yes: 1 Yes: 2 Yes: 1 Conditional : 1 (DCAF deployment) Extensibility TBD: 1 Yes: 1 Yes: 1 No: 1 No: 1 13
Ways Forward Ways Forward WF#1: A UP approach is technically feasible and can be developed by SA2 if RAN concludes on Option 2. Mod#1: Good to clarify to RAN that the solution is dependent on exact termination point in CN and also use case. Mod#2: Good to clarify to RAN that UP and CP approach are not mutually exclusive. Configuration can be CP while data transfer can be CP or UP depending on the volume of data / use case. Mod#3: Good to clarify that technical feasibility is separate from the level of work required dependent on Mod #1/ Mod#2 WF#2: No issue from SA2 to support UP approach for option 3 but this requires coordination with SA5 if RAN concludes on Option 3. WF#3: Option 1b does not allow full controllability and does not allow full visibility on the collected data in all deployments. Mod#4: WF#3 is based on majority views gathered so far and requires further discussion. Option 1b is deployment dependent. WF#4: Option 2 and option 3 allow full controllability and full visibility on the collected data. Mod#5: Good to clarify to RAN that SA2 analyses in WF#3 and WF#4 are based on full controllability and full visibility . RAN to advise if any other analyses is required beyond this. Mod#6: Aspects related to Data Integrity, Confidentiality, Privacy and User Consent can be left for SA3 to respond to RAN. Mod#7: Aspects covered in limited proposals only are not covered in WFs. 14