welcome to this presentation on the 3gpp tr22 876 version 19.10 which focuses on the study of AIML model transfer Phase 2 for release 19 this study focuses on the application and optimization of AIML within the 5G system specifically looking at the transfer of AIML models between different entities in the network I'd like to point out quickly here how phase one is different from phase two and what are the usual various phases of these kinds of studies phase one study usually focuses on initial exploration use cases basic requirements and GAP Gap analysis phase one outcomes include visibility confirmation and initial recommendations phase two study just like the document here focuses on Advanced exploration detailed use cases enhanced requirements comprehensive Gap analysis proposed Solutions and performance indicators kpis and the outcomes for phase two usually include Advanced recommendations and detailed Technical Solutions as of my knowledge the cut off date for this topic was back in October of 2021 there is no official documentation or announcement of phase three or phase four studies on AIML model transfer within the 3gpp framework however based on the progression from Phase 1 to phase two potential future faces could be forthcoming over the next 21 slot we will delve into various aspects of this study exploring its relevance to Modern ARR applications and the enhancements it brings to the 5G ecosystem this 3gpp specification encompasses a rich tapestry of key topics and Concepts I've distilled its Essence into a concise yet hopefully comprehensive presentation featuring 11 created agenda items these are explored across 23 crafted slides which Incorporated the majority of the specifications original diagrams let me go through the agenda items here quickly um first is scope and objectives AIML operations overview proximity based work task off loading local AIML model split on Factory robots AIML model transfer management 5gs 5G system assisted transfer learning direct device connection assisted Federated learning asynchronous Federated learning distributed joint interface for 3D object detection Consolidated potential requirements and kpis lastly is the conclusion and recommendations slide let's begin the scope of this technical report is to study the use cases and identify the functional and performance requirements necessary for efficient AIML operations using direct device connections so the this is using direct device connections we'll explore further on this um um on on this uh concept here our study focuses on three main areas distributed AI inference distributed decentralized model training and conducting a gap analysis of the existing 5G system mechanisms to identify areas needing enhancement the ultimate goal is to ensure that the 5G system can support these AIML operations effectively enabling applications such as autonomous driving robot remote control and video recognition in the initial phase we identified three primary types of AIML operations splitting operations between AIML and points Distributing and sharing AIML model models and data over the 5G system and utilizing distributed or Federated learning phase two of this study further explores how direct device connections can enhance each of these operations providing more efficient and effective AIML processes by leveraging direct device connections we aim to improve the communication capacity and coverage leading to better task of loading and more efficient AIML training and inference okay first big topic here is proximity based work task of loading what is it as the name implies it's about offloading work from one device to another proximity based work task offloading allows a device with low computation capacity to offload offload tasks to a nearby device leveraging direct device connections this approach helps manage computation loads and improve performance without necessarily increasing data rates the condition for this use case include the device using an AI model like alexnet this is an example here alexnet for image recognition and having predefined alternative splitting points during the surface flow the task off loading process involves the device discovering a nearby device establishing a direct connection with this nearby device and transfer ing intermediate data this ensures reduced computation load on the original device while maintaining qos parameters existing features support direct network connection modes but we need new requirements for um proximity based work task offloading um to complete and then implementation comes afterward we don't have a lot of requirements uh or all the requirements as of yet but I'm sure people are working on it or have worked on it but U made uh their solution proprietary okay let's take a look at this diagram uh showing the Alex net model for image recognition this diagram I'm going to go uh um look at this diagram in depth a little bit so stay with me this diagram illustrates the layer level computation and communication resource evaluation for an Alex net model used in image recognition you can see the mobile device on the left the little icon there the mobile device um that's the device performing the initial computation for image recognition using the alexnet model look to the right the right side you can see the network server the server that take over part of the computational tasks from the mobile device to reduce the computation load on the mobile device then take a look at the candidate split points there are four four of them on top on the top of uh the histogram um these are specific points in the neuron Network where the computation can be split between the mobile device and the network server now look at the Y AIS on the left which indicates the layer latency the latency associated with Computing each layer of the Alex net model on the mobile device the Y AIS on the right indicates the size of output data the size of the output data or the of the data outputed by each layer which needs to be trans ited if the computation is offloaded to the network server now the xaxis on the bottom layers the um the x axis that is representing the different layers in the Alex net model including convolutional layers C NV Con in short pulling layers pull in short and fully connected layers f c in short you can see those acronyms written sideways uh near the bottom there on this histogram and then the final layer called the soft Max layer so xaxis um again includes all of these layers now the split points the candidate let's take a look at the split points zero uh starting from the left to the right this represent the initial input to the neuron Network 0 Z there is no latency at this point as no computation has been performed yet the size of the input data is relatively small next to the candidate split point1 after pull one layer this is after the first pooling layer the layers up to this point conf one and pool one show significant latency indicating substantial computational effort the size of the input data from po one is larger compared to the input reflecting the intermediate data generated after initial layers of processing candidate split point two after pool two layer this is the second pulling layer this is after the second pooling layer the cumulative latency up to this point includes the latency from conf 2 and pool 2 which is still substantial but less than the first split point the data size here is smaller than at split point one indicating some reduction due to pooling operations candidate split. three after pull five layer this is after the fifth pulling layer the cumulative latency up to pool five is lower than the previous split points reflecting reduced computational demand as the network progresses the data size is significantly reduced making it more visible to transmit intermediate data if offloading is necessary now the final uh split point the split point 4 the candidate split point 4 uh final output this is at the Network's final output stage the cumulative latency includes all previous layers and the fully connected layers the size of the final output data is minimal as it represents the condensed classification result so for computational load management we need to select appropriate split points that is the computational load on the mobile device can be managed effectively so that you know the load the computational load can be managed effectively on the mobile device for example if the device has low computation capacity or battery for example your mobile phone is low in battery earlier split points can be chosen to offload more computation to the network server the size of the input uh sorry output data at at each split point in influences the data transmission requirements later split points result in smaller data sizes reducing the transmission load on the network we need to also consider latency uh there's latency considerations the latency associated with each layer impacts the decision on where to split the computation lower latency layers can be processed on the mobile device while high latency layers can be offloaded to reduce the overall processing time okay that's all uh I'd like to say for this diagram I think it it should be quite self-evidence what it is trying to convey moving on to the next diagram this is this is also about Alex net the Alex net model uh looking at it from a slightly different angle uh not not a histogram now this is really sort of a flow how how things flow uh this diagram illustrates two scenarios related to task offloading for AIML inference using uh again an alexnet model uh also for image recognition the two scenarios are if you look at the bottom there um there um as one scenario is called No task off loading as the name implies the mobile device UEA uh in in this instance performs all computations up to a certain layer and sends intermediate data to the application server look at the top there application servers on the top of this picture um sending sending the intermediate data to the application server for uh further processing the the B scenario here task of loading by ueb uh it it is describing the mobile device UEA offloads part of the computation to a nearby device in this case UE B using a direct device connection synonymous to S side link you heard you heard of the word sideling and not a lot sing is essentially uh device to device direct device connection which then completes the computation and sends intermediate data to the application server in scenario a no task of loading the mobile device which is UEA performs the computations for layers 1 to 15 of the alexnet model after processing layers 1 to 15 UEA generates intermediate data which is 0.02 megabytes per frame um it's written very small on the picture but I I think you may be able to see it it's it's still pretty clear um 0.02 megabytes per frame on scenario 8 I'm still talking about scenario a the intermediate data is transmitted to the application server via the NG Rand which is next Generation radio access network using The UU interface uu interface I'm sure all of you know what what that interface is knowing about 5G architecture the required Uplink data rate for transmitting this intermediate data is 4.8 megabits per second which is much lower than scenario B you'll see the application server then performs the computations for the remaining layers 14 to 24 to complete the AI inference task so that's scenario a what about scenario B scenario B is a task of loading by ueb so in scenario b u E A performs the computations for the initial layers 1 to four of the Alex net model due to Resource constraints for example low battery uh UA offloads the computation of layers 5 to 15 to a nearby device ueb the offloading is done using a side link which is again direct device connection between UEA and ueb UE receives the intermediate data from UEA in this case will be 0.27 megabytes per frame and performs the computations for layers 5 to 15 after completing its computations ueb transmits the intermediate data to the application server via the ngen using The UU interface the required Uplink data rate for transmitting this intermediate data from ueb is 65 megabits per second the application server then performs the computations for the remaining layers 16 to 24 to complete the AI in inference task so I want to point out UEA handles a significant computational load in scenario a which can be taxing on its resources as especially if the device has limited computational power or battery life like your your your your smartphone in scenario B the computational load on UEA is reduced by offloading part of the computation to UE B enabling UEA to conserve its resources the amount of intermediate data generated and the required Uplink data rate differ significantly between the two scenarios in scenario a the data size is smaller 0.02 megabytes per frame resulting in a lower Uplink data rate 4.8 megabits per second scenario b as we already stated the data size is larger 0.27 megabytes per frame versus 0.02 megabytes per frame in scenario a due to offloading resulting in a higher Uplink data rate which is 65 megabits per second versus scenario is 4.8 megabits per second so you can see the significant differences uh here between the size of the frame per frame and the Uplink data rate scenario B demonstrates the utilization of sidelink communication which is the direct device Communications to offload task between devices which can optimize Network usage and reduce the load on the uh Anan the the radio Access Network itself this approach leverages so-called proximity based computation enhancing the overall efficiency of the AIML inference process we have to think about the quality of service task offloading requires careful management of qos parameters to ensure that the endtoend latency and data rates are maintained at acceptable levels in scenario B the Qs parameters on both side link and The UU interface need to be adjusted to accommodate the increased data rate and ensure simless task of loading and data transmission in both of these scenarios the application server finalizes finalizes the AIML inference by process ing the remaining layers of the alexnet model the server must handle the intermediate data efficiently regardless of whether it comes directly from UE EA or from ueb after task of loading it doesn't really care you still have to handle the the intermediate data efficiently all right that's about all we need to look uh talk about next slide is about out another use case which is using the same concept in a modern factory setting autonomous robots assist human operators by performing tasks and ensuring safety when a robot's batter is low part of this a ml model can be offloaded to another robot or a service hosting environment this slide covers the detailed description service flows and pre and post conditions of this use case for the service flows that's exactly like what we talked about in the previous slide how the data being uh transferred uh the intermediate data and how the flow works so this is sort of a a narrative um uh rep uh uh repeating some of the things we already said so uh we also on this slide we have pre-imposed conditions of this use case the preconditions include multiple robots sharing aimo models and sensors while the surface flows involve offloading tasks to maintain efficiency post conditions ensure continuous operation despite low battery levels and existing features like proximity service support these operations there is no comprehensive requirements written up yet on how to enhance data transfer capability for efficient AIML model splitting and uh even if it exists it's not on this spec it will be on on a separate uh specification next is amm model transfer management AIML model transfer management involves using direct device connections to relay or store AIML models ensuring stable and reliable model transfers the preconditions include the mech storing various AIML models the mech Mech MEC is an acronymed for multi access Edge Computing or mobile Edge Computing they're the same MEC Mech mobile um multi access as Computing um storing various AI ml models and high quality plans for volunteer ues the service flows detail the mo model transfer process including qos acceleration and network exposure for volunteer ues post conditions ensure continuous AR Services augmented reality services and improved model transfer processes existing features support position related data availability and relay UE selection again there there are no comprehensive requirements written up on this yet um um but I'm sure that there are already implementations uh based on some proprietary requirements based on use cases there's a picture to further illustrate what aimm model management through direct device connection how it works it's it's pretty simple actually let's take a look this diagram illustrates the AIML model transfer management process through direct device connections um and and it's I think section six on the spe if you want to refer back uh for more information it's demonstrates how aimo models are managed and distributed among ues with the assistance of volunteer ues operator services and third party control so those are the elements of components of the diagram um so let's take a look at the blue arrows first the blue arrows indicate model transfer path these are path the arrows indicates the path through which the AO models are transferred between devices the green dashed lines represents the control mechanism for managing the transfer of AO models so those are model transfer controls screen Dash lines those orange double-sided arrows um represents volunteer uee selection uh showing the process of selecting volunteer uees to assist in the model transfer so what does each of these elements um do for the operator Mac multi access Edge Computing operator Mac uh it is responsible for storing various AIML models and facilitating their transfer to uees which I already said it this already earlier uh it also interacts with the operators 5 uh GC which is 5G core and the third party to manage the distribution and control of AIML models the 5G core network plays a crucial role in coordinating the mech volunteer you East and regular ues it's like a coordinator function in the 5G core Network in the 5G core element in the 5G uh Network it ensures the models are transferred efficiently and securely for this third party the third party um for example could be a service provider or application developer sets the policies and requirements for the AIML model transfer so therefore function is to set policies and requirements it also communicates with the operators Mech and 5G core to manage and control the transfer process volunteer ues are devices that are well connected to the Bas station and are selected to assist in relaying AIML models to other uees these devices these volunteer ues act as intermediaries to ensure stable and reliable mobile transfers especially when direct communication with the basis station is challenging for some uees uees are actually the end devices that require AI ml models for various applications such as AR headsets augmented reality headsets autonomous vehicles or smartphones they receive the AIML models either directly from the Mac or through volunteer uees the third party as we said earlier sets the policies and requirements for model transfers and then communicate them to the operators 5G core and Mech the 5G core and Mech work together to manage the control mechanism of the model transfers The Operators 5G core based on the policies set by the third party selects volunteer uees that are well connected to the network these volunteer uees are chosen to help relay the AIML models to other ues ensuring efficient and reliable distribution so I I think I covered all the elements here and what what exactly this is showing us um okay that's all I I wanted to describe on this picture the next is assisted transfer learning transfer learning leverages Knowledge from pre-trained Models to improve training efficiency and accuracy by using direct device connections privacy concerns can be mitigated as the model is transferred directly between user devices preconditions include intelligent driving services and agreements for AIML model sharing the service flows cover the model transfer process and fine-tuning based on local data post conditions ensure efficient model acquisition and enhanced intelligent driving Services existing features support indirect network connections and exposing information to third parties again we need some requirements or newer requirements uh to be established so that we can have effective transfer learning in 5G systems so here's a picture that follows uh this topic the model transfer learning what it is illustrating here is the concept of 5gs 5G system assisted transfer learning for trajectory prediction between two user equipments two uees especially or specifically here uh it is clearly stated ue1 and ue2 the process depicted involves transferring a pre-trained AIML model from ue1 to ue2 where it is then fine-tuned based on local data from ue2 this method leverages the 5G Network to facilitate the model transfer efficiently the device that initially uses and hals the pre-trained AI model is ue1 the device that receives the aimo model from ue1 and fine-tunes it based on its local data is ue2 the 5G Network supports and facilitates the model transfer processes between ue1 and ue2 um it's pretty clearly stated here so U1 has an aim model that has been pre-trained and used for a specific task such as again trajectory prediction in intelligent driving that's one use case of many many use cases its functionality is using this model which has been pretrained on data uh that is relevant to the environment and use cases specific to ue1 then this model in ue1 is transferred from ue1 to ue2 through the 5G Network the transfer allows ue2 to leverage the pre-trained model from ue1 which can significantly reduce the training time and computational resources needed for ue2 to achieve a similar level of performance the beauty of this is and um I said this already the ue2 after data is being the model is transferred to E2 it can then adjust the model um based on its local data based on the local data that reflects the environment that is unique to use ue2 so this fine tuning based on local data is very beneficial after the model transfer um what the what do a fine tuning does it simply involves adjusting the model parameters to better fit the specific environment and use cases of ue2 and the outcome would be that the fine-tuned model being optimized for the conditions and requirements of ue2 providing or or improving its performance and accuracy so this is a simple enough diagram next is assisted Federated learning Federated learning which is a slightly different concept A still is rather simple as the name implies you do learning collaboratively um with direct device connections and this allows devices to share training results uh locally not training model now this is sharing training results locally improving model accuracy and reducing Reliance on a central server preconditions include an application server for Federated learn learning and transmission delay requirements the service flows detail the decentralized average method where local model updates and are are aggregated globally post conditions ensure continuous model training and optimized Federate learning performance we'll have a picture full of this to explain further existing features support monitoring Network resource utilization and predicting Network condition changes again we need good written requirements uh if we want to enhance Federated learning through direct uh device connections that is yet to be worked on and people are publishing uh what what their uh specific requirements are based on use cases so here here is the diagram that will explain further the concept of Federated learning FL in short with a decentralized average method specifically using the Lacy Metropolis algorithm Lac Metropolis algorithm uh uh if you want to look at the details Google it as I always say all the information is at your fingertips if you want to learn more about any of these you you can just look look up in the from the internet so this this Lacy Metropolis algorithm um is one one of the two um methods the diagram indeed here compares the the performance of the original appal original Federated learning with the Federated learning using this La Metropolis method in terms of identification accuracy over the number of learning steps or learning iterations the decentralized aaging method aims to enhance the performance of Federated learning by reducing communication overhead and enabling more devices to participate in the learning process so here we have on the diagram device a and device B these devices participate in the FL process I'm I'm going to say FL process meaning Federated learning process okay so device a and device B participate in the F process using the Lacy Metropolis algorithm the communication paths represent and we have two of them here uh these communication paths represent the data transmission between devices and the central server which is the original FL and then between devices themselves which is using the Lacy Metropolis FL those are the two the distances between devices are indicated showing the range of communication so we are looking at a uh performance graph this is a performance graph uh essentially Y axis represents uh identification accuracy the accuracy of the model in identifying or classifying data xaxis represents the number of steps or iterations in the learning process the red dashed line indicates the original LL the performance of the traditional FL method the black solid line represents the performance of the Federated learning method using the Las Metropolis algorithm we are comparing the two the original and the the FL using the lace Metropolis Sol uh Metropolis algorithm and and that is represented by the black solid line so take a look at the two communication paths right the the original LL is green it's green in color on the top near the top there um so in the original FAL devices transmit their local model updates directly to the central server the central server Aggregates these updates and sends back the global model this method relies heavily on the central server and requires all devices to communicate with it which can lead to high communication overhead and delays as you can imagine especially for devices with poor connectivity the other path purple in color you can see uh the FL with Lacy Metropolis is the purple path the purple path indicates devices commun unicate with each other to share their local model updates the lasc Metropolis algorithm is used to aggregate these updates in a decentralized manner this method reduces the Reliance on the central server or getting rid of it altogether the it doesn't not go to the central server and allows devices to update their models more efficiently by sharing updates with nearby devices the communication paths and distances between between devices show the decentralized nature of this approach enabling more flexibility and reducing the communication burden on the central server there are the two two different lines as as we talked earlier the red dashed line and the black solid line the red dashed line which indicates the identification accuracy of the original F method as you can see it increases steadily with the number of learning steps but it plateaus at around 0.85 right um You you can see it it's not that small it plateus around 0.85 the performance is limited by the communication overhead and the need for all devices to synchronize with the cental server that's pretty taxing now the black solid line that's that's FL with Lac Metropolis the identification accuracy of the FL with Lacy Metropolis method increases more rapidly and reaches high accuracy levels plateauing at around 0.89 the difference is not that crazy but if you look at the inset graph it highlights the difference in performance between the two methods showing that the laser Metropolis method consistently outperforms the original FL method in terms of identification accuracy and we know the reason why right we just talked about the reason why of the because of the overhead this Improvement is due to the decentralized averaging method which allows for more efficient communication and aggregation of model updates enabling more devices to participate in the learning process so there are many use cases um image recognition is one use case that is uh being used throughout this specification but you can think of uh all the others I'm not going into more use cases if you want more uh for reference you can look up the spec but the concept is is exactly the same using what we just described that's that's the idea of assisted Federated learning moving on this is even a simpler uh diagram but we'll take a quick look at it this diagram illustrates scenario where two Bob and Alex Alice performed decentralized Federated learning FL using direct device communication by passing the central application server you can see the two big rack crosses here indicating the communication between Alex and Bob uh are between each other and not Bo bothered to go up to the application server this approach is particularly useful when the ues have poor network connectivity to the central server but can communicate directly with each other with other devices so this is that's what it is um I'm not going to talk more because we already know what the application server does and um what the two are doing uh how they transfer models okay so it's a very simple picture next let's talk about asynchronous Federated learning versus synchronous this is asynchronous Federated learning aynl um as is the acronym it enables you e to report results when ready when it's good and ready it will just report the results without waiting for all devices to synchronize this method is more resilient to varying Network conditions and device capabilities preconditions include the availability of direct and indirect network connections and relaxed communication requirements the service flows describe the asyn FL process where relay ues determined qos for member ues so there's a a new entity here relay U is uh doing something determining qos for member ues so we'll take a look at a picture later to further understand post conditions ensure efficient model training and proper charging for indirect communication existing features support aggregator qos qualitive service and exposing information to third parties again we need new requirements to be established for this um if we want to fully support asfl via direct device connections here's the picture uh another simple picture if you if you look at it carefully it illustrates the concept of a SFL within a group based setup it shows how member uees can perform Federated learning with a help of a relay uee look at the middle in the middle of this picture there's a relay UE pointing to ue1 which acts as the relay UEI so this picture shows how member ues can perform Federated learning with the help of a relay uee especially in scenarios where some uees are in areas with bad network coverage the diagram highlights the communication flow between the parameter server relay U and member uees the parameter server is the the central entity responsible for aggregating the model updates for member uees and distribu the global model back to them the relay uee is a special UE uh ue1 here and it's designated designated to assist other ues that have poor network connectivity it acts as an intermediary to relay data between the parameter server and other uees the ues participating in the Federated learning process are called the member ues some UE are in are with good coverage While others are in areas with bad coverage the asfl concept really um is just about Communications between member uees it represents the asynchronous Federated learning process where uees share updates with the parameter server and other ues without waiting for synchronized updates you can imagine it's much more efficient this way the role of the parameter server collects model updates from the member ues and Aggregates them to update the global model it then distributes the global the updated Global model back to the member uees or through the relay uees to the other uees the server communicates directly with uees that have good network coverage and in indirectly with with those in bad coverage through the relay UE e so it's pretty clear hope you follow oh I don't know if I have jumped a diagram um but we can take a look at this uh this is a diagram illustrating the concept of joint inference among multiple vehicles for 3D object detection enabling enhanced situational awareness and safety in autonomous driving scenarios the vehicles collaborate to share and process data leading to a more accurate and comprehensive object detection so the idea is very simple we have um vehicle one here a vehicle equipped with AI and sensors for object detection we have third part vehicle which is another vehicle involved in the joint inference process we have these other vehicles which are simply additional Vehicles contributing to the 3D object detection task so how how does this object detection come about each vehicle performs local object detection using its own sensors and AI capabilities detected objects are shared with other vehicles to enhance the overall detection accuracy when we say join inference the idea is that we have a collaborative process here going on where Vehicles share the detected objects and inference results with each other this leads to a more comprehensive understanding of the environment as information from multiple perspectives is combined mind so the idea is pretty simple here's another uh picture that illustrates the concept of distributed joint learning of 3D object detection emphasizing how combining local maps from multiple Vehicles leads to better inference performance the collaborative approach here helps to create a more accurate and comp comprehensive global map improving the detection and understanding of objects in the environment so it's a little bit messy here um what we're looking at is that there are three local Maps local map one local map 2 and local map 3 um these are maps generated by individual Vehicles using their own senses and AI algorithms each local map represents the vehicle's perception of the environment based on its own data own sensor data the global map on the other hand is an aggregated map created by combining the local maps from multiple Vehicles represent it represents a more accurate and comprehensive view of the environment so what is the ground truth quote unquote the ground truth refers to the ual positions and dimensions of objects in the environment the ground truth is used as a reference to evaluate the accuracy of the local and global maps so for Global for local map sorry local map local map one which is blue in color the text local map one is written in blue that is created by one vehicle using it onboard sensors for example cameras liar radar Etc it represents the vehicle's perception which may have inaccuracies due to limited perspective or sensor noise local map 2 green green color it's written in text and the and the map is like a rectangle is also in green this is generated by another vehicle with a different perspective and sensor data it adds additional details and corrections to the overall perception and then you can see there's the local map 3 written in yellow color this is contributed by a third vehicle further enriching the collective understanding of the environment the global map as you can see the global map um went through the aggregation process local maps from multiple vehicles are combined to form the global map the aggregation process involves aligning the local maps and integrating their data to correct inaccuracies and filling gaps so here the global map is red red in color the resultant global map provides a more accurate and comprehensive representation of the environment by incorporating multiple perspectives it reduces the uncertainty and errors pres present in individual local maps and we can use the ground truth as reference data um the ground truth as we said it represents the actual positions dimensions and orientations of objects in the environment it can serve as a benchmark to evaluate the accuracy of local and global maps the diagram shows the alignment of the local maps and the global map with the ground truth that's why you you can see this overlapping rectangles one over in and over the other uh is comparing these different maps with the ground truth the global map in red closely aligns with the ground Truth uh so that goes to show um global map is much more accurate that indicates improved accuracy over the individual local Maps so that's all initially what this picture is trying to convey uh and a specific use case example would be autonomous driving in an urban environment you need all the information you need for your environment for autonomous driving to be safe to be working as it intend as it is intended to to be so that would be a common use case okay another use case here to is uh other than detecting 3D objects is to detect um whether there accidents around so this is again a joint inference same same thing a joint collaborating uh collaboration between a each other the devices collaborate to get more accurate information joint inference among multiple vehicles for accident vehicle detection so this is just another use case same concept this concept uh this illustrates the concept again for join inference among multiple vehicles for accident detection again um many things are the same it demonstrates how Vehicles equipped with AI and sensors of their own collaborate to detect and identify an accident vehicle on the road enhancing situational awareness and safety we have the accident vehicle this accident this vehicle involved in an accident positioned in the middle of the road here on the picture and then this vehicle who is surrounded by debris and potentially hazardous objects so the other so-called participating Vehicles like Al Alice's vehicle um which is which is an autonomous vehicle approaching the accident scene there are other vehicles multiple Vehicles equipped also with ai ai uh and sensors contributing to the Joint inference process each vehicle is equipped with AI systems and various sensors again like cameras liar radar to detect objects and gather data about the environment so just like the previous example the collaborative process where Vehicles share their sensor data and inference results um is to improve the detection and identification of the accident vehicle it involves communication between Vehicles allowing them to Aggregate and refine their observations all right this is the second to the last slide this Slide consolidates the potential requirements and kpis uh key performance indicators identified across the various use cases for authorization the 5G system must support user consent and operator policy to authorize specific ues for data trans Mission qos quality of service control involves configuring and modifying communication qos and monitoring qos characteristics information exposure includes exposing relevant information to third parties and assisting in uee member selection charging mechanisms must support direct device connections for AIML applications these Consolidated requirements form the Baseline for subsequent normative work in conclusion this study has identified several use cases for leveraging direct device Connections in AIML operations including split operations model transfer and Federated learning we've gone through several different variations of these uh three topics and how each of them them work the findings highlight the potential for significant improvements in performance and efficiency we recommend proceeding with normative work based on the Consolidated requirements identified in this report establishing a baseline for future developments in AIML model transfer using direct device connections these advancements will enhance the efficiency and performance of aim applications within the 5G ecosystem Paving the way for more robust and effective Solutions that's the end of this presentation I hope to see you in the next 3gpp presentation goodbye