Enabling model computation offloading functionality

Abstract

The invention provides techniques for enabling shared or split model computation management functionalities whereby user equipment engaging in a proximity based split AI / ML model operation (i.e. a shared computation process) uses discovery / advertisement which specifies model criteria and device capability via a network entity. For example, the method includes generating a message comprising information indicative of model-based criteria supported by first user equipment with respect to a shared model computation process, and sending the message to a network entity to enable the network entity to respond to a discovery request from second user equipment seeking other user equipment to participate in the shared model computation process. By checking for a match between the first and second model-based criteria when the devices are proximate to each other, a discovery response may be sent to enable the first and second devices to establish a security context to exchange data with regards to a shared model computation process.

Description

Field The field relates generally to communication networks, and more particularly, but not exclusively, to model computation management in such communication networks. Background This section introduces aspects that may be helpful in facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art. While fourth generation (4G) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high-capacity mobile multimedia with high data rates particularly for human interaction, fifth generation (5G) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (loT) networks. More particularly, 5G networks are intended to enable massive ToT services (e g , very large numbers of limited capacity devices) and mission-critical loT services (e.g., requiring high reliability), while also providing improvements over legacy mobile communication services in the form of enhanced mobile broadband (eMBB) services with improved wireless Internet access for mobile devices. In an example communication system, user equipment (5G UE in a 5G network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point of an access network referred to as a 5G AN in a 5G network. The access point (e.g., gNB) is illustratively part of an access network of the communication system. For example, in a 5G network, the access network referred to as a 5G AN is described in 5G Technical Specification (TS) 23.501, entitled “Technical Specification Group Services and System Aspects; System Architecture for the 5G System,” and TS 23.502, entitled “Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS),” the disclosures of which are incorporated by reference herein in their entireties. In general, the access point (e.g., gNB) provides access for the UE to a core network (CN or 5GC), which then provides access for the UE to other UEs and / or a data network such as a packet data network (e.g., Internet). TS 23.501 goes on to define a 5G Service-Based Architecture (SBA) which models services as network functions (NFs) that communicate with each other using representational state transfer application programming interfaces (Restful APIs). Furthermore, TS 33.501, entitled “Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety, further describes security management details associated with a 5G network. In some use cases, however, UEs can communicate with one another via a secure direct connection. One such exemplary use case is known as work task offloading, i.e., where one UE offloads a work task to another UE by secure direct connection between UEs. However, due to continuing attempts to improve the architectures and protocols associated with a 5G network in order to increase network efficiency and / or subscriber convenience, network management issues associated with such use cases can present a significant challenge. Summary Illustrative embodiments provide techniques for enabling shared or split model computation management functionalities. While not necessarily limited thereto, illustrative embodiments are well suited for implementation with devices such as user equipment engaging in a split artificial intelligence / machine learning (AIML) model operation (i.e., a shared model computation process) in a communication network environment. In one illustrative embodiment, from a provider user equipment or device perspective, a method includes generating a message comprising information indicative of model-based criteria supported by first user equipment with respect to a shared model computation process, and sending the message to a network entity to enable the network entity to respond to a discovery request from second user equipment seeking other user equipment to participate in the shared model computation process. In another illustrative embodiment, from a consumer user equipment or device perspective, a method includes generating a discovery request seeking user equipment to participate in a shared model computation process, wherein the discovery request specifies model-based criteria to be supported by the user equipment being sought, and sending the discovery request to a network entity to enable the network entity to respond to the discovery request. In yet another illustrative embodiment, from an application server perspective, a method includes receiving a message comprising information indicative of first model-based criteria supported by a first device with respect to a shared model computation process, storing the information in accordance with a context corresponding to the first device, receiving a discovery request from a second device seeking at least one other device to participate in the shared model computation process, wherein the discovery request specifies second modelbased criteria to be supported by the at least one other device being sought, checking for a match between the first model-based criteria and the second model-based criteria when the first device and the second device are proximate to one another, and sending a discovery response to the second device, in response to a match between the first model-based criteria and the second model-based criteria, to enable the second device and the first device to establish a security context to securely exchange data in accordance with the shared model computation process. In some examples, one or more of the devices comprise user equipment. Further illustrative embodiments are provided in the form of a non-transitory computer readable medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above and / or other steps, operations, and the like. Still further illustrative embodiments comprise an apparatus with a processor and a memory configured to perform the above and / or other steps, operations, and the like. Some illustrative embodiments comprise a system configured to perform the above and / or other steps, operations, and the like. Further, some illustrative embodiments comprise an apparatus or a system comprising means for performing the above and / or other steps, operations, and the like. Advantageously, illustrative embodiments provide techniques for enabling functionalities in a communication network in a data exchange context (e.g., a work task offloading context between at least two UEs or other devices) with respect to performance of a service such as, but not limited to, a split AIML model processing service. These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description. Brief Description of the Drawings FIG. 1 illustrates a communication network environment with which one or more illustrative embodiments may be implemented. FIG. 2 illustrates user equipment and entities with which one or more illustrative embodiments may be implemented. FIGS. 3A through 3C illustrate a difference between scenarios involving work task offloading and no work task offloading with respect to user equipment operating in a split AIML model context within which one or more illustrative embodiments can be implemented. FIG. 4 illustrates a procedure for securely enabling work task offloading functionality in a communication network environment according to an illustrative embodiment. FIG. 5 illustrates another procedure for securely enabling work task offloading functionality in a communication network environment according to an illustrative embodiment. FIG. 6 illustrates yet another procedure for securely enabling work task offloading functionality in a communication network environment according to an illustrative embodiment. Detailed Description Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for network function management in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and / or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing the 3rd Generation Partnership Project (3GPP) system elements such as a 3GPP next generation system (5G), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems such as 6G communication systems. In accordance with illustrative embodiments implemented in a 5G communication system environment, one or more 3GPP technical specifications (TS) and technical reports (TR) may provide further explanation of network elements / functions and / or operations that may interact with parts of the inventive solutions, e.g., the above-referenced 3GPP TS 23.501, TS 23.502, and TS 33.501. Other 3GPP TS / TR documents may provide other details that one of ordinary skill in the art will realize, for example, TR 22.876: “Technical Specification Group Services and System Aspects; Study on AI / ML Model Transfer Phase 2,” TR 22.874: “Technical Specification Group Services and System Aspects; Study on Traffic Characteristics and Performance Requirements for AI / ML Model Transfer in 5GS,” TS 23.304: “Technical Specification Group Services and System Aspects; Proximity Based Services (ProSe) in the 5G System (5GS),” and TS 33.503: “Technical Specification Group Services and System Aspects; Security Aspects of Proximity Based Services (ProSe) in the 5G System (5GS)”, the disclosures of which are incorporated by reference herein in their entireties. Note that 3GPP TS / TR documents are non-limiting examples of communication network standards (e.g., specifications, procedures, reports, requirements, recommendations, and the like). However, while well-suited for 5G-related 3GPP standards, embodiments are not necessarily intended to be limited to any particular standards. It is to be understood that the term 5G network, and the like (e.g., 5G system, 5G communication system, 5G environment, 5G communication environment etc.), in some illustrative embodiments, may be understood to comprise all or part of an access network and all or part of a core network. However, the term 5G network, and the like, may also occasionally be used interchangeably herein with the term 5GC network, and the like, without any loss of generality, since one of ordinary skill in the art understands any distinctions. Prior to describing illustrative embodiments, a general description of certain main components of a 5G network will be described below in the context of FIGS. 1 and 2. FIG. 1 shows a communication system 100 within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system 100 are intended to represent some main functions provided within the system, e.g., control plane functions, user plane functions, etc. As such, the blocks shown in FIG. 1 reference specific elements in 5G networks that provide some of these main functions. However, other network elements may be used to implement some or all of the main functions represented. Also, it is to be understood that not all functions of a 5G network are depicted in FIG. 1. Rather, at least some functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures may depict some additional elements / functions (i.e., network entities). Accordingly, as shown, communication system 100 comprises user equipment (UE) 102 that communicates via an air interface 103 with an access point 104. It is to be understood that UE 102 may use one or more other types of access points (e.g., access functions, networks, etc.) to communicate with the 5GC network other than a gNB. By way of example only, the access point 104 may be any 5G access network (gNB), an untrusted non-3 GPP access network that uses an Non-3GPP Interworking Function (N3IWF), a trusted non-3GPP network that uses a Trusted Non-3GPP Gateway Function (TNGF) or wireline access that uses a Wireline Access Gateway Function (W-AGF) or may correspond to a legacy access point (e.g., eNB). Furthermore, access point 104 may be a wireless local area network (WLAN) access point as will be further explained in illustrative embodiments described herein. The UE 102 may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, an loT device, or any other type of communication device. The term “user equipment” as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment such as a smart phone. Such communication devices are also intended to encompass devices commonly referred to as access terminals. In one illustrative embodiment, UE 102 is comprised of a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores a permanent subscription identifier and its related key, which are used to uniquely identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions. Alternative illustrative embodiments may not use UICC-based authentication, e.g., a Non-Public (Private) Network (NPN). Note that, in one example, the permanent subscription identifier is an International Mobile Subscriber Identity (IMSI) unique to the UE. In one embodiment, the IMSI is a fixed 15-digit length and consists of a 3-digit Mobile Country Code (MCC), a 3-digit Mobile Network Code (MNC), and a 9-digit Mobile Station Identification Number (MSIN). In a 5G communication system, an IMSI is referred to as a Subscription Permanent Identifier (SUPI). In the case of an IMSI as a SUPI, the MSIN provides the subscriber identity. Thus, only the MSIN portion of the IMSI typically needs to be encrypted. The MNC and MCC portions of the IMSI provide routing information, used by the serving network to route to the correct home network. When the MSIN of a SUPI is encrypted, it is referred to as Subscription Concealed Identifier (SUCI). Another example of a SUPI uses a Network Access Identifier (NAI). NAI is typically used for loT communication. The access point 104 is illustratively part of a radio access network or RAN of the communication system 100. Such a radio access network may comprise, for example, a 5G System having a plurality of base stations. Components of a radio access network may, more generally, be considered “radio access entities.” Further, the access point 104 in this illustrative embodiment is operatively coupled to an Access and Mobility Management Function (AMF / SEAF) 106. In a 5G network, the AMF / SEAF supports, inter alia, mobility management (MM) and security anchor (SEAF) functions. AMF / SEAF 106 in this illustrative embodiment is operatively coupled to (e.g., uses the services of) other network functions 108. As shown, some of these other network functions 108 include, but are not limited to, a Direct Discovery Name Management Function (DDNMF), an Application Function (AF), and a Unified Data Management (UDM) function. The UDM manages network user data in a single, centralized element. The AF exposes the application layer for interaction with 5G NFs and network resources, e.g., split AIML functionalities, as will be further explained herein. DDNMF is the logical 5G NF that handles network related actions required for dynamic ProSe Direct Discovery. The DDNMF in a Home Public Land Mobile Network (HPLMN) may interact with the DDNMF in a Visited Public Land Mobile Network (VPLMN) or local PLMN in order to manage the ProSe Direct Discovery service. ProSe Direct Discovery is a procedure employed by a ProSe-enabled UE to discover other ProSe-enabled UEs in its vicinity (proximity) based on direct radio transmissions (direct device connection or sidelink) between the two UEs with NR technology. Note that NFs may, more generally, be considered “network entities.” Note that a UE, such as UE 102, is typically subscribed to its HPLMN in which some or all of the functions 106 and 108 reside. Alternatively the UE, such as UE 102, may receive services from an NPN where these functions may reside. The HPLMN is also referred to as the Home Environment (HE). If the UE is roaming (not in the HPLMN), it is typically connected with a VPLMN also referred to as a visited network, while the network that is currently serving the UE is also referred to as a serving network. In the roaming case, some of the functions 106 and 108 can reside in the VPLMN, in which case, functions in the VPLMN communicate with functions in the HPLMN as needed. However, in a non-roaming scenario, access and mobility management functions 106 and the other network functions 108 reside in the same communication network, i.e., HPLMN. Embodiments described herein, unless otherwise specified, are not necessarily limited by which functions reside in which PLMN (i.e., HPLMN or VPLMN). The access point 104 is also operatively coupled (via one or more of functions 106 and / or 108) to a Session Management Function (SMF) 110, which is operatively coupled to a User Plane Function (UPF) 112. UPF 112 is operatively coupled to a Packet Data Network, e.g., Internet 114. Note that the thicker solid lines in this figure denote a user plane (UP) of the communication network, as compared to the thinner solid lines that denote a control plane (CP) of the communication network. It is to be appreciated that network (e.g., Internet 114) in FIG. 1 may additionally or alternatively represent other network infrastructures including, but not limited to, cloud computing infrastructure and / or edge computing infrastructure. Further typical operations and functions of such network elements are not described here since they are not the focus of the illustrative embodiments and may be found in appropriate 3GPP 5G documentation. Note that functions shown in 106, 108, 110 and 112 are examples of network functions (NFs). It is to be appreciated that this particular arrangement of system elements is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. For example, in other embodiments, the communication system 100 may comprise other elements / functions not expressly shown herein. Accordingly, the FIG. 1 arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single elements / functions are shown in the FIG. 1 embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations. It is also to be noted that while FIG. 1 illustrates system elements as singular functional blocks, the various subnetworks that make up the 5G network are partitioned into so-called network slices. Network slices (network partitions) are logical networks that provide specific network capabilities and network characteristics that can support a corresponding service type, optionally using network function virtualization (NFV) on a common physical infrastructure. With NFV, network slices are instantiated as needed for a given service, e.g., eMBB service, massive loT service, and mission-critical loT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE 102 is configured to access one or more of these services via access point 104. FIG. 2 is a block diagram illustrating computing architectures for various participants in methodologies according to illustrative embodiments. More particularly, system 200 is shown comprising user equipment (UE) 202 and a plurality of entities 204-1, ...., 204-N. For example, in illustrative embodiments and with reference back to FIG. 1, UE 202 can represent UE 102 (as well as any UE functioning as a consumer and / or a provider in a work task offloading context as will be further described herein), while entities 204-1, ..., 204-N can represent functions 106 and 108 (i.e., network entities such as, but not limited to, DDNMF, AF, etc.), as well as access point 104 (i.e., radio access entity such as, but not limited to, a RAN node or gNB). It is to be appreciated that the UE 202 and entities 204-1, ...., 204-N are configured to interact to provide management (e.g., functionalities associated with work task offloading in a split AIML model processing context) and other techniques described herein. The user equipment 202 comprises a processor 212 coupled to a memory 216 and interface circuitry 210. The processor 212 of the user equipment 202 includes a management processing module 214 that may be implemented at least in part in the form of software executed by the processor. The management processing module 214 performs management described in conjunction with subsequent figures and otherwise herein. The memory 216 of the user equipment 202 includes a management storage module 218 that stores data generated or otherwise used during management operations. Each of the entities (individually or collectively referred to herein as 204) comprises a processor 222 (222-1, ..., 222-N) coupled to a memory 226 (226-1, ..., 226-N) and interface circuitry 220 (220-1, ..., 220-N). Each processor 222 of each entity 204 includes a management processing module 224 (224-1, ..., 224-N) that may be implemented at least in part in the form of software executed by the processor 222. The management processing module 224 performs management operations described in conjunction with subsequent figures and otherwise herein. Each memory 226 of each entity 204 includes a management storage module 228 (228-1, ..., 228-N) that stores data generated or otherwise used during management operations. The processors 212 and 222 may comprise, for example, microprocessors such as central processing units (CPUs), application-specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements. The memories 216 and 226 may be used to store one or more software programs that are executed by the respective processors 212 and 222 to implement at least a portion of the functionality described herein. For example, management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors 212 and 222. A given one of the memories 216 and 226 may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a computer or processor readable (non-transitory or storage) medium that has executable program code embodied therein. Other examples of computer or processor readable media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other computer or processor readable media. Further, the memories 216 and 226 may more particularly comprise, for example, electronic random-access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phasechange RAM (PC-RAM) or ferroelectric RAM (FRAM). The term “memory” as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices. The interface circuitries 210 and 220 illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein. It is apparent from FIG. 2 that user equipment 202 and plurality of entities 204 are configured for communication with each other as management participants via their respective interface circuitries 210 and 220. This communication involves each participant sending data to and / or receiving data from one or more of the other participants. The term “data” as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between participants including, but not limited to, identity data, key pairs, key indicators, tokens, secrets, management messages, registration request / response messages and data, request / response messages, authentication request / response messages and data, metadata, control data, audio, video, multimedia, consent data, other messages, etc. It is to be appreciated that the particular arrangement of components shown in FIG. 2 is an example only, and numerous alternative configurations may be used in other embodiments. For example, any given network element / function and / or access point can be configured to incorporate additional or alternative components and to support other communication protocols. Other system elements such as access point 104, SMF 110, and UPF 112 may each be configured to include components such as a processor, memory and network interface. Also, entities such as third-party applications and network operators can participate in methodologies described herein via computing devices configured to include components such as a processor, memory and network interface. These elements and devices need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform. More generally, FIG. 2 can be considered to represent processing devices configured to provide respective management functionalities and operatively coupled to one another in a communication system. By way of example only, all or parts of each of UE 202 and the plurality of entities 204 (e.g., processor and memory) can be considered examples of means for performing one or more operations, one or more steps, one or more functions, one or more processes, etc. as described herein. As mentioned above, the 3GPP TS 23.501 defines the 5GC network architecture as service-based, e.g., Service-Based Architecture (SBA). It is realized herein that in deploying different NFs, there can be many situations where an NF may need to interact with an entity external to the SBA-based 5GC network (e.g., including the corresponding PLMN(s), e.g., HPLMN and VPLMN). Thus, the term “internal” as used herein illustratively refers to operations and / or communications within the SBA-based 5GC network (e.g., SBA-based interfaces) and the term “external” illustratively refers to operations and / or communications outside the SBA-based 5GC network (non-SBA interfaces). Given the above general description of some features of a 5GC network, problems with existing approaches in user equipment work task offloading functionalities in a communication network environment, and solutions proposed in accordance with illustrative embodiments, will now be described herein below. While not limited thereto, illustrative embodiments will be described in the context of work task offloading for user equipment engaging in split artificial intelligence / machine learning (AIML) model processing in a communication network environment. Further, it is to be appreciated that the term work task offloading relationship is one example of a data exchange relationship with respect to the requested service (e.g., split AIML model processing). Still further, while some illustrative embodiments are described with respect to a work task offloading relationship between two UEs, it is to be understood that more than two UEs or other devices can be involved in the same work task offloading relationship for the requested service according to further illustrative embodiments. Work task offloading or, more particularly, proximity-based work task offloading, is based on a third party’s request for one UE, i.e., a relay UE, to receive data from another UE, i.e., a remote UE, via a secure direct (device-to-device) connection and perform calculation of a work task for the remote UE. The calculation result can be further sent to a network server or NF. In the context of one particular use case, proximity-based work task offloading can be utilized for AIML inference model processing. Model splitting, wherein different devices or functions (e.g., one or more UEs and one or more network functions or servers) compute different layers of the AIML inference model, is an important feature for AI inference model processing. In some scenarios, it is realized herein that the number of devices or functions computing layers, and the amount of data transmission, correspond to different model splitting points. For example, FIG. 3A shows a layer-level computation / communication resource evaluation 300 for an example AIML model, e.g., an AlexNet model. A general trend is realized wherein the more layers a UE calculates, the less intermediate data needs to be transmitted to the network server (e.g., application). Further, when a UE has low computation capacity (e.g., due to a low battery), the application can change the splitting point to enable the UE to calculate fewer layers while increasing the data rate in the Universal Mobile Telecommunications System (UMTS) air interface, referred to as the Uu interface, for transmitting a higher load of intermediate data to the network server. However, sometimes the data rate cannot be increased due to radio resource (e.g., gNB) limitations. In such circumstances, the UE with low computation capacity needs to offload the computation task to a proximate UE (e.g., a relay UE) while still maintaining the computation service and letting the proximate UE send the calculated data to the network server. Thus, by offloading the work task using a secure direct device connection, the original UE’s computation load will be released while the data rate in the Uu interface will not necessarily be increased either, which leads to better network performance. More particularly, FIG. 3B shows a service flow 310 where no work task offloading occurs while FIG. 3C shows a service flow 320 where work task offloading occurs. As shown in service flow 310 in FIG. 3B, UE-A is performing image recognition using a convolutional neural network (CNN) of the AlexNet model represented in FIG. 3 A. Assume that UE-A selects splitting point-3 for the AI inference. It is realized that the end-to-end (E2E) service latency (including image recognition latency and intermediate data transmission latency) is one second. However, when the UE-A’s battery becomes low, it cannot afford the heavy work task for the AlexNet model (i.e., calculating layers 1-15 for AlexNet model on the local (UE) side). Thus, as shown in service flow 320 in FIG. 3C, further assume that, while managed by the 5G network (CN or 5GC), UE-A discovers UE-B (e.g., another mobile subscriber terminal or a customer premise equipment (CPE)) which has installed the same model and is willing to take the offloading task from UE-A. Note that the 5G network does not store UE-A and UE-B’s location data. As further shown in FIG. 3C, UE-A establishes a sidelink (i.e., a secure direct device connection) to UE-B. During the sidelink establishment, assume that UE-B also obtains the information of the total service latency (including the image recognition latency and intermediate data transmission latency) and the processing time consumed by UE-A for computing layers 1-4. Since UE-B has acquired the E2E service latency and the processing time consumed by UE-A, and also knows its own processing time for computing layers 5-15, UE-B can determine the quality-of-service (QoS) parameters applied to both the Uu interface and the sidelink while keeping the same (i.e., one second) E2E service latency. Note that it is assumed that UE-A and UE-B have the same computation capacity, i.e., the time used for computing the particular AlexNet model layers are the same for UE-A and UE-B. Otherwise, the data rate on the Uu interface and the sidelink may be changed accordingly. As further shown in FIG. 3C, LJE-A sends the intermediate data (i.e., data after calculating layers 1-4) to UE-B via the sidelink, and UE-B performs the further processing and transmits the intermediate data (i.e., data after calculating layers 5-15) to the network (application) server via the Uu interface. The specific model layers being computed by UE-A and UE-B are shown in FIG. 3C. UE-A continues to perform image recognition by leveraging the sidelink and UE-B’s computation capacity while the source and destination Internet Protocol (IP) address and the E2E service latency for the image recognition service is unchanged. Thus, as depicted in FIG. 3C, a direct device connection (e.g., sidelink) can advantageously be used to realize the proximity-based work task offloading. In this case, the data rate for UE-A on the Uu interface need not be increased while UE-A’s computation load is offloaded to UE-B. It is further realized herein that, in some scenarios, a third party may be able to provide UEs with high computation capabilities specifically for providing proximity-based work task offloading services for AIML. By way of example only, airport authorities or local governments (more generally, entities) may decide to install devices at the airport which not only provide additional AIML computation capabilities to UEs at the airport, but also share airport security related information within the devices as well as to a network (application) server. In such scenarios, the additional computation capabilities are provided by the devices installed by airport authorities. It is to be appreciated that such devices installed at locations as explained here may be referred to as customer premise equipment (CPE). Such CPE, whether stationary and / or mobile, can be more generally referred to as one or more UEs. However, it is realized herein that such proximity-based work task offloading with respect to split AIML model processing, as illustratively described above, can cause significant management challenges to the CN or 5GC. By way of example, it is realized herein that the 5GC should support the transfer of AIML model intermediate data from UE to UE via the direct device connection. Still further, it is further realized that in order for the 5GS to allow UEs to split operations of AIML offload using proximity based direct connections, the 5GS should obtain user consent for using one UE’s AIML capability for another UE’s AIML processing. Also, the 5GS should know about UEs abilities to share AIML computing resources and should be able to enable UEs to use the shared AIML computation capabilities from neighboring UEs. Still further, the 5GS should assess potential UE pairs which can work on split operations of AIML offload using proximity based direct connections, while ensuring the satisfaction of key performance indicators (KPIs). Additionally, security aspects should be considered by the 5GS in this work offload for split AIML scenario. Illustrative embodiments enable the above and other features and advantages, and thus overcome the above and other technical drawbacks of existing approaches, by providing improved techniques for enabling functionalities in the context of work task offloading with respect to split AIML model processing or the like. As used herein with respect to one or more illustrative embodiments, the term “AIML service provider” is used for the UE which provides the AIML work offload service to another UE in proximity, while the term “AIML service consumer” is used for the UE which requests the AIML work offload service from the AIML service provider. As will be further illustrated and explained, illustrative embodiments provide techniques that enable the following and other functionalities. In some illustrative embodiments, the AIML service provider UE sends the list of AIML models supported for split AIML operation for other UEs. Also, the upper limit of the number of layers supported is shared with the DDNMF. The ProSe Application Server stores the list of AIML models supported for split operation and the layer support limit in a UE context. If a UE shares the above mentioned information, some illustrative embodiments propose to consider this as implicit user consent for the split AIML work offloading use case. UEs not sharing this information are not considered by the 5GS for this use case, even if those UEs are in proximity of the AIML service consumer UE and are capable of sidelink communications. However, in some embodiments, an explicit user consent can also be included along with AIML capability information shared from the AIML service provider UE. In some illustrative embodiments, the discovery request also includes requested AIML model and requested layer support to let the other UE calculate fewer layers while increasing the data rate in Uu for transmitting a higher load of intermediate data to the 5GS. The discovery procedure can be executed as described above. In some illustrative embodiments, the direct communication procedure can be executed, and security establishment completed, as per the legacy ProSe security procedure. However, some illustrative embodiments implement PC5 security including encryption and integrity protection for split AIML use cases. PC5, also referred to as LTE-V2X, is a proxy standard that represents the subset of the 3GPP specification that defines Cellular Vehicle-to-Everything (C-V2X) technology which uses device-to-device communication (PC5) without requiring the presence of a base station. In some illustrative embodiments, as the AIML data is sensitive, for the user plane case, the security of integrity and ciphering should be mandatory from the network configuration or in the security establishment procedure. Thus, using ProSe keys, the AIML data for split operation is shared to the service provider UE along with the expected latency information. Referring now to FIG. 4, a procedure 400 is shown for enabling work task offloading functionality in a communication network environment according to an illustrative embodiment. While not limited thereto, procedure 400 may be considered a security procedure for a restricted 5G ProSe Direct Discovery Model A use case. As such, when the user plane based security procedure for the UE-to-Network Relay is used, the 5G PKMF takes the role of the 5GDDNMF as described in the above-referenced TS 33.503. As shown, procedure 400 involves a UE 402 (e.g., M-UE functioning as an AIML service consumer), UE 404 (e.g., A-UE functioning as an AIML service provider), an HPLMN 406 (e.g., HPLMN of M-UE DDNMF), a VPLMN 408 (e.g, VPLMN of A-UE DDNMF), an HPLMN 410 (e g., HPLMN of A-UE DDNMF), and a ProSe Application Server 412. Steps 1-4, as referenced in procedure 400, relate to the AIML service provider UE (i.e., UE 404): Step 1. AIML service provider UE sends a Discovery Request message containing the Restricted ProSe Application User ID (RPAUID) to the 5G DDNMF in its HPLMN in order to get the ProSe Code to announce and to get the associated security material. In addition, the AIML service provider UE includes its PC5 UE security capability that contains the list of supported ciphering algorithms by the UE in the Discovery Request message. For 5G ProSe UE-to-Network Relay discovery, the 5G ProSe UE-to-Network Relay plays the role of the AIML service provider UE and sends a Relay Discovery Key Request instead of a Discovery Request. The Relay Discovery Key Request message includes the Relay Service Code (RSC) and the 5G ProSe UE-to-Network Relay’s PC5 security capability. AIML service provider UE also sends the list of AIML models supported for split AIML operation for other UEs. Also, the layer supported limit is shared with HPLMN DDNMF of the A-UE. When AIML service provider UE sends this information to HPLMN DDNMF of the A-UE, this is considered as an implicit user consent. Also, in some embodiments, an explicit user-consent can be included in the same message along with the AIML model capabilities information. Step 2 (inclusive of steps 2a and 2b). The 5G DDNMF of the A-UE may check for the announce authorization with the ProSe Application Server. For 5G ProSe UE-to-Network Relay discovery, the 5G DDNMF may check with the UDM whether the UE-to-Network relay is authorized to announce UE-to-Network relay discovery. ProSe Application Server stores the list of AIML models supported for split operation and the layer support limit (AIML configuration) in the UE context. Step 3. If the AIML service provider UE is roaming, the 5G DDNMFs in the HPLMN and VPLMN of the AIML service provider UE exchange Announce Auth. Step 4. The 5G DDNMF in the HPLMN of the AIML service provider UE returns the ProSe Restricted Code and the corresponding Code-Sending Security Parameters, along with the CURRENTJTIME and MAX OFFSET parameters. The Code-Sending Security Parameters provide the necessary information for the AIML service provider UE to protect the transmission of the ProSe Restricted Code and are stored with the ProSe Restricted Code. The AIML service provider UE takes the same actions with CURRENT TIME and MAX OFFSET as described for the AIML service provider UE in step 4 of clause 6.1.3.1 of TS 33.503. The 5G DDNMF in the HPLMN of the AIML service provider UE includes the chosen PC5 ciphering algorithm in the Discovery Response message. The 5G DDNMF determines the chosen PC5 ciphering algorithm based on the ProSe Restricted Code and the received PC5 UE security capability in step 1. The UE stores the chosen PC5 ciphering algorithm together with the ProSe Restricted Code. In addition, the 5G DDNMF in the HPLMN of the AIML service provider UE may associate the ProSe Restricted Code with the PC5 security policies and include the PC5 security policies in the Discovery Response message. For 5G ProSe UE-to-Network Relay discovery, a Relay Discovery Key Response is used instead of the Discovery Response, and the RSC is used instead of the ProSe Restricted Code. It is to be noted that the 5G DDNMF may get the PC5 security policies in different ways (e.g., from PCF, from ProSe Application Server, or based on local configuration). Steps 5-10, as referenced in procedure 400, relate to the AIML service consumer UE (i.e., UE 402): Step 5. The AIML service consumer UE sends a Discovery Request message containing the RPAUID and its PC5 UE security capability to the 5G DDNMF in its HPLMN in order to be allowed to monitor for one or more Restricted ProSe Application User IDs. For 5G ProSe UE-to-Network Relay discovery, the 5G ProSe Remote UE plays the role of the AIML service consumer UE and sends a Relay Discovery Key Request instead of the Discovery Request. The Relay Discovery Key Request message includes the RSC and the 5G ProSe Remote UE’s PC5 security capability. The discovery request also includes the requested AIML model and requested layer support to let the other UE calculate fewer layers while increasing the data rate in Uu for transmitting a higher load of intermediate data to network. Step 6 (inclusive of steps 6a and 6b). The 5G DDNMF in the HPLMN of the AIML service consumer UE (M-UE) sends an authorization request to the ProSe Application Server. If, based on the permission settings, the RPAUID is allowed to discover at least one of the Target RPAUIDs contained in the Application Level Container, the ProSe Application Server returns an authorization response. The request for split AIML operation is considered at ProSe Application Server for further processing. The ProSe Application Server checks which UE in proximity is best suited for the request for split operation. For 5G ProSe UE-to-Network Relay discovery, the 5G DDNMF of the Remote UE may check with the UDM whether the Remote UE is authorized to monitor UE-to-Network relay discovery. Step 7. If the Discovery Request is authorized, and the PLMN ID in the Target RPAUID indicates a different PLMN, the 5G DDNMF in the HPLMN of the AIML service consumer UE contacts the indicated PLMN's 5G DDNMF (i.e., the 5G DDNMF in the HPLMN of the AIML service provider UE) by sending a Monitor Request message including the PC5 UE security capability received in step 5. For 5G ProSe UE-to-Network Relay Discovery, Relay Discovery Key Request and RSC are used instead of Discovery Request and RPAUID. Step 8. The 5G DDNMF in the HPLMN of the AIML service provider UE may exchange authorization messages with the ProSe Application Server. For 5G ProSe UE-to-Network Relay discovery, this step is skipped. If the matching request is found, then AIML information is shared. Step 9. If the PC5 UE security capability in step 5 includes the chosen PC5 ciphering algorithm, the 5G DDNMF in the HPLMN of the AIML service provider UE responds to the 5G DDNMF in the HPLMN of the AIML service consumer UE with a Monitor Response message including the ProSe Restricted Code, the corresponding Code-Receiving Security Parameters, an optional Discovery User Integrity Key (DUIK), and the chosen PC5 ciphering algorithm (based on the information / keys stored in step 4). The Code-Receiving Security Parameters provide the information needed by the AIML service consumer UE to undo the protection applied by the AIML service provider UE. The DUIK is included as a separate parameter if the Code-Receiving Security Parameters indicate that the AIML service consumer UE uses Match Reports for MIC checking. The 5G DDNMF in the HPLMN of the AIML service consumer UE stores the ProSe Restricted Code and the Discovery User Integrity Key (if it received one outside of the Code-Receiving Security Parameters). For 5G ProSe UE-to-Network Relay discovery, a Relay Discovery Key Response is used instead of the Monitor Response, and the RSC is used instead of the ProSe Restricted Code. The 5G DDNMF in the HPLMN of the AIML service provider UE may send the PC5 security policies associated with the ProSe Restricted Code to the 5G DDNMF in the HPLMN of the AIML service consumer UE. It is to be noted that, for 5G ProSe Direct Discovery, there are two possible configurations for integrity checking, namely, MIC checked by the 5G DDNMF of the AIML service consumer UE, and MIC checked at the AIML service consumer UE side. Which configuration to use is decided by the 5G DDNMF, which assigns the monitored ProSe Restricted Code and signals the AIML service consumer UE in the Code-Receiving Security Parameters. For 5G ProSe UE-to-Network Relay discovery, MIC checking is performed only at the Remote UE and the 5G DDNMF of the Remote UE does not need to configure integrity checking for UE-to-Network Relay discovery. It is to be noted that the chosen PC5 ciphering algorithm is associated with the ProSe Restricted Code. Step 10. The 5G DDNMF in the HPLMN of the AIML service consumer UE returns the Discovery Filter and the Code-Receiving Security Parameters, along with the CURRENT TIME and MAX OFFSET parameters and the chosen PC5 ciphering algorithm. The AIML service consumer UE takes the same actions with CURRENT TIME and MAX OFFSET as described for the AIML service consumer UE in step 9 of clause 6.1.3.1 of the above-referenced TS 33.503. The UE stores the Discovery Filter, Code-Receiving Security Parameters, and the chosen PC5 ciphering algorithm together with the ProSe Restricted Code. For 5G ProSe UE-to-Network Relay discovery, a Relay Discovery Key Response is returned instead of the Discovery Response, and the RSC is included instead of the ProSe Restricted Code. The response message contains the discovery security materials as contained in step 9. If the 5G DDNMF in the HPLMN of the AIML service consumer UE receives the PC5 security policies associated with the ProSe Restricted Code in step 9, the AIML service consumer UE’s 5G DDNMF forwards the PC5 security policies to the AI ML service consumer UE. For 5G ProSe UE-to-Network Relay discovery, a Relay Discovery Key Response is used instead of the Discovery Response, and the RSC is used instead of the ProSe Restricted Code. Steps 11 and 12, referenced in procedure 400, occur over PC5: Step 11. The UE starts announcing, if the UTC-based counter provided by the system associated with the discovery slot is within the MAX OFFSET of the AI ML service provider UE's ProSe clock and if the Validity Timer has not expired. The UE forms the discovery message and protects the message. The four least significant bits of UTC-based counter are transmitted along with the protected discovery message. Step 12. The AIML service consumer UE listens for a discovery message that satisfies its Discovery Filter if the UTC-based counter associated with that discovery slot is within the MAX OFFSET of the AIML service consumer UE’s ProSe clock. In order to find such a matching message, it processes the message. If the AIML service consumer UE was not asked to send Match Reports for MIC checking, it stops at this step from a security perspective. Otherwise, it proceeds to step 13. It is to be noted that the UE checking the integrity of the discovery message on its own does not prevent the UE from sending a Match Report due to requirements in the abovereferenced TS 23.304. If such a Match Report is sent, then there is no security functionality involved. Steps 13-16, as referenced in procedure 400, refer to an AIML service consumer UE that has encountered a match (note that, for 5G ProSe UE-to-Network Relay discovery, steps 13-16 are skipped): Step 13. If the UE has either not had the 5G DDNMF check the MIC for the discovered ProSe Restricted Code previously or the 5G DDNMF has checked a MIC for the ProSe Restricted Code and the associated Match Report refresh timer (see step 15 for details of this timer) has expired, or as required based on the procedure specified in the above-referenced TS 23.304, then the AIML service consumer UE sends a Match Report message to the 5 G DDNMF in the HPLMN of the AIML service consumer UE. The Match Report contains the UTC-based counter value with four least significant bits equal to four least significant bits received along with discovery message and nearest to the AIML service consumer UE’s UTC-based counter associated with the discovery slot where it heard the announcement, and other discovery message parameters including the ProSe Restricted Code and MIC. The 5G DDNMF checks the MIC. Step 14. The 5G DDNMF in the HPLMN of the AIML service consumer UE may exchange an Auth Req / Auth Resp with the ProSe Application Server to ensure that AIML service consumer UE is authorized to discover the AIML service provider UE. Step 15. The 5G DDNMF in the HPLMN of the AIML service consumer UE returns to the AIML service consumer UE an acknowledgement that the integrity check passed. It also provides the CURRENT TIME parameter, by which the UE (re)sets its ProSe clock. The 5G DDNMF in the HPLMN of the AIML service consumer UE included the Match Report refresh timer in the message to the AI ML service consumer UE. The Match Report refresh timer indicates how long the UE will wait before sending a new Match Report for the ProSe Restricted Code. Step 16. The 5G DDNMF in the HPLMN of the AIML service consumer UE may send a Match Report Info message to the 5G DDNMF in the HPLMN of the AIML service provider UE. Referring now to FIG. 5, a procedure 500 is shown for enabling work task offloading functionality in a communication network environment according to an illustrative embodiment. While not limited thereto, procedure 500 may be considered an open 5G ProSe Direct Discovery security procedure. As shown, procedure 500 involves a UE 502 (e.g., P-UE functioning as an AIML service provider), an HPLMN 504 (e.g., HPLMN of P-UE DDNMF), and a VPLMN 506 (e.g., VPLMN of P-UE DDNMF). Steps 1-15 referenced in procedure 500 will now be described. Step 1. The AIML service Provider UE sends a Discovery Request message containing the ProSe Application ID to the 5G DDNMF in its HPLMN in order to be allowed to announce a code on its serving PLMN (either VPLMN or HPLMN). AIML service provider UE also sends the list of AI ML model supported for split AIML operation for other UEs. Also, the upper limit of number of layers supported is shared with DDNMF. a. If AIML service provider UE sends such a list of AIML models and layers capability information, this is considered as implicit user consent. b. Also, in some embodiments, an explicit user-consent can also be included in the same message along with the AIML model capabilities information. Step 2 (inclusive of steps 2a and 2b). If the AIML service Provider UE wants to send announcements in the VPLMN, it needs to be authorized from the VPLMN 5G DDNMF. The 5G DDNMF in the HPLMN requests authorization from the VPLMN 5G DDNMF by sending Announce Auth.() message. DDNMF stores the list of AIML models supported for split operation and the layer support limit in UE context. Step 3. VPLMN 5G DDNMF responds with an Announce Auth. Ack() message, if authorization is granted. There are no changes to these messages for the purpose of protecting the transmitted code for open 5G ProSe Direct Discovery. If the AIML service Provider UE is not roaming, these steps do not take place. Step 4. The 5G DDNMF in HPLMN of the AIML service Provider UE returns the ProSe Application Code that the AIML service Provider UE can announce and a Discovery Key associated with it. The 5G DDNMF stores the Discovery Key with the ProSe Application Code. In addition, the 5G DDNMF provides the UE with a CURRENT TIME parameter, which contains the current UTC-based time at the 5G DDNMF, a MAX_OFFSET parameter, and a Validity Timer. The UE sets a clock which is used for ProSe authentication (i.e., ProSe clock) to the value of CURRENT TIME and the UE stores the MAX OFFSET parameter, overwriting any previous values. The AIML service Provider UE obtains a value for a UTC-based counter associated with a discovery slot based on UTC time. The counter is set to a value of UTC time in a granularity of seconds. The UE may obtain UTC time from any sources available, e.g., the RAN via SIB9, NITZ, NTP, GPS, via Ub interface (in GBA) (depending on which is available). Note that the UE may use unprotected time to obtain the UTC-based counter associated with a discovery slot. This means that the discovery message could be successfully replayed if a UE is fooled into using a time different to the current time. The M AX OFFSET parameter is used to limit the ability of an attacker to successfully replay discovery messages or obtain correctly MICed discovery message for later use. This is achieved by using MAX OFFSET as a maximum difference between the UTC-based counter associated with the discovery slot and the ProSe clock held by the UE. Note that a discovery slot is the time at which an AI ML service Provider UE sends the announcement. Further note that AIML service provider UE will receive Prose App Code which is only specific for the AIML split operation. For other services, the code will be different. Accordingly, the range can be standardized for AIML split operation. Step 5. The AIML service Provider UE starts announcing, if the difference between UTC-based counter provided by the system associated with the discovery slot and the UE’s ProSe clock is not greater than the MAX OFFSET and if the Validity Timer has not expired. For each discovery slot it uses to announce, the AIML service Provider UE calculates a 32-bit Message Integrity Check (MIC) to include with the ProSe Application Code in the discovery message. Four least significant bits of UTC-based counter are transmitted along with the discovery message. The MIC is calculated using the Discovery Key and the UTC-based counter associated with the discovery slot. Step 6 (inclusive of steps 6a and 6b). The AIML service consumer UE sends a Discovery Request message containing the ProSe Application ID to the 5G DDNMF in its HPLMN in order to get the Discovery Filters that it wants to listen for. The request for split AIML operation is considered at DDNMF for further processing. The DDNMF checks which UE in proximity is best suited for the request for split operation. Step 7. The 5G DDNMF in the HPLMN of the AIML service consumer UE sends Monitor Req. message to the 5G DDNMF in the HPLMN of the AI ML service Provider UE. Step 8. The 5G DDNMF in the HPLMN of the AIML service Provider UE sends Monitor Resp. message to the 5G DDNMF in the HPLMN of the AIML service consumer UE. Step 9. The 5G DDNMF returns the Discovery Filter containing either the ProSe Application Code(s), the ProSe Application Mask(s) or both along with the CURRENT TIME and the MAX OFFSET parameters. The AIML service consumer UE sets its ProSe clock to CURRENTJFIME and stores the MAX OFFSET parameter, overwriting any previous values. The AIML service consumer UE obtains a value for a UTC-based counter associated with a discovery slot based on UTC time. The counter is set to a value of UTC time in a granularity of seconds. The AIML service consumer UE may obtain UTC time from any sources available, e.g., the RAN via SIB9, NITZ, NTP, GPS (depending on which is available). Step 10. The AIML service consumer UE listens for a discovery message that satisfies its Discovery Filter, if the difference between UTC-based counter associated with that discovery slot and UE’s ProSe clock is not greater than the MAX OFFSET of the AI ML service consumer UE's ProSe clock. Step 11. On hearing such a discovery message, and if the UE has either not checked the MIC for the discovered ProSe App Code via Match Report previously or has checked a MIC for the ProSe App Code via Match Report and the associated Match Report refresh timer (see steps 14 and 15 for details of this timer) has expired, or as required based on the procedure specified in the above-referenced TS 23.304, the AIML service consumer UE sends a Match Report message to the 5G DDNMF in the HPLMN of the AIML service consumer UE. The Match Report contains the UTC-based counter value with four least significant bits equal to four least significant bits received along with discovery message and nearest to the AIML service consumer UE’s UTC-based counter associated with the discovery slot where it heard the announcement, and other discovery message parameters including the ProSe App Code and MIC. If a Match Report is not required, the AI ML service consumer UE shall locally process the discovery message and the rest of the procedure is not performed. Step 12. The 5G DDNMF in the HPLMN of the AIML service consumer UE passes the discovery message parameters including the ProSe Application Code and MIC and associated counter parameter to the 5G DDNMF in the HPLMN of the AIML service Provider UE in the Match Report message. Step 13. The 5G DDNMF in the HPLMN of the AIML service Provider UE checks the MIC is valid. The relevant Discovery Key is identified by the ProSe Application Code. Step 14. The 5G DDNMF in the HPLMN of the AIML service Provider UE acknowledges a successful check of the MIC to the 5G DDNMF in the HPLMN of the AIML service consumer UE via the Match Report Ack message. The 5G DDNMF in the HPLMN of the AIML service Provider UE includes a Match Report refresh timer in the Match Report Ack message. The Match Report refresh timer indicates how long the UE will wait before sending a new Match Report for the ProSe Application Code. Step 15. The 5G DDNMF in the HPLMN of the AIML service consumer UE acknowledges the MIC check result to the AIML service consumer UE. The 5G DDNMF returns the parameter ProSe Application ID to the UE. It also provides the CURRENT TIME parameter, by which the UE (re)sets its ProSe clock. The 5G DDNMF in the HPLMN of the AIML service consumer UE may optionally modify the received Match Report refresh timer based on local policy and then include the Match Report refresh timer in the message to the AIML service consumer UE. Referring now to FIG. 6, a procedure 600 is shown for enabling work task offloading functionality in a communication network environment according to an illustrative embodiment. Procedure 600 refers to further illustrative security aspects for enabling work task offloading functionality in a communication network environment. As shown, procedure 600 involves a UE 602 (e.g., P-UE functioning as an AIML service provider), UE 604 (e.g., C-UE functioning as an AIML service consumer), a DDMNF 606 of P-UE, a DDMNF 608 of C-UE, and a UDM 610 of P-UE. Steps 1-4 referenced in procedure 600 will now be explained. Step 1. Discovery procedure is executed as described above. Step 2. Direct communication procedure is executed and security establishment is completed. Steps 3 and 4. As the AIML data is sensitive, for the user plane case, the security of integrity and ciphering is mandatory from the network configuration or in security establishment procedure. Furthermore, using ProSe keys, the AIML data for split operation is shared with the service provider UE (P-UE) along with the latency information. Accordingly, at least one illustrative embodiment may include an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to generate a message comprising information indicative of model-based criteria supported by the apparatus with respect to a shared model computation process, and send the message to a network entity to enable the network entity to respond to a discovery request from a device seeking at least one other device to participate in the shared model computation process. In some illustrative embodiments, the information indicative of the model-based criteria comprises one or more model types and at least one model layer limit that the apparatus supports with respect to the shared model computation process. In some illustrative embodiments, inclusion of the information indicative of the modelbased criteria in the message comprises an implicit consent by the apparatus to participate in the shared model computation process. In some illustrative embodiments, the message further comprises an explicit consent by the apparatus to participate in the shared model computation process. In some illustrative embodiments, the apparatus may be further caused to participate in a direct communication process with the device that sent the discovery request, when in proximity therewith, to exchange data in accordance with the shared model computation process, and to establish a security context with the device to securely exchange data in accordance with the shared model computation process. In some illustrative embodiments, the security context specifies one or more of ciphering and integrity protection parameters to be used to securely exchange data in accordance with the shared model computation process. In some illustrative embodiments, the apparatus may be further caused to securely receive latency information, associated with the shared model computation process, from the device. In some illustrative embodiments, the shared model computation process comprises a split artificial intelligence / machine learning (AIML) model operation. In some illustrative embodiments, a method comprises generating a message comprising information indicative of model-based criteria supported by first user equipment (or first device) with respect to a shared model computation process, and sending the message to a network entity to enable the network entity to respond to a discovery request from second user equipment (or second device) seeking other user equipment to participate in the shared model computation process. The steps can be performed by at least one processor and at least one memory storing instructions executable by the at least one processor. Another illustrative embodiment may include an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to generate a discovery request seeking a device to participate in a shared model computation process, wherein the discovery request specifies model-based criteria to be supported by the device being sought, and send the discovery request to a network entity to enable the network entity to respond to the discovery request. In some illustrative embodiments, the model-based criteria comprises a requested model type and a requested number of model layers to be supported by the device in accordance with the shared model computation process. In some illustrative embodiments, the apparatus is further caused to participate in a direct communication process with the device, when in proximity therewith, to exchange data in accordance with the shared model computation process, and to establish a security context with the device to securely exchange data in accordance with the shared model computation process. The security context may specify one or more of ciphering and integrity protection parameters to be used to securely exchange data in accordance with the shared model computation process. In some illustrative embodiments, the apparatus may be further caused to securely send latency information, associated with the shared model computation process, to the device. In some illustrative embodiments, a method comprises generating a discovery request seeking user equipment to participate in a shared model computation process, wherein the discovery request specifies model-based criteria to be supported by the user equipment being sought, and sending the discovery request to a network entity to enable the network entity to respond to the discovery request. The steps may be performed by at least one processor and at least one memory storing instructions executable by the at least one processor. Yet another illustrative embodiment may include an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to receive a message comprising information indicative of first model-based criteria supported by a first device with respect to a shared model computation process, and store the information in accordance with a context corresponding to the first device. In some illustrative embodiments, the apparatus may be further caused to receive a discovery request from a second device seeking at least one other device to participate in the shared model computation process, wherein the discovery request specifies second modelbased criteria to be supported by the at least one other device being sought. In some illustrative embodiments, the apparatus may be further caused to check for a match between the first model-based criteria and the second model-based criteria when the first device and the second device are proximate to one another. In some illustrative embodiments, the apparatus may be further caused to send a discovery response to the second device, in response to a match between the first model-based criteria and the second model-based criteria, to enable the second device and the first device to establish a security context to securely exchange data in accordance with the shared model computation process. In some illustrative embodiments, the apparatus comprises a proximity service application server, the shared model computation process comprises a split artificial intelligence / machine learning (AIML) model operation, the first device comprises user equipment functioning as an AIML service provider, and the second device comprises user equipment functioning as an AIML service consumer. In some illustrative embodiments, a method comprises receiving a message comprising information indicative of first model-based criteria supported by a first device with respect to a shared model computation process, storing the information in accordance with a context corresponding to the first device, receiving a discovery request from a second device seeking at least one other device to participate in the shared model computation process, wherein the discovery request specifies second model-based criteria to be supported by the at least one other device being sought, checking for a match between the first model-based criteria and the second model-based criteria when the first device and the second device are proximate to one another, and sending a discovery response to the second device, in response to a match between the first model-based criteria and the second model-based criteria, to enable the second device and the first device to establish a security context to securely exchange data in accordance with the shared model computation process. The steps may be performed by at least one processor and at least one memory storing instructions executable by the at least one processor. As used herein, it is to be understood that the term “communication network” in some embodiments can comprise two or more separate communication networks. Further, the particular processing operations and other system functionality described in conjunction with the diagrams described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of processing operations and messaging protocols. For example, the ordering of the steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the steps may be repeated periodically, or multiple instances of the methods can be performed in parallel with one another. 5 It should again be emphasized that the various embodiments described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the claims. For example, alternative embodiments can utilize different communication system configurations, user equipment configurations, base station configurations, provisioning and usage processes, messaging protocols and message formats than those 10 described above in the context of the illustrative embodiments. These and numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.

Claims

What is claimed is:

1. An apparatus comprising:means for generating a message comprising information indicative of model-based criteria supported by the apparatus with respect to a shared model computation process; andmeans for sending the message to a network entity to enable the network entity to respond to a discovery request from a device seeking at least one other device to participate in the shared model computation process.

2. The apparatus of claim 1, wherein the information indicative of the model-based criteria comprises one or more model types and at least one model layer limit that the apparatus supports with respect to the shared model computation process.

3. The apparatus of claim 1, wherein inclusion of the information indicative of the model-based criteria in the message comprises an implicit consent by the apparatus to participate in the shared model computation process.

4. The apparatus of claim 1, wherein the message further comprises an explicit consent by the apparatus to participate in the shared model computation process.

5. The apparatus of claim 1, further comprising:means for participating in a direct communication process with the device that sent the discovery request, when in proximity therewith, to exchange data in accordance with the shared model computation process.

6. The apparatus of claim 1, further comprising:means for participating in establishment of a security context with the device to securely exchange data in accordance with the shared model computation process.

7. The apparatus of claim 6, wherein the security context specifies one or more of ciphering and integrity protection parameters to be used to securely exchange data in accordance with the shared model computation process.

8. The apparatus of claim 7, further comprising:means for securely receiving latency information, associated with the shared model computation process, from the device.

9. The apparatus of claim 1, wherein the shared model computation process comprises a split artificial intelligence / machine learning (AIML) model operation.

10. The apparatus of claim 9, wherein the apparatus comprises user equipment functioning as an AIML service provider.

11. The apparatus of claim 10, wherein the device that sent the discovery request comprises user equipment functioning as an AIML service consumer.

12. A method comprising:generating a message comprising information indicative of model-based criteria supported by first user equipment with respect to a shared model computation process; andsending the message to a network entity to enable the network entity to respond to a discovery request from second user equipment seeking other user equipment to participate in the shared model computation process;wherein the steps are performed by at least one processor and at least one memory storing instructions executable by the at least one processor.

13. An apparatus comprising:means for generating a discovery request seeking a device to participate in a shared model computation process, wherein the discovery request specifies model-based criteria to be supported by the device being sought; andmeans for sending the discovery request to a network entity to enable the network entity to respond to the discovery request.

14. The apparatus of claim 13, wherein the model-based criteria comprises a requested model type and a requested number of model layers to be supported by the device in accordance with the shared model computation process.

15. The apparatus of claim 13, further comprising:means for securely sending latency information, associated with the shared model computation process, to the device.

16. The apparatus of claim 13, wherein the shared model computation process comprises a split artificial intelligence / machine learning (AIML) model operation, the apparatus comprises user equipment functioning as an AIML service consumer, and the device comprises user equipment functioning as an AIML service provider.

17. A method comprising:generating a discovery request seeking user equipment to participate in a shared model computation process, wherein the discovery request specifies model-based criteria to be supported by the user equipment being sought; andsending the discovery request to a network entity to enable the network entity to respond to the discovery request;wherein the steps are performed by at least one processor and at least one memory storing instructions executable by the at least one processor.

18. An apparatus comprising:means for receiving a message comprising information indicative of first model-based criteria supported by a first device with respect to a shared model computation process; andmeans for storing the information in accordance with a context corresponding to the first device.

19. The apparatus of claim 18, further comprising:means for receiving a discovery request from a second device seeking at least one other device to participate in the shared model computation process, wherein the discovery requestspecifies second model-based criteria to be supported by the at least one other device being sought.

20. The apparatus of claim 19, further comprising:means for checking for a match between the first model-based criteria and the second model-based criteria when the first device and the second device are proximate to one another.

21. The apparatus of claim 20, further comprising:means for sending a discovery response to the second device, in response to a match between the first model-based criteria and the second model-based criteria, to enable the second device and the first device to establish a security context to securely exchange data in accordance with the shared model computation process.

22. The apparatus of claim 18, wherein the apparatus comprises a proximity service application server.

23. The apparatus of claim 22, wherein the shared model computation process comprises a split artificial intelligence / machine learning (AIML) model operation.

24. The apparatus of claim 23, wherein the first device comprises user equipment functioning as an AIML service provider and the second device comprises user equipment functioning as an AIML service consumer.

25. A method comprising:receiving a message comprising information indicative of first model-based criteria supported by a first device with respect to a shared model computation process;storing the information in accordance with a context corresponding to the first device;receiving a discovery request from a second device seeking at least one other device to participate in the shared model computation process, wherein the discovery request specifies second model-based criteria to be supported by the at least one other device being sought;checking for a match between the first model-based criteria and the second model-based criteria when the first device and the second device are proximate to one another; andsending a discovery response to the second device, in response to a match between the first model-based criteria and the second model-based criteria, to enable the second device and the first device to establish a security context to securely exchange data in accordance with the shared model computation process;5 wherein the steps are performed by at least one processor and at least one memorystoring instructions executable by the at least one processor.

Images