Data volume management for radio resource control messages

Abstract

Example embodiments of the present disclosure relate to data volume management for radio resource control (RRC) messages. According to example embodiments, a method may be provided, including segmenting, by a user equipment (UE), a dataset into a plurality of segments, each segment including metadata comprising a sequence number, a total segment count, and a data integrity value; and transmitting, by the UE, each of the plurality of segments as respective Radio Resource Control (RRC) reconfiguration messages to a network node, wherein upon receiving the RRC reconfiguration messages, the network node is configured to receive and buffer each of the plurality of segments from the RRC reconfiguration messages to reassemble the dataset based on the metadata.

Description

DATA VOLUME MANAGEMENT FOR RADIO RESOURCE CONTROL MESSAGESTECHNICAL FIELD

[0001] The present disclosure relates to data volume management for Radio Resource Control (RRC) messages.BACKGROUND

[0002] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0003] In the related art, a Radio Resource Control (RRC) message is a control plane message used in cellular communication (e.g., UMTS, LTE, and 5G) to manage the radio interface between a User Equipment (UE) and a base station (for example, eNodeB in LTE, gNB in 5G). These messages handle tasks like establishing and releasing connections, managing radio bearers, and facilitating mobility between cells.SUMMARY

[0004] In the related art, the RRC message protocol struggles to handle large amounts of data, like LI measurements for beam management and CSI feedback. These large data sets often surpass what a single RRC message can manage, leading to delays, data loss, and inefficiencies in data collection and transmission. Properly managing these large data volumes is essential for maintaining the quality of data used in AI / ML model training.

[0005] Accordingly, there is a need for an improved method for managing large data volumes for RRC messages.

[0006] Example embodiments of the present disclosure provide a system, method, and device for data volume management for radio resource control (RRC) messages. According to example embodiments, a base station may be provided. The base station may be configured to segment a dataset into a plurality of packets; and send each data packet of the plurality of packets as a Radio Resource Control (RRC) reconfiguration message to a user equipment (UE), wherein each RRC reconfiguration message comprises segmentation parameters, wherein upon receiving the RRC reconfiguration messages, the UE is configured to collect each data packet from the RRC reconfiguration message to reassemble the dataset based on the segmentation parameters.

[0007] Based on the above example embodiments, example effects which may be achieved by embodiments of the present disclosure may include being able to handle sending large data volumes over RRC messages, while ensuring the integrity of the dataset from compression and segmenting.

[0008] According to example embodiments, a method may be provided including compressing, by a user equipment (UE), measurement or reporting data to generate compressed data; and transmitting, by the UE, a compressed Radio Resource Control (RRC) reconfiguration message to a network node, wherein the compressed RRC message includes compression parameters specifying the compression and decompression algorithms, wherein upon receiving the compressed RRC reconfiguration message, the network node is configured to receive and decompress the compressed data based on the indicated decompression algorithm and verify the integrity of the decompressed data.

[0009] According to example embodiments, a user equipment (UE) may be provided and configured to: segment a dataset into a plurality of segments, each segment including metadata comprising a sequence number, a total segment count, and a data integrity value; and transmit each of the plurality of segments as respective Radio Resource Control (RRC) reconfiguration messages to a network node, wherein upon receiving the RRC reconfiguration messages, the network node is configured to receive and buffer each of the plurality of segments from the RRC reconfiguration messages to reassemble the dataset based on the metadata.

[0010] According to example embodiments, a user equipment (UE) may be provided and configured to compress measurement or reporting data to generate compressed data; and transmit a compressed Radio Resource Control (RRC) reconfiguration message to a network node, wherein the compressed RRC message includes compression parameters specifying the compression and decompression algorithms, wherein upon receiving the compressed RRC reconfiguration message, the network node is configured to receive and decompress the compressed data based on the indicated decompression algorithm and verify the integrity of the decompressed data.

[0011] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0013] FIG. 1 illustrates an example callflow diagram for segmenting and reassembling a dataset, according to one or more example embodiments;

[0014] FIG. 2 illustrates an example callflow diagram for compressing and decompressing a dataset, according to one or more example embodiments;

[0015] FIG. 3 illustrates a block diagram of an example method for data volume segmentation for RRC messages, according to one or more example embodiments;

[0016] FIG. 4 illustrates a block diagram of an example method for data volume compression for RRC messages, according to one or more example embodiments;

[0017] FIG. 5 illustrates an example structure of an RRC reconfiguration message including segmentation parameters, according to one or more example embodiments;

[0018] FIG. 6 illustrates an example calllflow diagram for performing segment error detection and recovery at then network node, according to one or more example embodiments;

[0019] FIG. 7 illustrates an example of UE and network capability interaction for large data optimization, according to one or more example embodiments;

[0020] FIG. 8 illustrates an example structure of modified RRC message format supporting compression parameters and payloads, according to one or more example embodiments;

[0021] FIG. 9 illustrates an example callflow diagram for lossless data compression and decompression, according to one or more example embodiments;

[0022] FIG. 10 illustrates a block diagram of an example device for implementing one or more example embodiments; and

[0023] FIG. 11 illustrates a block diagram of an example environment for implementing one or more example embodiments.DETAILED DESCRIPTION

[0024] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is notintended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0025] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the described implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0026] Even though particular combinations of features are disclosed in the claims and / or in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0027] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0028] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (0-RAN) Alliance standard organization, and the like.

[0029] According to example embodiments, segmentation, transmission, and reassembly of data may be performed in order to manage large data volumes for sending in RRC messages. In particular, large data sets, like extensive LI measurement logs or comprehensive CSI feedback, may be split into smaller segments that fit within the RRC message size limits.

[0030] According to example embodiments, segments may include metadata such as sequence numbers to indicate the segment's position in the overall data set, total segments to allow the receiver to know when all segments have been received, and checksum / data integrity information to ensure that each segment is received correctly without errors. Each segmented packet may be transmitted as a separate RRC message, ensuring that each message stays within the RRC protocol's size limits, preventing issues associated with oversized messages. Thisapproach avoids bottlenecks and potential data loss when transmitting large messages, allowing the network to handle each piece of data more efficiently.

[0031] At the receiving end, the network uses the sequence numbers and total segment information to accurately reassemble the original data set, ensuring data completeness and accuracy for subsequent use. If any segment is missing or corrupted, the network can request retransmission of that specific segment rather than the entire data set, minimizing the amount of data that needs to be resent and reducing overall transmission.

[0032] Example embodiments may also provide lossless compression techniques to maintain data integrity, ensuring no data is lost during the process. Example algorithms which may be used may be optimized for the types of data typically sent in RRC messages, such as LI RSRP measurements and CSI feedback, to efficiently compress these data types and reduce their size before transmission. On the network side, a corresponding decompression mechanism may be used to accurately reconstruct the original data from the compressed RRC messages, ensuring that the decompressed data matches the original data before compression. The decompression process introduces minimal latency to maintain the real-time requirements of the network and handle large volumes of data quickly to prevent delays in data processing and analysis.

[0033] Example embodiments may provide a base station. The base station may be configured to segment a dataset into a plurality of packets; and send each data packet of the plurality of packets as a Radio Resource Control (RRC) reconfiguration message to a user equipment (UE), wherein each RRC reconfiguration message comprises segmentation parameters, wherein upon receiving the RRC reconfiguration messages, the UE is configured to collect each data packet from the RRC reconfiguration message to reassemble the dataset based on the segmentation parameters.

[0034] According to example embodiments, the user equipment (UE) may be configured to receive a MSG 2 and / or MSG 4 instructions for Random Access Channel (RACH) from a network node / reader in order to adapt its delay, frequency, and / or power with respect to sending messages to the network node. For example, based on receiving a MSG 2 and / or MSG 4 instruction for RACH, the UE may be configured to increase its delay. Furthermore, the UE may be configured to use energy thresholds (which may be specified by the network node) for changing its behavior for sending messages. For example, the UE may only send messages when the UE’s power is above a predefined energy threshold specified by the network node.

[0035] Based on the above example embodiments, example effects which may be achieved by embodiments of the present disclosure may include being able to handle sending large data volumes over RRC messages, while ensuring the integrity of the dataset from compression and segmenting.

[0036] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.

[0037] FIG. 1 illustrates an example callflow diagram for segmenting and reassembling a dataset, according to one or more example embodiments.

[0038] User equipment (UE) 100 and base station 110 may be provided. Base station 110 may be, for example, eNodeB in LTE, gNB in 5G (and may be interchangeably referred to as the “network” or “network node” herein). It should be appreciated that although the example is illustrated in the direction of the UE 100 towards base station 110, the example callflow may beimplemented in the opposite direction as well (with the RRC message being sent from base station HO to UE 100).

[0039] At step 1, UE 100 may segment the dataset into packets. Segmentation parameters such as a sequence number, total number of segments, and a checksum may be included in each packet / segment as an information element (IE). Each segment may include a sequence number indicating the segment’s position in the overall dataset. This is so that the receiving end can reassemble the segments correctly. The total number of segments may also be included to allow the receiver to know when all the segments have been received. The checksum may also include integrity information to ensure that the segments are transmitted without error.

[0040] At step 2, UE 100 may send each data packet as an RRC reconfiguration message to base station 110. Each data packet is transmitted as a separate RRC message so as to ensure that each message stays within the RRC protocol’s size limits, and preventing issues with sending oversized messages. This is to avoid bottlenecks and potential data loss which typically occurs when transmitting large messages to improve network efficiency.

[0041] At step 3, base station 110 may reassemble the packets into the dataset. The network may use sequence numbers and total segment information in order to reassemble the dataset (e.g., the segmentation parameters provided in step 1). Firstly, the network may collect all the segments based on the sequence numbers to ensure all parts are received. The segments may be reassembled in the correct order to recreate the original large dataset.

[0042] At step 4, base station 110 may verify the integrity of the reassembled dataset. This step may be either performed during step 3 or sequentially after step 3. The checksum / integrity verification information may be used to ensure each segment was received correctly without errors.

[0043] At step 5, if the result in step 4 is that there was an error or the reassembled dataset is missing a data packet, base station 110 may request retransmission to UE 100. This may be in the case where a segment is missing or corrupted, and accordingly the network can request retransmission of only the specific segment which is needed. This may minimize the amount of data which needs to be sent.

[0044] At step 6, UE 100 may retransmit the data packets, and the process may return to step 3. Steps 3-6 may be repeated until there are no errors.

[0045] FIG. 2 illustrates an example callflow diagram for compressing and decompressing a dataset, according to one or more example embodiments.

[0046] UE 100 and base station 110 may be provided, similar to FIG. 1 above.

[0047] At step 1, UE 100 may compress the dataset. UE 100 may use a compression algorithm which is loss-less and optimized forRRC messages (e.g., Huffman coding). Data which may be compressed (for example, using Huffman coding) may include LI Reference Signal Received Power (RSRP) measurements and Channel State Information (CSI) feedback. Parameters may be included which specify targets for compression efficiency. As an example method of compression, the frequency of each character in the dataset may be calculated, a binarytree may be built using the frequencies, and codes may be assigned to characters based on their position in the tree. If there is any error during the compression, the error may be logged and compression may be repeated until it is correct.

[0048] At step 2, UE 100 may send the compressed dataset as a RRC reconfiguration message to base station 110. It should be appreciated that the RRC message may include the compression parameters as an information element (IE) with respect to the compression and decompression settings. This may specify an enumerated list of the compression algorithms anddecompression algorithms which should be used. The RRC message may additionally include the message type and the compressed data.

[0049] At step 3, base station 110 may decompress the message. This may be based on the compression parameter IE in the RRC message from step 2.

[0050] At step 4, base station 110 may verify the integrity of the decompressed message. If there is any error, the error may be logged and retransmission may be requested (in step 5).

[0051] At step 5, base station 110 may request retransmission if there was an error in step 4.

[0052] At step 6, UE 100 may retransmit the compressed dataset.

[0053] FIG. 3 illustrates a block diagram of an example method 300 for data volume segmentation for RRC messages, according to one or more example embodiments.

[0054] At operation S301, the UE (e.g., UE 100) may segment the dataset into a plurality of packets, including metadata. The meta data may include a sequence number, a total segment count, and a data integrity value.

[0055] At operation S302, the UE may transmit each segment of the plurality of segments as a respective RRC reconfiguration message to a network node (e.g., the base station). The RRC reconfiguration message may include the metadata in the form of segmentation parameters (e.g., as an information element) which may be used by the network node to reassemble the dataset.

[0056] At operation S303, the network node (base station) may receive the RRC reconfiguration message from the UE (as sent in operation S302).

[0057] At operation S304, the network node may buffers each segment to reassemble dataset based on metadata. This may be done by reordering the segments based on the sequence number and completeness may be verified using the total segment count.

[0058] As an optional step, at operation S305, the network node may also verify the integrity of the reassembled dataset by verifying the integrity of each received segment using the data integrity value. For example, if there is a failed checksum or missing sequence number. If there is an error / missing segment / data packet, the network node may request retransmission to the UE with an identifier of one or more data packets which failed validation.

[0059] FIG. 4 illustrates a block diagram of an example method for data volume compression for RRC messages, according to one or more example embodiments.

[0060] At operation S401, the UE may compress measurement or reporting data to send in RRC reconfiguration message. The compression may be specifically applied on LI RSRP measurements and CSI feedback using an example compression algorithm such as Huffman coding. The RRC reconfiguration message may also include compression parameters (for example, as an information element) including the compression algorithm and the decompression algorithm. The compression parameters may be specified based on an ASN.1 structure which includes the fields of the compression algorithm and the decompression algorithm. The Huffman coding may be performed using a predefined code table and frequency table which is shared between the UE and the network node.

[0061] It should be appreciated that according to some implementations, the UE may also determine whether or not the network node supports decompression. This may be performed based on a capability exchange for example. In the case decompression support is not supported / not available, the UE may use uncompressed transmission as a fallback.

[0062] At operation S402, the UE transmits the compressed RRC reconfiguration message to the network node.

[0063] At operation S403, the network node may decompress the RRC reconfiguration message based on a decompression algorithm.

[0064] At operation S404, the network node may verify the integrity of the decompressed data.

[0065] Optionally, at operation S405, the UE may receive a retransmission request from the network node based on verification of the integrity of the decompressed data failing in operation S404. According to example embodiments, the UE may receive an energy threshold value from the network node. This may be used, for example, to determine behavior of the UE for sending messages.

[0066] FIG. 5 illustrates an example structure of an RRC reconfiguration message including segmentation parameters, according to one or more example embodiments.

[0067] RRCReconfiguration 500 may be the parent element. radioBearerConfig 510 may be a child element to RRCReconfiguration 500 and may include segmentationparameters 520 which include sequenceNumber 521, total Segments 522, and checksum 523 (for integrity verification), similar to as described with respect to FIG. 1 and FIG. 3 above. The encoding used may be ASN.1, and may be useful to distinguish backward-compatible extensions.

[0068] FIG. 6 illustrates an example calllflow diagram for performing segment error detection and recovery at then network node, according to one or more example embodiments.

[0069] At step 1, UE 100 may transmit an N# of segments, gNB 110 (e.g., network node / base station). This may be similar to the process which is performed in FIG. 1 above.

[0070] At step 2, gNB 110 may determine that one segment is missing.

[0071] At step 3, accordingly, gNB 110 may determine that the checksum fails.

[0072] At step 4, gNB 110 may send a retransmission message to UE 100 based on the missing segment.

[0073] At step 5, UE 100 may retransmit the missing segments to gNB 110.

[0074] At step 6, gNB 110 may complete the reassembly after the last segment is validated.

[0075] FIG. 7 illustrates an example of UE and network capability interaction for large data optimization, according to one or more example embodiments.

[0076] At step 1, UE 100 may generate a UE capability report (which may include an element such as UEAssistancelnformation or OtherConfig, for example).

[0077] At step 2, the UE may indicate support for segmentation / compression to gNB 110.

[0078] At step 3, the network (gNB 110) may adapt the RRC procedure to be used withUE 100 accordingly.

[0079] FIG. 8 illustrates an example structure of modified RRC message format supporting compression parameters and payloads, according to one or more example embodiments.

[0080] RRCMessage 800 may be the parent element, and messageType 810 may be provided as a sub-element. The compressed data may be provided in compressedData820, and the compression parameters may be provided in compressionParamters 830 as subelements to messageType 810. The compressionParam eters830 may include a list of the specific compressionAlgorithm 831, and a list of the specific decompressionAlgorithm 832.

[0081] FIG. 9 illustrates an example callflow diagram for lossless data compression and decompression, according to one or more example embodiments.

[0082] At step 1, UE 100 may perform a compression algorithm denoted by compress().

[0083] At step 2, UE 100 may send the RRC message with the compressed payload to gNB110.

[0084] At step 3, gNB 110 may perform a decompression algorithm denoted by decompress!).

[0085] At step 4, gNB 110 may perform checksum verification.

[0086] Based on the above example embodiments, example effects which may be achieved by embodiments of the present disclosure may include being able to handle sending large data volumes over RRC messages, while ensuring the integrity of the dataset from compression and segmenting.

[0087] FIG. 10 illustrates a block diagram of an example device 1000 for implementing one or more example embodiments. As shown in FIG. 10, the device 1000 includes processor 1010, a memory 1020, a storage component 1030, an input component 1040, an output component 1050, a communication interface 1060, and a bus 1070.

[0088] The processor 1010, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 1010 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like. The processor 1010 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0089] Memory 1020 includes a non-transitory computer readable medium. Memory 1020 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 1010. The memory 1020 comprises machine-readable instructions which are executable by the processor 1010. Thesemachine-readable instructions when executed by the processor 1010 cause the processor 1010 to perform one or more method steps of an embodiment described above.

[0090] Storage component 1030 stores information and / or software related to the operation and use of the device 1000. For example, storage component 1030 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0091] Input component 1040 is configured to receive information, such as user input. For example, the input component 1040 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 1040 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0092] Output component 1050 is configured to provide output information from the device 1000. For example, the output component 1050 may be, but not limited to, a display, a speaker, an instruction device to an external device, and / or one or more light-emitting diodes (LEDs).

[0093] Communication interface 1060 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 1060 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 1000 and other devices. In other words, the standard of the communication interface 1060 is not limited.

[0094] The bus 1070 acts as an interconnect between the processor 1010, the memory 1020, the storage component 1030, the input component 1040, the output component 1050, and the communication interface 1060 of the device 1000. The bus 1070 may include a wired interconnection or a wireless interconnection.

[0095] The number and arrangement of components shown in FIG. 10 are provided as an example. In practice, device 1000 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 10. Additionally, or alternatively, a set of components (e.g., one or more components) of device 1000 may perform one or more functions described as being performed by another set of components of device 1000. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 1000 in communication with one another.

[0096] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0097] FIG. 11 illustrates a block diagram of an example environment 1100 for implementing in which systems and / or method, described herein, may be implemented. The implementation environment 1100 includes a UE (User equipment) 1110, a service environment1120, and a network 1130. The service environment 1120 include one or more sub-environments1121. To illustrate this, FIG. 11 shows, for convenience, examples of a 1st sub-environment 1121- 1, a 2nd sub-environment 1121-2, and an N-th sub-environment 1121-N (where N is any natural number).

[0098] The UE 1110 is connected to the network 1130, and the network 1130 is connected to the service environment 1 120. The connections may be wired, wireless, or a combination ofboth wired and wireless. The UE 1110 and the service environment 1120 are connected via the network 1130.

[0099] The UE 1110 is a device that communicates with the service environment 1120. The UE 1110 receives information from the service environment 1120 and / or sends information to the service environment 1120. Also, the UE 1110 may generate and / or store information to be transmitted, as necessary. Also, the UE 1110 may store and / or process information that is received, as necessary.

[0100] The example FIG. 11 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,” “communication device,” and “communication terminal” can be used interchangeably with the term “UE.”

[0101] For example, the UE 1110 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0102] The service environment 1120 is an environment that communicates with the UE 1110 to provide one or more services. The service environment 1120 receives information from the UE 1110 and / or sends information to the UE 1110. Also, the service environment 1120 may generate and / or store information to be transmitted, as necessary. Also, the service environment 1120 may store and / or process information that is received, as necessary. For example, the service environment 1120 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may performprocesses such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0103] The example FIG. 11 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the "service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted. For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment."

[0104] The one or more services provided by the service environment 1120 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 1110, a service that stores information from the UE 1110, or a service that performs processing based on information from the UE 1110 and returns the results of the processing.

[0105] In an embodiment, the Service Environments 1120 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0106] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtualresources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0107] The service environment 1120 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 1120 can be determined as appropriate. Additionally, if the service environment 1120 includes one or more sub-environments 1121, the placement of devices can be determined based on predetermined policies for each sub-environment 1121. For example, devices related to the first service may be placed in the 1st sub-environment 1121-1, and devices related to the second service may be placed in the 2nd sub-environment 1121-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st sub-environment 1121-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 1121-2. In this way, specific devices can be placed in specific sub-environments 1121. Conversely, each sub-environment 1121 can be specialized for a particular purpose.

[0108] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0109] The network 1130 is a network that exchanges information between the UE 1110 and the service environment 1120. The network 1130 includes one or more wired and / or wireless networks.

[0110] For example, the network 1130 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.[0U1] The network 1130 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 1130 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 1120 could be in the core network, in which case the network 1130 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0112] The number and arrangement of devices and networks shown in FIG. 11 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.Various Aspects of Embodiments

[0113] It is contemplated that the example embodiments described hereinabove with reference to FIG. 1 to FIG. 11 are merely examples of possible embodiments of the present disclosure, and are not intended to limit or restrict the scope of the present disclosure.

[0114] Specifically, the foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0115] Some embodiments may relate to a device (e.g., node, etc.), a system, a method, and / or a computer-readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non- transitory storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out operations.

[0116] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact discread-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0117] Computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0118] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0119] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer- readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0120] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer- readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0121] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operationalsteps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0122] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer- readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0123] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the implementations. Thus, the operation and behavior of the systemsand / or methods were described herein without reference to specific software code — it is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0124] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A method comprising: segmenting, by a user equipment (UE), a dataset into a plurality of segments, each segment including metadata comprising a sequence number, a total segment count, and a data integrity value; and transmitting, by the UE, each of the plurality of segments as respective Radio Resource Control (RRC) reconfiguration messages to a network node, wherein upon receiving the RRC reconfiguration messages, the network node is configured to receive and buffer each of the plurality of segments from the RRC reconfiguration messages to reassemble the dataset based on the metadata.Item [2]: The method according to Item [1], wherein the network node is configured to reassemble the dataset by verifying the integrity of each received segment using the data integrity value, and reconstruct the dataset by reordering the segments based on the sequence number and verify completeness using the total segment count.Item [3]: The method according to any one of Items [l]-[2], further comprising: receiving, by the UE, a retransmission request from the network node comprising an identifier of any missing or corrupted segments based on a failed checksum or missing sequence number.Item [4]: The method according to any one of Items [l]-[3], wherein the metadata is specified in the RRC reconfiguration message as a segmentation parameter information elementItem [5]: A method including compressing, by a user equipment (UE), measurement or reporting data to generate compressed data; and transmitting, by the UE, a compressed Radio Resource Control (RRC) reconfiguration message to a network node, wherein the compressed RRC message includes compression parameters specifying the compression and decompression algorithms, wherein upon receiving the compressed RRC reconfiguration message, the network node is configured to receive and decompress the compressed data based on the indicated decompression algorithm and verify the integrity of the decompressed data.Item [6]: The method according to Item [5], wherein compression is performed using Huffman coding based on a predefined code table and frequency table shared between the UE and the network node.Item [7]: The method according to any one of Items [5]-[6], wherein the compression parameters are specified in the RRC reconfiguration message based on an ASN.1 structure including fields of the compression algorithm and decompression algorithm.Item [8]: The method according to any one of Items [5]-[7], further comprising: determining, by the UE based on a capability exchange, whether the network node supports decompression, wherein uncompressed transmission is used as a fallback if decompression support is not available.Item [9]: The method according to any one of Items [5]-[8], wherein the measurement or reporting data includes LI measurements or CSI feedback reports.Item

[0010] : The method according to any one of Items [5]-[9], further comprising: receiving, by the UE, at least one energy threshold from the network node.Item

[0011] : A user equipment (UE) configured to: segment a dataset into a plurality of segments, each segment including metadata comprising a sequence number, a total segment count, and a data integrity value; and transmit each of the plurality of segments as respective Radio Resource Control (RRC) reconfiguration messages to a network node, wherein upon receiving the RRC reconfiguration messages, the network node is configured to receive and buffer each of the plurality of segments from the RRC reconfiguration messages to reassemble the dataset based on the metadata.Item

[0012] : The UE according to Item

[0011] , wherein the network node is configured to reassemble the dataset by verifying the integrity of each received segment using the data integrity value, and reconstruct the dataset by reordering the segments based on the sequence number and verify completeness using the total segment count.Item

[0013] : The UE according to any one of Items

[0011] -

[0012] , further configured to: receive a retransmission request from the network node comprising an identifier of any missing or corrupted segments based on a failed checksum or missing sequence number.Item

[0014] : The UE according to any one of Items

[0011] -

[0013] , wherein the metadata is specified in the RRC reconfiguration message as a segmentation parameter information elementItem

[0015] : A user equipment (UE) configured to: compress measurement or reporting data to generate compressed data; and transmit a compressed Radio Resource Control (RRC) reconfiguration message to a network node, wherein the compressed RRC message includes compression parameters specifying the compression and decompression algorithms, wherein upon receiving the compressed RRC reconfiguration message, the network node is configured to receive and decompress the compressed data based on the indicated decompression algorithm and verify the integrity of the decompressed data.Item

[0016] : The UE according to Item

[0015] , wherein compression is performed using Huffman coding based on a predefined code table and frequency table shared between the UE and the network node.Item

[0017] : The UE according to any one of Items

[0015] -

[0016] , wherein the compression parameters are specified in the RRC reconfiguration message based on an ASN.1 structure including fields of the compression algorithm and decompression algorithm.Item

[0018] : The UE according to any one of Items

[0015] -

[0017] , further configured to: determine based on a capability exchange, whether the network node supports decompression, wherein uncompressed transmission is used as a fallback if decompression support is not available.Item

[0019] : The UE according to any one of Items

[0015] -

[0018] , wherein the measurement or reporting data includes LI measurements or CSI feedback reports.Item

[0020] : The UE according to any one of Items

[0015] -

[0019] , further configured to: receive at least one energy threshold from the network node.It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A method comprising: segmenting, by a user equipment (UE), a dataset into a plurality of segments, each segment including metadata comprising a sequence number, a total segment count, and a data integrity value; and transmitting, by the UE, each of the plurality of segments as respective Radio Resource Control (RRC) reconfiguration messages to a network node, wherein upon receiving the RRC reconfiguration messages, the network node is configured to receive and buffer each of the plurality of segments from the RRC reconfiguration messages to reassemble the dataset based on the metadata.

2. The method as claimed in claim 1, wherein the network node is configured to reassemble the dataset by verifying the integrity of each received segment using the data integrity value, and reconstruct the dataset by reordering the segments based on the sequence number and verify completeness using the total segment count.

3. The method as claimed in claim 1, further comprising: receiving, by the UE, a retransmission request from the network node comprising an identifier of any missing or corrupted segments based on a failed checksum or missing sequence number.

4. The method as claimed in claim 1, wherein the metadata is specified in the RRC reconfiguration message as a segmentation parameter information element5. A method comprising: compressing, by a user equipment (UE), measurement or reporting data to generate compressed data; and transmitting, by the UE, a compressed Radio Resource Control (RRC) reconfiguration message to a network node, wherein the compressed RRC message includes compression parameters specifying the compression and decompression algorithms, wherein upon receiving the compressed RRC reconfiguration message, the network node is configured to receive and decompress the compressed data based on the indicated decompression algorithm and verify the integrity of the decompressed data.

6. The method as claimed in claim 5, wherein compression is performed using Huffman coding based on a predefined code table and frequency table shared between the UE and the network node.

7. The method as claimed in claim 5, wherein the compression parameters are specified in the RRC reconfiguration message based on an ASN.1 structure including fields of the compression algorithm and decompression algorithm.

8. The method as claimed in claim 5, further comprising: determining, by the UE based on a capability exchange, whether the network node supports decompression, wherein uncompressed transmission is used as a fallback if decompression support is not available.

9. The method as claimed in claim 5, wherein the measurement or reporting data includes LI measurements or CSI feedback reports.

10. The method as claimed in claim 5, further comprising: receiving, by the UE, at least one energy threshold from the network node.

11. A user equipment (UE) configured to: segment a dataset into a plurality of segments, each segment including metadata comprising a sequence number, a total segment count, and a data integrity value; and transmit each of the plurality of segments as respective Radio Resource Control (RRC) reconfiguration messages to a network node, wherein upon receiving the RRC reconfiguration messages, the network node is configured to receive and buffer each of the plurality of segments from the RRC reconfiguration messages to reassemble the dataset based on the metadata.

12. The UE as claimed in claim 11, wherein the network node is configured to reassemble the dataset by verifying the integrity of each received segment using the data integrity value, and reconstruct the dataset by reordering the segments based on the sequence number and verify completeness using the total segment count.

13. The UE as claimed in claim 11, further configured to: receive a retransmission request from the network node comprising an identifier of any missing or corrupted segments based on a failed checksum or missing sequence number.

14. The UE as claimed in claim 11, wherein the metadata is specified in the RRC reconfiguration message as a segmentation parameter information element15. A user equipment (UE) configured to: compress measurement or reporting data to generate compressed data; and transmit a compressed Radio Resource Control (RRC) reconfiguration message to a network node, wherein the compressed RRC message includes compression parameters specifying the compression and decompression algorithms, wherein upon receiving the compressed RRC reconfiguration message, the network node is configured to receive and decompress the compressed data based on the indicated decompression algorithm and verify the integrity of the decompressed data.

16. The UE as claimed in claim 15, wherein compression is performed using Huffman coding based on a predefined code table and frequency table shared between the UE and the network node.

17. The UE as claimed in claim 15, wherein the compression parameters are specified in the RRC reconfiguration message based on an ASN.1 structure including fields of the compression algorithm and decompression algorithm.

18. The UE as claimed in claim 15, further configured to:determine based on a capability exchange, whether the network node supports decompression, wherein uncompressed transmission is used as a fallback if decompression support is not available.

19. The UE as claimed in claim 15, wherein the measurement or reporting data includes LI measurements or CSI feedback reports.

20. The UE as claimed in claim 15, further configured to: receive at least one energy threshold from the network node.

Images