Logging different failure types for on-demand system information request procedures

Abstract

A method (800) by a wireless device (212A-D) for reporting information associated with an on-demand system information (SI) request includes transmitting (802) information associated with the on-demand SI request to a network node (210A-B), the information indicating whether the on-demand SI request was successful or not.

Description

[Technical Field]

[0001] The present disclosure relates generally to wireless communications, and more particularly to a system and method for logging different failure types for on-demand system information (SI) request procedures. [Background technology]

[0002] On-demand system information (SI) acquisition is specified as part of 3GPP TS38.331 v.16.4.0, which discloses in section 5.2.2 that system information blocks (SIBs) may or may not be broadcast. If an SIB is broadcast, si-BroadcastStatus is set to broadcasting and the periodicity of the broadcasted SIB is provided as part of si-BroadcastStatus.

[0003] If SI is not broadcast, there are two ways for a user equipment device (UE) to request the desired SI. The first method is a message 1 (MSG1)-based system information request. In this method, the si-BroadcastStatus of the SIB type is set to notbroadcasting. If the UE is interested in reading at least one SIB, it must determine which random access channel (RACH) resource should be used to notify the network to broadcast the required SIB according to the si-RequestConfig. However, si-RequestConfig is an optional field and is present only if RACH resources are configured for SI requests from the UE. Conversely, if si-RequestConfig is not present or if RACH resources are configured for on-demand SI requests, the UE can use the second method, a message 3 (MSG3)-based system information request. In this scenario, the UE initiates an RRCSystemInfoRequest to request the desired SI from the network.

[0004] In both methods of requesting SI, a RACH procedure needs to be initiated (based on configuration in the MSG1-based method and based on contention in the MSG3-based solution). If the random access (RA) procedure is successful, an ra-Report is logged by the UE. The ra-Report indicates the performance of the RA procedure. The contents of the RA procedure are disclosed in 3GPP TS38.331. In particular, the procedure for on-demand SI request in connected mode is disclosed in sections 5.2.2.3.5 and 5.2.2.3.6 of 3GPP TS38.331. However, if the UE fails the random access procedure to request system information, there is no operation in the UE to log the failed random access related information.

[0005] However, there are currently challenges. For example, according to 3GPP TS38.321 v.16.4.0, when triggering an on-demand request for an SI (e.g., SIB) with broadcast status set to notbroadcasting, if RACH resources are provided as part of the si-RequestConfig, the UE must receive an acknowledgement message from the lower layer. For example, the UE may receive an acknowledgement from the Medium Access Control (MAC) layer, as specified in 3GPP TS38.321. The acknowledgement from the lower layer may trigger the acquisition of the requested on-demand SI / SIB, as defined in section 5.2.2.3.2 of 3GPP TS38.331.

[0006] However, there may be different conditions that result in the UE failing to receive the requested SI. For example, in the first case, an on-demand SI / SIB request may fail due to problems with transmitting the preamble and receiving the Random Access Response (RAR) message at the MAC layer. For example, the UE may not be in a location with good uplink coverage, which could result in the failure to transmit the preamble dedicated to the on-demand SI / SIB request. As another example, the preamble may be successfully transmitted by the UE and received by the network node, but downlink coverage issues could cause the network node to fail to transmit the RAR message.

[0007] As another example, in the second case, the UE may successfully transmit a preamble and receive an RAR indicating that the network node received the transmitted preamble. However, due to coverage issues, the UE may not be able to obtain the requested on-demand SI / SIB. Alternatively, the UE may not be able to obtain the SI / SIB it requested because the network has decided not to transmit the SI / SIB via either broadcast or dedicated RRC signaling. However, in either of these scenarios, the network has no knowledge of these types of failures. Summary of the Invention

[0008] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these and other problems. For example, a method and system are provided that uses a new set of information logged by the UE regarding an on-demand SI / SIB request procedure. The new set of information logged by the UE and reported to the RAN node (and / or OAM) allows the RAN node or OAM to analyze and understand whether a failure in the procedure occurred at the MAC layer (sending the preamble or receiving the RAR and SI request acknowledgment) or at the stage of retrieving the SIB or SI message after receiving the SI request acknowledgment from the lower layer.

[0009] According to certain embodiments, a method by a wireless device for reporting information associated with an on-demand SI request includes transmitting information associated with the on-demand SI request to a network node, the information indicating that the on-demand SI request was successful or that the on-demand SI request was unsuccessful.

[0010] According to a particular embodiment, a wireless device for reporting information associated with an on-demand SI request is adapted to transmit information associated with the on-demand SI request to a network node, the information indicating whether the on-demand SI request was successful or not.

[0011] According to certain embodiments, a method by a network node for processing information associated with an on-demand SI request includes receiving information associated with the on-demand SI request of a wireless device, the information indicating that the on-demand SI request was successful or that the on-demand SI request was unsuccessful.

[0012] According to certain embodiments, a network node for processing information associated with an on-demand SI request is adapted to receive information associated with the on-demand SI request of a wireless device, the information indicating that the on-demand SI request was successful or that the on-demand SI request was unsuccessful.

[0013] Certain embodiments may provide one or more of the following technical advantages. For example, certain embodiments may provide a technical advantage of enabling a network node or operation and maintenance (OAM) receiving measurements and information regarding on-demand SI / SIB requests to determine whether the problem causing the failure in the procedure is related to the lower layer acquiring the SIB or SI message. Specifically, for example, the network node or OAM may determine whether the failure is related to the MAC layer of the RRC layer. Therefore, certain embodiments may provide a technical advantage of enabling the network to take countermeasures, such as optimizing the MAC layer or the request procedure for acquiring the SI. For example, if the information indicates that the wireless device did not successfully transmit a preamble or receive an RAR procedure, the network node may need to re-optimize the SSB downlink / uplink coverage. However, if a failure occurs in the stage of acquiring the SIB or SI message, the network node may optimize the SI broadcast or unicast procedure.

[0014] As another example, certain embodiments may provide a technical advantage of enabling a wireless device to log and report to the network whether the wireless device listens to the SI window to obtain an SIB or SI message before the actual transmission of a preamble. Knowing whether the wireless device listens to the SI window before transmitting a preamble helps a network node optimize the broadcast of SI messages. In fact, if there are many wireless devices that check the SI window before transmitting a preamble, it may be better for the network node to broadcast an SIB or SI message on all beams for each preamble received. This increases the likelihood that other UEs will receive the SIB or SI message before requesting it. However, if a wireless device does not listen to the SI window before transmitting a preamble, the network does not need to broadcast the SIB or SI message on all beams because other wireless devices may not listen.

[0015] Other advantages will be readily apparent to those skilled in the art. Particular embodiments may have none, some, or all of the described advantages. [Brief explanation of the drawings]

[0016] For a more complete understanding of the disclosed embodiments and their features and advantages, reference is made to the following descriptions taken in conjunction with the accompanying drawings, in which:

[0017] [Figure 1] 1 illustrates various network operations based on wireless device operations in accordance with certain embodiments. [Figure 2] FIG. 1 illustrates an exemplary communication system in accordance with certain embodiments. [Figure 3] FIG. 1 illustrates an exemplary UE in accordance with certain embodiments. [Figure 4] FIG. 1 illustrates an exemplary network node according to certain embodiments. [Figure 5]FIG. 2 is a block diagram of a host according to certain embodiments. [Figure 6] FIG. 1 illustrates a virtualization environment in which functionality implemented by some embodiments may be virtualized, according to certain embodiments. [Figure 7] FIG. 1 illustrates a host communicating with a UE over a partially wireless connection via a network node in accordance with certain embodiments. [Figure 8] A diagram illustrating a method by a wireless device for reporting information related to an on-demand SI / SIB request according to a particular embodiment. [Figure 9] A diagram illustrating a method by a network node for processing information related to an on-demand SI / SIB request according to a particular embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0018] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. The embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. However, other embodiments are within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0019] In general, all terms used herein shall be interpreted according to their ordinary meaning in the relevant technical field unless a different meaning is clearly given and / or is implied from the context in which they are used. All references to elements, devices, components, means, steps, etc. shall be openly interpreted as referring to at least one instance of that element, device, component, means, step, etc., unless expressly stated otherwise. The steps of methods disclosed herein need not be performed in the exact order disclosed, unless a step is explicitly described as following or preceding other steps and / or is implicitly described as having to follow or precede other steps. Any feature of the embodiments disclosed herein may also be applied to other embodiments, where appropriate. Similarly, any advantage of any embodiment may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the enclosed embodiments will become apparent from the following description.

[0020] In some embodiments, the more general term "network node" may be used and may correspond to any type of radio network node or any network node that communicates with UEs (directly or via another node) and / or with another network node. Examples of network nodes include a NodeB, a master eNodeB (MeNB), a network node belonging to a master cell group (MCG) or a secondary cell group (SCG), a base station (BS), a multi-standard radio (MSR) radio node such as an MSR_BS, an eNodeB (eNB), a gNodeB (gNB), a network controller, a radio network controller (RNC), a base station controller (BSC), a repeater, a donor node controlled repeater, a base transceiver station (BTS), an access point (AP), a transmission point, a transmitting node, a remote radio unit (RRU), a remote radio head (RRH), a node in a distributed antenna system (DAS), a core network node (e.g., a mobile switching center (MSC), a mobility management entity (MME), etc.), an operation and maintenance (O&M), an operation support system (OSS), a self-organizing network (SON), a positioning node (e.g., an evolved serving mobile location center (E-SMLC)), a minimization of drive test (MDT), and test equipment (physical node or software).

[0021] In some embodiments, the non-limiting terms user equipment (UE) or wireless device may be used and may refer to any type of wireless device that communicates with network nodes and / or other UEs in a cellular or mobile communication system. Examples of UEs include target devices, device-to-device (D2D) UEs, machine-type UEs or UEs capable of machine-to-machine (M2M) communications, personal digital assistants (PDAs), tablets, handheld devices, smartphones, laptop embedded devices (LEEs), laptop mounted devices (LMEs), unified serial bus (USB) dongles, UE category M1, UE category M2, proximity services UEs (ProSeUEs), vehicle-to-vehicle UDs (V2V_UEs), vehicle-to-any UEs (V2X_UEs), etc.

[0022] Furthermore, terms such as base station / gNB and UE should be considered non-limiting and do not imply any particular hierarchical relationship between the two. Generally, a "gNB" is considered device 1 and a "UE" is considered device 2, and these two devices communicate with each other over some wireless channel. And hereafter, a transmitter or receiver is either a gNB or a UE.

[0023] The embodiments described herein are applicable to both Long Term Evolution (LTE) and New Radio (NR) Radio Access Network (RAN) nodes.

[0024] The inhibit timers described here are mapped to timer T350 in 3GPP TS38.331 and vice versa.

[0025] According to certain embodiments, network node and RAN node are used interchangeably. Non-limiting examples of network node or RAN node may be eNB, gNB, gNB-aggregation unit (gNB-CU), gNB-CU-control plane (gNB-CU-CP), gNB-distributed unit (gNB-DU).

[0026] While the term "on-demand SI" is used herein, it is recognized that this term may also be interchanged with "on-demand SIB," "on-demand SIBs," or "on-demand SIB(s)" without loss of meaning. In general, "SI," "SIB," "SIBs," and "SIB(s)" may be used interchangeably without loss of meaning. According to certain embodiments, a method is provided that is performed by a wireless device, such as a UE. The method includes logging, by the wireless device, information related to actions by the wireless device upon receiving a request to obtain an on-demand SI / SIB. According to various specific embodiments, the wireless device may log any one or more of the following information: · An indication of whether the on-demand SI / SIB request was successful (where success means that the UE sent the request and the UE received the requested SIB or SI message from the network); · an indication of whether an acknowledgment to the SI request has been received from a lower layer (wherein, as used herein, the term lower layer includes a physical (PHY) layer, a medium access control (MAC) layer, or a radio link control (RLC) layer); · An indication of whether there was a failure to retrieve a SIB or SI message while an acknowledgment to a SIB or SI request was successfully received from the lower layer; · An indication of whether a SIB or SI message was successfully retrieved while an acknowledgment for the SIB or SI request was not received from the lower layer; · An indication that the UE requested SIBx, SIBy, and SIBz, but the UE received only SIBx (or another SIB less than all of the requested SIBs); ·An indication of whether the UE has checked the SI window for the required SIB or SI message before initiating the on-demand SIB / SI request procedure; · An indication of how many SI window opportunities the UE has monitored to receive SIB or SI messages; · an indication of the number of attempts by the UE to receive the requested SI message, if a downlink scheduling allocation addressed to the SI-RNTI is received in the SI window associated with the associated SI message; ·If the UE used the DedicatedSIBRequest RRC message to request SI in the RRC_CONNECTED state, the number of HARQ retransmissions made by the UE when it sent the DedicatedSIBRequest message; In the case of an SI request using the RRC message DedicatedSIBRequest or RRCSystemInfoRequest in the RRC_CONNECTED state, an indication of whether the UE has received an acknowledgement from the lower layers according to the Hybrid Automatic Repeat Request (HARQ) procedure; and / or · An indication of whether the UE has received an acknowledgement from the RLC lower layers in response to a transmission by the UE in RRC_CONNECTED or DedicatedSIBRequest message to request an on-demand SI / SIB.

[0027] According to certain embodiments, the wireless device logs any of the above information as part of existing UE reports, such as a Connection Establishment Failure (CEF) report, a RACH report, or an RA report, or this information may be logged and provided as a new report dedicated to providing information and measurements related to on-demand SI / SIB requests.

[0028] Alternatively, according to certain embodiments, the wireless device may store information in a structure different from the report format, and the wireless device may construct a report using the stored information when the UE is triggered, such as when the UE receives a request from the network to send a report regarding all or a portion of the logged / stored information.

[0029] According to particular embodiments, the wireless device logs radio link quality received from an SSB beam providing coverage to the wireless device when obtaining the requested SI / SIB. In further particular embodiments, the logged information related to radio link quality may include one or more of Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), Signal-to-Interference-to-Noise Ratio (SINR), Signal-to-Noise Ratio (SNR), Received Signal Strength Indicator (RSSI), path loss, etc. Additionally or alternatively, the logged information may include location information at the time the wireless device initiated the on-demand SI / SIB request.

[0030] According to certain other embodiments, the wireless device reports radio link quality measurements of serving cell measurements and neighbor cell measurements as part of an on-demand SI / SIB request related report. In certain embodiments, for example, the logged information related to radio link quality may include one or more of RSRP, RSRQ, SINR, SNR, RSSI, path loss, etc. Additionally or alternatively, the information may include location information of the wireless device at the time the wireless device initiated the on-demand SI / SIB request.

[0031] In particular embodiments, the wireless device logs the cell ID of the cell for which the SI / SIB request is performed. The cell ID may include a Cell Global ID (CGI), and / or a Physical Cell ID (PCI), and the operating frequency information of the cell. The UE may also, in various particular embodiments, log the Tracking Area Code and Public Land Mobile Network (PLMN) ID of the cell for which the on-demand SI / SIB message is requested.

[0032] In particular embodiments, the wireless device may also log GNSS location information (e.g., obtained via Global Positioning System (GPS), Galileo, Global Navigation Satellite System (GLONASS), or BeiDou) at the time the wireless device initiated the on-demand SI / SIB request. Optionally, the location information may be supplemented with information regarding the speed and / or direction of movement of the wireless device.

[0033] In certain embodiments, after logging the information and measurements related to the on-demand SI / SIB request, the wireless device indicates the availability of a corresponding report to the network, e.g., a network node, etc. Upon receiving a fetch request from the network, the wireless device signals the report including the information and measurements related to the on-demand SI / SIB request to the network.

[0034] In certain embodiments, reports containing information about measurements and on-demand SI / SIB requests are transferred between Radio Access Network (RAN) nodes via RAN node-to-RAN node signaling over RAN node-to-RAN node interfaces, such as the Xn, NG, and F1 interfaces. Thus, network nodes can transmit / forward / exchange information received from wireless devices with each other.

[0035] In certain embodiments, in a report containing feedback information related to an on-demand SI / SIB request, such as a RACH report in LTE, an RA report in NR, a CEF report, or a report dedicated to this purpose, i.e., an SI request report, the UE can include information indicating all SIB(s) of other SIs that the UE is interested in and needs to receive. This includes both SIB(s) that are broadcast or not broadcast in the cell and SIB(s) that are not broadcast. This information is useful for the network to determine which SIBs of other SIs should be broadcast and which SIBs are available on demand. As an option, this information indicates which SIBs are available in the cell (broadcast or available on demand) that the UE is interested in. As another option, the information may also indicate that the UE is interested in one or more SIB(s) designated as belonging to other SIs that are not available in the cell (either broadcast or on-demand), e.g., among all SIB(s) designated as SIBs of other SIs in the 3rd Generation Partnership Project (3GPP) standard or in a particular release of the 3GPP standard, the information may indicate which SIB(s) of other SIs the UE is interested in.

[0036] Signaling to the network According to certain embodiments, the wireless device logs some, all, or any of the above information and measurements in an existing report, e.g., a RACH report or RA report (such as the RA-Report-r16 IE in NR), or a dedicated report purposely designed for on-demand SI / SIB requests (e.g., either the new IEs denoted as SI-RequestReport or SI-RequestReport-r17).

[0037] In a particular embodiment, the wireless device logs a list of multiple chunks (up to X) of on-demand SI / SIB request related information, and / or measurement results, and / or sets of on-demand SI / SIB request related parameters or IEs in a dedicated report or an existing report (extended with this new type of information).

[0038] Upon logging the information related to the on-demand SI / SIB request, the wireless device indicates the availability of a report containing the on-demand SI / SIB request related information to the network node, and the network node requests the fetching of the report via a solicitation mechanism, e.g., a UE information request / response procedure.

[0039] In certain embodiments, the network node may not wait for an availability signal from the wireless device, and upon receiving a request for on-demand SI (i.e., a DedicatedSIBRequest message) from a wireless device in the RRC_CONNECTED state, the network may begin fetching information related to the on-demand SI request, for example, using a UE information request / response procedure.

[0040] Furthermore, in another particular embodiment, when transmitting an on-demand SI / SIB request, the wireless device by default includes a report containing on-demand SI / SIB request-related information of a previous on-demand SI / SIB request. For example, if the wireless device requests an SI / SIB in an RRC_IDLE or RRC_INACTIVE state and later transitions to an RRC_CONNECTED state, the wireless device transmits the report (without a preceding request) to the network (e.g., a gNB or eNB) after the RRC connection is established.

[0041] In some embodiments, if a report containing information about an on-demand SI request is fetched by a different RAN node (e.g., gNB-CU_2) than the RAN node from which the SI was primarily requested (e.g., if the SI request was sent in a cell owned by another RAN node (e.g., gNB-CU_1)), the RAN node receiving the report (containing the measurement results and information about the on-demand SI request (gNB-CU_2)) must forward the report to the RAN node from which the on-demand SI / SIB request was made (gNB-CU_1). The report may, in certain embodiments, be sent over a RAN node-to-RAN node interface, such as the Xn or NG interface.

[0042] In other embodiments, in the above scenario, the RAN node receiving the report (e.g., gNB-CU_2) can instead send the report to the O&M system, which can process the report and initiate action at the RAN node (e.g., gNB-CU_1) related to the information in the report. Alternatively, the O&M system, in certain embodiments, can forward the report to the relevant RAN node (e.g., gNB-CU_1) and have the RAN node itself process the report and initiate possible action.

[0043] In certain embodiments, when the gNB-DU is the one that determines and optimizes MAC layer procedures, a gNB-CU that receives a report (either directly from a wireless device or from another node (e.g., another gNB-CU or an entity in the O&M system)) containing on-demand SI request related information may forward the report (or a portion of the report) to the gNB-DU via the F1 interface.

[0044] Processing of on-demand SI / SIB request information in network nodes According to certain embodiments, the network uses feedback information related to the on-demand SI / SIB request from the UE to optimize relevant and related aspects of the network. In particular, a network node that receives measurement results and information related to the on-demand SI / SIB request uses the reports to optimize SI / SIB transmissions. Thus, the network can use such received information to optimize, adapt, adjust, modify, or change aspects related to the configuration. For example, according to various specific embodiments, the network node can perform any one or more of the following: - Change how SIBs are grouped into different SI messages For example, in certain embodiments, if the network notices that it is common for the same wireless device to request a set of SIBs, perhaps in consecutive SI requests, the network may choose to change the mapping of SIBs to SI messages so that related SIBs are included in the same SI message. - Change whether SIB / SI messages are broadcast or not For example, in certain embodiments, if the network notices that a certain SIB or SI message is frequently requested and of interest to many wireless devices, the network may choose to change the delivery principle of that SI / SIB message from on-demand to broadcast. - Varying the amount of physical random access channel (PRACH) resources dedicated to SI / SIB requestsFor example, in a particular embodiment, if the network notices that SI / SIB requests often fail, this may be an indication of frequent collisions or that more SI / SIB requests based on Msg1 are being sent on the same PRACH opportunity than the receiving base station (e.g., gNB) can handle, which may mean that it would be beneficial to increase the amount of PRACH resources (e.g., by making the PRACH opportunities dedicated to SI / SIB requests more densely packed). - Modify RA-related configurations related to SI / SIB requests For example, in various embodiments, the network may change one or more of the following: A parameter that controls the initial transmit power, Power ramping step, - Maximum number of preamble transmissions allowed. - Change the mapping between random access preambles and SI / SIB messages for Msg1-based SI / SIB requests For example, in certain embodiments, a network node may choose to associate the same random access preamble with multiple SI / SIB messages that previously had separate associated random access preambles, allowing these SI / SIB messages to be requested with a single Msg1-based SI / SIB request (i.e., a single random access preamble). This may be useful, for example, if the network finds that when a wireless device requests one of these SI / SIB messages, it is common for it to also request the other associated SI / SIB messages. - Change from Msg1-based to Msg3-based SI / SIB requests - Change the SI / SIB messages available on the Msg1 and Msg3 bases : In future scenarios where Msg1-based and Msg3-based SI requests may be supported in parallel, modify the SI / SIBs available for Msg1-based and Msg3-based SI / SIB requests (if not all requests are possible both ways). - Change the number of times or the time period that the requested SI message is broadcastFor example, in a particular embodiment, if feedback information reported from a wireless device indicates that the wireless device frequently fails to receive requested SI message(s) or desired SIB(s) despite receiving an acknowledgment for the SI / SIB request, the network may attempt to address this by increasing the number of times it broadcasts a certain on-demand SI / SIB message after receiving a request for it. - Change the scheduling period of on-demand SI / SIB - Change how often on-demand SI messages are sent : In certain embodiments, the network may vary the number of times an on-demand SI / SIB message is transmitted (or beam swept) within the associated SI window (i.e., the number of times it is transmitted during the same occurrence or instance of the associated recurring SI window). - Beams on which requested SI / SIB messages are sent For example, in certain embodiments, the network may change the beam on which the requested SI / SIB message is transmitted as follows: ·Only those corresponding to the Synchronization Signal Block (SSB) beam of the SSB associated with the PRACH occasion (or preamble if multiple SSBs are associated with the same PRACH occasion) used for the request; All SSB beams (i.e. full beam sweep), or -Statistically, the set of SSB beams that wireless devices are located in the coverage area. - Change the mapping between SIB and SI messages and / or - Change the SI window length .

[0045] In certain embodiments, the network node classifies failures that occur in the on-demand SI / SIB request procedure and determines whether the failure occurs at the MAC layer (e.g., no acknowledgement is received for the SI / SIB request at the MAC layer) or whether the failure occurs after receiving an acknowledgement from the MAC layer (e.g., no SI / SIB message is received by the RRC layer in the SI window).

[0046] In another particular embodiment, the network node analyzes the beam index selected and used by the wireless device to transmit the preamble of the on-demand SI / SIB request. The network node can use this information to optimize the broadcast of the requested SI / SIB message only on the beam selected by the wireless device. Thus, the network node does not broadcast the requested SI / SIB message on a beam that was not selected by the wireless device for transmission of the preamble.

[0047] In another embodiment, if the wireless device does not provide a selected beam index but provides a preamble index through logging, the network node first determines which SSB is used to transmit the selected preamble, and then optimizes the broadcast of the SI message. In other words, the network node first determines the selected beam from the selected preamble index, and then broadcasts the SIB or SI message only on beams that were frequently used by the wireless device (or does not broadcast the SIB or SI message on beams that were not used by the wireless device to request the SIB or SI message).

[0048] In yet another embodiment, the network node uses information provided by the wireless device. In particular, the network node can use the behavior of the wireless device when checking the SI window before transmitting the preamble. Figure 1 illustrates two scenarios 100 illustrating different network behaviors determined based on the behavior of the wireless device, according to certain embodiments.

[0049] In the first scenario (Scenario 1) shown in FIG. 1, the network node (i.e., the RAN node) broadcasts the SIB or SI message on all beams because multiple wireless devices indicated that they listen to the nearest SI window before requesting on-demand SI. For example, if multiple wireless devices inspect the SI window before transmitting a preamble and attempt to obtain an SIB with the broadcast status flag set to notbroadcasting, the network node can learn to broadcast the SIB or SI message on all beams (Scenario 1 in FIG. 1). This increases the chance that the wireless devices will obtain an SIB with the broadcast status flag set to notbroadcasting before the actual request. However, if the wireless devices do not inspect the SI window before transmitting a preamble for an SIB / SI request, other UEs covered by other beams may not listen to the broadcasted SIB or SI message until they actually request it. Therefore, the network node can learn to broadcast the requested SIB or SI message only on the beam on which the preamble was actually received. Therefore, in the second scenario (Scenario 2), we have shown that the UE does not listen to the closest SI window before requesting on-demand SI, so the RAN node broadcasts SIB or SI messages only towards the beam covering UE1.

[0050] Example Certain embodiments described herein include logging and reporting information related to measurement results and on-demand SI requests, and may be implemented as part of the UE Information Request / Response procedures (described in terms of ASN.1 codes and associated field descriptions and conditional presence code descriptions) of RRC specification 3GPP TS38.331. Three non-limiting implementations / realizations are provided below, although it should be recognized that these examples are non-limiting and are provided as example embodiments only.

[0051] Example 1 In this example implementation or realization, the ASN.1 code relies on introducing a new information element (IE) for the purpose of reporting feedback information from the UE to the gNB regarding the SI / SIB request procedure in which the UE was involved (here, the new IE is denoted as SI-RequestReport-r17). The most relevant parts of the ASN.1 code are shown in bold. This code does not include all the examples of information items previously described, and this code also discloses examples of SI request related feedback information that the UE may report to the network that may not be disclosed in the text above.

[0052] UE-MeasurementsAvailable information element -- ASN1START -- TAG-UE-MeasurementsAvailable-START UE-MeasurementsAvailable-r16 ::= SEQUENCE { logMeasAvailable-r16 ENUMERATED {true} OPTIONAL, logMeasAvailableBT-r16 ENUMERATED {true} OPTIONAL, logMeasAvailableWLAN-r16 ENUMERATED {true} OPTIONAL, connEstFailInfoAvailable-r16 ENUMERATED {true} OPTIONAL, rlf-InfoAvailable-r16 ENUMERATED {true} OPTIONAL, ... [[ si-RequestInfoAvailable-r17 ENUMERATED {true} OPTIONAL, ]] } -- TAG-UE-MeasurementsAvailable-STOP -- ASN1STOP

[0053] UEInformationRequest The UEInformationRequest message is used by the network to obtain information from the UE. Signaling Radio Bearer: SRB1 RLC-SAP:AM Logical channel: DCCH Direction: Network to UE

[0054] UEInformationRequest Message -- ASN1START -- TAG-UEINFORMATIONREQUEST-START UEInformationRequest-r16 ::= SEQUENCE { rrc-TransactionIdentifier RRC-TransactionIdentifier, criticalExtensions CHOICE { ueInformationRequest-r16 UEInformationRequest-r16-IEs, criticalExtensionsFuture SEQUENCE {} } } UEInformationRequest-r16-IEs ::= SEQUENCE { idleModeMeasurementReq-r16 ENUMERATED {true} OPTIONAL, -- Need N logMeasReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N connEstFailReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N ra-ReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N rlf-ReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N mobilityHistoryReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension UEInformationRequest-v1700-IEs OPTIONAL } UEInformationRequest-v1700-IEs ::= SEQUENCE { si-RequestReportReq-r17 ENUMERATED {true} OPTIONAL, -- Need N nonCriticalExtension SEQUENCE {} OPTIONAL } -- TAG-UEINFORMATIONREQUEST-STOP -- ASN1STOP

[0055] UEInformationRequest-IE Field Descriptions connEstFailReportReq This field is used to indicate whether the UE reports information about connection failures. idleModeMeasurementReq This field indicates that the UE shall report idle / inactive measurement information, if any, to the network in the UEInformationResponse message. logMeasReportReq This field is used to indicate whether the UE reports information about logged measurements. mobilityHistoryReportReq This field is used to indicate whether the UE reports information about mobility history information. ra-ReportReq This field is used to indicate whether the UE reports information about the random access procedure. rlf-ReportReq This field is used to indicate whether the UE reports information about radio link failure. siRequestReportReq This field is used to indicate whether the UE reports information about the SI request procedure.

[0056] UEInformationResponse The UEInformationResponse message is used by the UE to transfer the requested information from the network. Signaling Radio Bearer: SRB1 or SRB2 (if logged measurement information is included) RLC-SAP:AM Logical channel: DCCH Direction: UE to network

[0057] UEInformationResponse Message -- ASN1START -- TAG-UEINFORMATIONRESPONSE-START UEInformationResponse-r16 ::= SEQUENCE { rrc-TransactionIdentifier RRC-TransactionIdentifier, criticalExtensions CHOICE { ueInformationResponse-r16 UEInformationResponse-r16-IEs, criticalExtensionsFuture SEQUENCE {} } } UEInformationResponse-r16-IEs ::= SEQUENCE { measResultIdleEUTRA-r16 MeasResultIdleEUTRA-r16 OPTIONAL, measResultIdleNR-r16 MeasResultIdleNR-r16 OPTIONAL, logMeasReport-r16 LogMeasReport-r16 OPTIONAL, connEstFailReport-r16 ConnEstFailReport-r16 OPTIONAL, ra-ReportList-r16 RA-ReportList-r16 OPTIONAL, rlf-Report-r16 RLF-Report-r16 OPTIONAL, mobilityHistoryReport-r16 MobilityHistoryReport-r16 OPTIONAL, lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension UEInformationResponse-v1700-IEs OPTIONAL } LogMeasReport-r16 ::= SEQUENCE { absoluteTimeStamp-r16 AbsoluteTimeInfo-r16, traceReference-r16 TraceReference-r16, traceRecordingSessionRef-r16 OCTET STRING (SIZE (2)), tce-Id-r16 OCTET STRING (SIZE (1)), logMeasInfoList-r16 LogMeasInfoList-r16, logMeasAvailable-r16 ENUMERATED {true} OPTIONAL, logMeasAvailableBT-r16 ENUMERATED {true} OPTIONAL, logMeasAvailableWLAN-r16 ENUMERATED {true} OPTIONAL, ... } LogMeasInfoList-r16 ::= SEQUENCE (SIZE (1..maxLogMeasReport-r16)) OF LogMeasInfo-r16 LogMeasInfo-r16 ::= SEQUENCE { locationInfo-r16 LocationInfo-r16 OPTIONAL, relativeTimeStamp-r16 INTEGER (0..7200), servCellIdentity-r16 CGI-Info-Logging-r16 OPTIONAL, measResultServingCell-r16 MeasResultServingCell-r16 OPTIONAL, measResultNeighCells-r16 SEQUENCE { measResultNeighCellListNR MeasResultListLogging2NR-r16 OPTIONAL, measResultNeighCellListEUTRA MeasResultList2EUTRA-r16 OPTIONAL }, anyCellSelectionDetected-r16 ENUMERATED {true} OPTIONAL, ... } ConnEstFailReport-r16 ::= SEQUENCE { measResultFailedCell-r16 MeasResultFailedCell-r16, locationInfo-r16 LocationInfo-r16 OPTIONAL, measResultNeighCells-r16 SEQUENCE { measResultNeighCellListNR MeasResultList2NR-r16 OPTIONAL, measResultNeighCellListEUTRA MeasResultList2EUTRA-r16 OPTIONAL }, numberOfConnFail-r16 INTEGER (1..8), perRAInfoList-r16 PerRAInfoList-r16, timeSinceFailure-r16 TimeSinceFailure-r16, ... } MeasResultServingCell-r16 ::= SEQUENCE { resultsSSB-Cell MeasQuantityResults, resultsSSB SEQUENCE{ best-ssb-Index SSB-Index, best-ssb-Results MeasQuantityResults, numberOfGoodSSB INTEGER (1..maxNrofSSBs-r16) } OPTIONAL } MeasResultFailedCell-r16 ::= SEQUENCE { cgi-Info CGI-Info-Logging-r16, measResult-r16 SEQUENCE { cellResults-r16 SEQUENCE{ resultsSSB-Cell-r16 MeasQuantityResults }, rsIndexResults-r16 SEQUENCE{ resultsSSB-Indexes-r16 ResultsPerSSB-IndexList } } } RA-ReportList-r16 ::= SEQUENCE (SIZE (1..maxRAReport-r16)) OF RA-Report-r16 RA-Report-r16 ::= SEQUENCE { cellId-r16 CHOICE { cellGlobalId-r16 CGI-Info-Logging-r16, pci-arfcn-r16 SEQUENCE { physCellId-r16 PhysCellId, carrierFreq-r16 ARFCN-ValueNR } }, ra-InformationCommon-r16 RA-InformationCommon-r16 OPTIONAL, raPurpose-r16 ENUMERATED {accessRelated, beamFailureRecovery, reconfigurationWithSync, ulUnSynchronized, schedulingRequestFailure, noPUCCHResourceAvailable, requestForOtherSI, spare9, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1}, ... } RA-InformationCommon-r16 ::= SEQUENCE { absoluteFrequencyPointA-r16 ARFCN-ValueNR, locationAndBandwidth-r16 INTEGER (0..37949), subcarrierSpacing-r16 SubcarrierSpacing, msg1-FrequencyStart-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL, msg1-FrequencyStartCFRA-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL, msg1-SubcarrierSpacing-r16 SubcarrierSpacing OPTIONAL, msg1-SubcarrierSpacingCFRA-r16 SubcarrierSpacing OPTIONAL, msg1-FDM-r16 ENUMERATED {one, two, four, eight} OPTIONAL, msg1-FDMCFRA-r16 ENUMERATED {one, two, four, eight} OPTIONAL, perRAInfoList-r16 PerRAInfoList-r16, ... } PerRAInfoList-r16 ::= SEQUENCE (SIZE (1..200)) OF PerRAInfo-r16 PerRAInfo-r16 ::= CHOICE { perRASSBInfoList-r16 PerRASSBInfo-r16, perRACSI-RSInfoList-r16 PerRACSI-RSInfo-r16 } PerRASSBInfo-r16 ::= SEQUENCE { ssb-Index-r16 SSB-Index, numberOfPreamblesSentOnSSB-r16 INTEGER (1..200), perRAAttemptInfoList-r16 PerRAAttemptInfoList-r16 } PerRACSI-RSInfo-r16 ::= SEQUENCE { csi-RS-Index-r16 CSI-RS-Index, numberOfPreamblesSentOnCSI-RS-r16 INTEGER (1..200) } PerRAAttemptInfoList-r16 ::= SEQUENCE (SIZE (1..200)) OF PerRAAttemptInfo-r16 PerRAAttemptInfo-r16 ::= SEQUENCE { contentionDetected-r16 BOOLEAN OPTIONAL, dlRSRPAboveThreshold-r16 BOOLEAN OPTIONAL, ... } RLF-Report-r16 ::= CHOICE { nr-RLF-Report-r16 SEQUENCE { measResultLastServCell-r16 MeasResultRLFNR-r16, measResultNeighCells-r16 SEQUENCE { measResultListNR-r16 MeasResultList2NR-r16 OPTIONAL, measResultListEUTRA-r16 MeasResultList2EUTRA-r16 OPTIONAL } OPTIONAL, c-RNTI-r16 RNTI-Value, previousPCellId-r16 CHOICE { nrPreviousCell-r16 CGI-Info-Logging-r16, eutraPreviousCell-r16 CGI-InfoEUTRALogging } OPTIONAL, failedPCellId-r16 CHOICE { nrFailedPCellId-r16 CHOICE { cellGlobalId-r16 CGI-Info-Logging-r16, pci-arfcn-r16 SEQUENCE { physCellId-r16 PhysCellId, carrierFreq-r16 ARFCN-ValueNR } }, eutraFailedPCellId-r16 CHOICE { cellGlobalId-r16 CGI-InfoEUTRALogging, pci-arfcn-r16 SEQUENCE { physCellId-r16 EUTRA-PhysCellId, carrierFreq-r16 ARFCN-ValueEUTRA } } }, reconnectCellId-r16 CHOICE { nrReconnectCellId-r16 CGI-Info-Logging-r16, eutraReconnectCellId-r16 CGI-InfoEUTRALogging } OPTIONAL, timeUntilReconnection-16 TimeUntilReconnection-16 OPTIONAL, reestablishmentCellId-r16 CGI-Info-Logging-r16 OPTIONAL, timeConnFailure-r16 INTEGER (0..1023) OPTIONAL, timeSinceFailure-r16 TimeSinceFailure-r16, connectionFailureType-r16 ENUMERATED {rlf, hof}, rlf-Cause-r16 ENUMERATED {t310-Expiry, randomAccessProblem, rlc-MaxNumRetx, beamFailureRecoveryFailure, lbtFailure-r16, bh-rlfRecoveryFailure, spare2, spare1}, locationInfo-r16 LocationInfo-r16 OPTIONAL, noSuitableCellFound-r16 ENUMERATED {true} OPTIONAL, ra-InformationCommon-r16 RA-InformationCommon-r16 OPTIONAL, ... }, eutra-RLF-Report-r16 SEQUENCE { failedPCellId-EUTRA CGI-InfoEUTRALogging, measResult-RLF-Report-EUTRA-r16 OCTET STRING, ... } } MeasResultList2NR-r16 ::= SEQUENCE(SIZE (1..maxFreq)) OF MeasResult2NR-r16 MeasResultList2EUTRA-r16 ::= SEQUENCE(SIZE (1..maxFreq)) OF MeasResult2EUTRA-r16 MeasResult2NR-r16 ::= SEQUENCE { ssbFrequency-r16 ARFCN-ValueNR OPTIONAL, refFreqCSI-RS-r16 ARFCN-ValueNR OPTIONAL, measResultList-r16 MeasResultListNR } MeasResultListLogging2NR-r16 ::= SEQUENCE(SIZE (1..maxFreq)) OF MeasResultLogging2NR-r16 MeasResultLogging2NR-r16 ::= SEQUENCE { carrierFreq-r16 ARFCN-ValueNR, measResultListLoggingNR-r16 MeasResultListLoggingNR-r16 } MeasResultListLoggingNR-r16 ::= SEQUENCE (SIZE (1..maxCellReport)) OF MeasResultLoggingNR-r16 MeasResultLoggingNR-r16 ::= SEQUENCE { physCellId-r16 PhysCellId, resultsSSB-Cell-r16 MeasQuantityResults, numberOfGoodSSB-r16 INTEGER (1..maxNrofSSBs-r16) OPTIONAL } MeasResult2EUTRA-r16 ::= SEQUENCE { carrierFreq-r16 ARFCN-ValueEUTRA, measResultList-r16 MeasResultListEUTRA } MeasResultRLFNR-r16 ::= SEQUENCE { measResult-r16 SEQUENCE { cellResults-r16 SEQUENCE{ resultsSSB-Cell-r16 MeasQuantityResults OPTIONAL, resultsCSI-RS-Cell-r16 MeasQuantityResults OPTIONAL }, rsIndexResults-r16 SEQUENCE{ resultsSSB-Indexes-r16 ResultsPerSSB-IndexList OPTIONAL, ssbRLMConfigBitmap-r16 BIT STRING (SIZE (64)) OPTIONAL, resultsCSI-RS-Indexes-r16 ResultsPerCSI-RS-IndexList OPTIONAL, csi-rsRLMConfigBitmap-r16 BIT STRING (SIZE (96)) OPTIONAL } OPTIONAL } } TimeSinceFailure-r16 ::= INTEGER (0..172800) MobilityHistoryReport-r16 ::= VisitedCellInfoList-r16 TimeUntilReconnection-16 ::= INTEGER (0..172800) UEInformationResponse-v1700-IEs ::= SEQUENCE { si-RequestReportList-r17 SI-RequestReportList-r17 ... } SI-RequestReportList-r17 ::= SEQUENCE (SIZE (1..maxSIRequestReport-r17)) OF SI-RequestReport-r17 SI-RequestReport-r17 ::= SEQUENCE { cellId-r16 CHOICE { cellGlobalId-r16 CGI-Info-Logging-r16, pci-arfcn-r16 SEQUENCE { physCellId-r16 PhysCellId, carrierFreq-r16 ARFCN-ValueNR } }, wantedSIB-Types-r17 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r17, siRequestType-r17 ENUMERATED {msg1Based, msg3Based, rrcConnectedStateRequest), si-RequestAttemptsPerSSB-InfoList-r17 SEQUENCE (SIZE (1..200)) OF SI-RequestAttemptsPerSSB-Info-r17 OPTIONAL, -- Cond msg1msg3Request si-RRC-ConnStateConfigInfo-r17 SI-RRC-ConnStateConfigInfo-r17 OPTIONAL, -- Cond rrcConnStateRequest perRRC-ConnStateSI-RequestAttemptInfoList-r17 SEQUENCE (SIZE (1..maxNoOfSI-RequestAttemptsRRC-ConnState) OF PerRRC-ConnStateSI-RequestAttemptInfo-r17 OPTIONAL, -- Cond rrcConnStateRequest initiationTime InitiationTimestamp, locationInfo LocationInfo-r16 OPTIONAL, outcome-r17 Outcome-r17, receivedSIB-Types-r17 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r17, OPTIONAL, -- Cond ackedAndSubsetOfWantedSIBsReceived si-MessageReceptionInfo-r17 SI-MessageReceptionInfo-r17 OPTIONAL, -- Cond si-MessageReceptionAttempted ... } SIB-Type-r17 ::= ENUMERATED {sibType2, sibType3, sibType4, sibType5, sibType6, sibType7, sibType8, sibType9, sibType10-v1610, sibType11-v1610, sibType12-v1610, sibType13-v1610, sibType14-v1610, spare3, spare2, spare1, ...} InitiationTimestamp ::= CHOICE { preciseUTC INTEGER (0..8796093022207), coarseUTC-HSFN-SFN-SlotSymbol CoarseUTC-HSFN-SFN-SlotSymbol, coarseUTC-HSFN-SFN-Slot CoarseUTC-HSFN-SFN-Slot, coarseUTC-HSFN-SFN CoarseUTC-HSFN-SFN, semiCoarseUTC-SFN-SlotSymbol SemiCoarseUTC-SFN-SlotSymbol, semiCoarseUTC-SFN-Slot SemiCoarseUTC-SFN-Slot, semiCoarseUTC-SFN SemiCoarseUTC-SFN, hsfn-SFN-SlotSymbol HSFN-SFN-SlotSymbol, hsfn-SFN-Slot HSFN-SFN-Slot, hsfn-SFN HSFN-SFN, gnssTime GNSS-Time } CoarseUTC-HSFN-SFN-SlotSymbol ::= SEQUENCE { coarseUTC INTEGER (0..268435455), hsfn INTEGER (0..1023), sfn INTEGER (0..1023), slot INTEGER (0..159), symbol INTEGER (0..13) } CoarseUTC-HSFN-SFN-Slot ::= SEQUENCE { coarseUTC INTEGER (0..268435455), hsfn INTEGER (0..1023), sfn INTEGER (0..1023), slot INTEGER (0..159) } CoarseUTC-HSFN-SFN ::= SEQUENCE { coarseUTC INTEGER (0..268435455), hsfn INTEGER (0..1023), sfn INTEGER (0..1023), slot INTEGER (0..159) } SemiCoarseUTC-SFN-SlotSymbol ::= SEQUENCE { semiCoarseUTC INTEGER (0..4294967295), sfn INTEGER (0..1023), slot INTEGER (0..159), symbol INTEGER (0..13) } SemiCoarseUTC-SFN-Slot ::= SEQUENCE { semiCoarseUTC INTEGER (0..4294967295), sfn INTEGER (0..1023), slot INTEGER (0..159) } SemiCoarseUTC-SFN ::= SEQUENCE { semiCoarseUTC INTEGER (0..4294967295), sfn INTEGER (0..1023) } HSFN-SFN-SlotSymbol ::= SEQUENCE { hsfn INTEGER (0..1023), sfn INTEGER (0..1023), slot INTEGER (0..159), symbol INTEGER (0..13) } HSFN-SFN-Slot ::= SEQUENCE { hsfn INTEGER (0..1023), sfn INTEGER (0..1023), slot INTEGER (0..159) } HSFN-SFN ::= SEQUENCE { hsfn INTEGER (0..1023), sfn INTEGER (0..1023) } GNSS-Time ::= SEQUENCE { timeSource CHOICE { gpsTime INTEGER (0..4398046511104), galileoTime INTEGER (0..4398046511104), glonassTime INTEGER (0..8796093022207), beidouTime INTEGER (0..4398046511104), ... }, leapSeconds INTEGER (-255..256) OPTIONAL, } Outcome-r17 ::= CHOICE { concluded-r17 ENUMERATED {ackedAndAllWantedSIBsReceived, ackedAndSubsetOfWantedSIBsReceived, ackedAndNoWantedSIBsReceived, maxAllowedAttemptsReachedWithoutAck}, abandoned-r17 ENUMERATED {wantedSIBsReceived, subsetOfWantedSIBsReceived, lossOfCoverage, rlf, cellReselection, spare3, spare2, spare1, ...}, ... } SI-MessageReceptionInfo-r17 ::= SEQUENCE (SIZE(1..maxSI-Message) OF PerSI-MessageReceptionInfo-r17) PerSI-MessageReceptionInfo-r17 ::= SEQUENCE { si-MessageNumber-r17 INTEGER (1..maxSI-Message), numberOfReceptionAttempts-r17 INTEGER, si-MessageReceptionResult-r17 ENUMERATED {success, failure}, ... } SI-RequestAttemptsPerSSBInfo-r17 ::= SEQUENCE { ssb-Index-r16 SSB-Index, numberOfSI-RequestsSentOnSSB INTEGER (1..200), perSI-RequestAttemptInfoList-r17 SEQUENCE (SIZE (1..200)) OF PerSI-RequestAttemptInfo-r17, ... } PerSI-RequestAttemptInfo-r17 ::= SEQUENCE { contentionDetected-r16 BOOLEAN OPTIONAL, -- Cond msg3Request dlRSRPAboveThreshold-r16 BOOLEAN OPTIONAL, relativeTimestamp RelativeTimestamp OPTIONAL, ... } SI-RRC-ConnStateConfigInfo-r17 ::= SEQUENCE { absoluteFrequencyPointA-r16 ARFCN-ValueNR, locationAndBandwidth-r16 INTEGER (0..37949), subcarrierSpacing-r16 SubcarrierSpacing, ... } PerRRC-ConnStateSI-RequestAttemptInfo-r17 ::= SEQUENCE { numberOfHARQ-Retransmissions-r17 INTEGER, relativeTimestamp RelativeTimestamp OPTIONAL, -- In case of HARQ retransmissions, the relative timestamp indicates the time of the first transmission. ... } RelativeTimestamp ::= CHOICE { milliseconds INTEGER (0..1048575), slots INTEGER (0..4194303), symbols INTEGER (0..67108863), ... } -- TAG-UEINFORMATIONRESPONSE-STOP -- ASN1STOP

[0058] UEInformationResponse-IE field descriptions logMeasReport This field is used to provide measurements stored by the UE associated with the logged MDT. measResultIdleEUTRA EUTRA measurement results performed during RRC_INACTIVE or RRC_IDLE. measResultIdleNR NR measurement results performed during RRC_INACTIVE or RRC_IDLE. ra-ReportList This field is used to provide a list of RA reports that the UE stores up to the number maxRAReport-r16 of previous successful random access procedures. rlf-Report This field is used to indicate the RLF report related content. SI-RequestReportList This field contains a list of SI request reports that the UE stores for up to maxSIRequestReport number of previous SI request procedures.

[0059] SI-RequestReport Field Descriptions cellID This field indicates the cell ID of the cell for which the associated SI request procedure was performed, in the form of a combination of CGI or PCI and carrier frequency. coarseUTC This field indicates the number of 32768 milliseconds since midnight between December 31, 1899 and January 1, 1900 according to UTC. contentionDetected This field is used to indicate whether a transmitted preamble collision was detected when attempting an Msg3 based SI request. This field is not included if the UE uses an Msg1 based SI request. dlRSRPAboveThreshold This field is used to indicate whether the RSRP of the DL beam (SSB) associated with the SI request attempt was greater than or equal to the threshold rsrp-ThresholdSSB in rach-ConfigCommon in the UL_BWP configuration of the UL_BWP selected for the SI request procedure. gnssTime This field indicates the number of milliseconds since the start of timekeeping for the respective GNSS time source. initiationTime This field indicates the time when the SI request procedure was started. For SI requests based on Msg1 and Msg3, this time is the start time of the first symbol of the PRACH occasion used for random access preamble transmission. For SI requests using the DedicatedSIBReqeust message in RRC_CONNECTED state, the indicated time is the start time of the first symbol of the PUSCH transmission carrying the DedicatedSIBReqeust message (or the first transmission in case of HARQ retransmissions). If the time representation used in the parameter has a coarser granularity, the indicated (rounded) time should be the value closest to the actual start time. locationInfo This field contains the UE's location information and possibly its velocity information. Ideally, it should indicate the UE's location (and velocity, if applicable) at the start of the SI request procedure, although the reported location information may have been collected at a different time, as indicated by the locationTimestamp parameter of the commonLocationInfoIE. numberOfHARQ-Retransmissions This field indicates the number of HARQ retransmissions used during an SI request attempt using the DedicatedSIBRequest message sent in the RRC_CONNECTED state. numberOfSI-RequestsSentOnSSB This field is used to indicate the total number of consecutive Msg1 or Msg3 based SI requests transmitted using the PRACH resource associated with the corresponding SS / PBCH block. outcome This field indicates the result of the SI request procedure. The presence of the field "concluded" indicates that the SI request procedure has either been acknowledged (by a matching RAPID field in Msg2 for an Msg1-based SI request, or by a matching UE_Contention_Resolution_ID_MAC_CE in Msg4 for an Msg3-based SI request, or by an RLC acknowledgement for an SI request using a DedicatedSIBRequest message) or continued until the maximum number of SI request attempts was reached without receiving an acknowledgement. If the SI request is acknowledged, the UE can receive all requested SIBs (i.e., the SIBs of the SI request). This is indicated by the ENUMERATED values ​​"ackedAndAllWantedSIBsReceived", "ackedAndSubsetOfWantedSIBsReceived", and "ackedAndNoWantedSIBsReceived". If the UE has made the maximum allowed number of SI request attempts without receiving an acknowledgement, the conceded field is set to the value "maxAllowedAttemptsReachedWithoutAck". The presence of the abandoned field indicates that the SI request procedure was abandoned before the maximum number of allowed attempts was performed, even if the SI request procedure did not receive an acknowledgment. The reason for abandoning the SI request procedure is indicated by the value provided by this field. perRRC-ConnStateSI-RequestAttemptInfoList This field provides detailed information about the number of consecutive SI request attempts performed through the transmission of DedicatedSIBRequest messages in the RRC_CONNECTED state. One SI request attempt may consist of a set of associated HARQ retransmissions. perSI-RequestAttemptInfoList This field provides detailed information about the number of consecutive Msg1- or Msg3-based SI request attempts in which the random access preamble was transmitted using the PRACH resource associated with the same SS / PBCH block. preciseUTC This field indicates the number of milliseconds since midnight between December 31, 1899 and January 1, 1900, based on UTC. receivedSIB-Types This field indicates the wanted SIBs (if any) received by the UE if the UE's SI request is confirmed (by a matching RAPID field in Msg2 for an Msg1-based SI request, or by a matching UE_Contention_Resolution_ID_MAC_CE in Msg4 for an Msg3-based SI request, or by a matching RLC acknowledgment for an SI request using a DedicatedSIBRequest message) and the UE has received at least one, but not all, of the wanted SIBs (i.e., SIBs of the types indicated in the wantedSIB-Types field). This field is present if the outcome field is present. This field is present if the outcome field contains a concluding field set to the value "ackedAndSubsetOfWantedSIBsReceived", and is absent otherwise. relativeTimestamp This field indicates the elapsed time from the time indicated by the initiationTime field to the start of the SI request attempt to which the relativeTimestamp field relates. For SI request attempts based on Msg1 and Msg3, the start of the SI request attempt is the start of the first symbol of the PRACH opportunity used for random access preamble transmission. For SI request attempts using a DedicatedSIBRequest message, the start of the SI request attempt is the start of the first symbol of the PUSCH resource used for transmitting the DedicatedSIBRequest message. If the SI request attempt includes HARQ retransmissions, the relative timestamp indicates the start time of the first transmission. semiCoarseUTC This field indicates the time since midnight between December 31, 1899 and January 1, 1900, based on UTC, in units of 2048 milliseconds. si-MessageReceptionInfo This field provides information related to the receipt or attempted receipt of the requested SI message. This field is not present if the UE did not attempt to receive the requested SI message. This means that this field is present if the result field contains the concluding field set to one of the following values: "ackedAndAllWantedSIBsReceived", "ackedAndSubsetOfWantedSIBsReceived", or "ackedAndNoWantedSIBsReceived". si-RequestAttemptsPerSSB-InfoLIst This field provides detailed information about a set of consecutive Msg1-based or Msg3-based SI request attempts, each using PRACH resources associated with a specific (same) SS / PBCH block. Each such set of consecutive SI request attempts is included in the Si-ReqestAttemptsPerSSB-Info field. si-RequestType This field indicates either an Msg1-based SI request, an Msg3-based SI request, or the type of SI request using a DedicatedSIBRequest message in the RRC_CONNECTED state. si-RRC-ConnStateConfigInfo This field provides general configuration information related to the SI request mechanism in the RRC_CONNECTED state. ssb-Index This field is used to indicate the SS / PBCH index of the SS / PBCH block that corresponds to the SI request attempt. wantedSIB-Types This field indicates which (all or a subset) of the SIBs in the requested SI message (during the SI request procedure to which this SI-RequestReport instance pertains) the UE is interested. For example, if SIBX, SIBY, and SIBZ are included in the same SI message that is available on demand, and the wantedSIB-Types parameter of the SI-RequestReport indicates SIB types X and Y, this means that in the SI request procedure to which the SI-RequestReport pertains, the UE requested an SI message containing SIBX, SIBY, and SIBZ, but the UE was only interested in SIBX and SIBY, and not SIBZ. (Note: If the UE changes the requested SIBs or the requested SI message or SIBs between successive attempts, this should be considered a new SI request procedure and should be logged and reported as a new SI-RequestReport.)

[0060] SI-RRC-ConnStateConfigInfo Field Description absoluteFrequencyPointA This field indicates the absolute frequency location of the reference resource block (common RB0). locationAndBandwidth The frequency domain location and bandwidth of the bandwidth portion used for the transmission of the DedicatedSIBRequest message of the SI request procedure to which this SI-RequestReport pertains. subcarrierSpacing This field indicates the subcarrier spacing used for transmitting the DedicatedSIBRequest message of the SI request procedure to which this SI-RequestReport pertains.

[0061] Conditional Presence and Description ackedAndSubsetOfWantedSIBsReceived This field is present if the UE's SI request is acknowledged (matching RAPID field in Msg2 for Msg1-based SI requests, matching UE_Contention_Resolution_ID_MAC_CE in Msg4 for Msg3-based SI requests, or matching RLC acknowledgement for SI requests using a DedicatedSIBRequest message) and the UE has received at least one (but not all) of the desired SIBs (i.e., SIBs of the types indicated in the wantedSIB-Types field). Therefore, this field is mandatory if the outcome field contains the concluding field set to the value "ackedAndSubsetOfWantedSIBsReceived", otherwise this field is absent. msg1msg3Request This field is required if the SI request is performed with the Msg1-based SI request method or the Msg3-based SI request method, otherwise this field is not present if the SI request is performed by sending a DedicatedSIBRequest message. msg3Request This field is required if the SI request is performed using the Msg3-based SI request method. rrcConnStateRequest This field is required if the SI request is performed by sending a DedicatedSIBRequest message. si-MessageReceptionAttempted This field is mandatory to be present if the UE has attempted (either successfully or unsuccessfully) to receive at least one requested SI message.

[0062] LocationInfo The IE "LocationInfo" is used to transfer detailed location information, Bluetooth, WLAN and sensor measurements available in the UE.

[0063] LocationInfo information element -- ASN1START -- TAG-LOCATIONINFO-START LocationInfo-r16 ::= SEQUENCE { commonLocationInfo-r16 CommonLocationInfo-r16 OPTIONAL, bt-LocationInfo-r16 LogMeasResultListBT-r16 OPTIONAL, wlan-LocationInfo-r16 LogMeasResultListWLAN-r16 OPTIONAL, sensor-LocationInfo-r16 Sensor-LocationInfo-r16 OPTIONAL, ... } -- TAG-LOCATIONINFO-STOP -- ASN1STOP

[0064] CommonLocationInfo The IE "CommonLocationInfo" is used to transfer detailed location information available at the UE in order to associate measurements with the UE's location information.

[0065] CommonLocationInfo information element -- ASN1START -- TAG-COMMONLOCATIONINFO-START CommonLocationInfo-r16 ::= SEQUENCE { gnss-TOD-msec-r16 OCTET STRING OPTIONAL, locationTimestamp-r16 OCTET STRING OPTIONAL, locationCoordinate-r16 OCTET STRING OPTIONAL, locationError-r16 OCTET STRING OPTIONAL, locationSource-r16 OCTET STRING OPTIONAL, velocityEstimate-r16 OCTET STRING OPTIONAL } -- TAG-COMMONLOCATIONINFO-STOP -- ASN1STOP

[0066] CommonLocationInfo field descriptions gnss-TOD-msec Parameter type gnss-TOD-msec as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit. locationTimeStamp Parameter type DisplacementTimeStamp as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit. locationCoordinate Parameter type LocationCoordinates as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit. locationError Parameter LocationError as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit. locationSource Parameter LocationSource as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit. velocityEstimate Parameter type Velocity as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit.

[0067] Example 2 Similar to Example 1, in this second implementation or realization, the ASN.1 code relies on the introduction of a new IE (here denoted as SI-RequestReport-r17) for the purpose of reporting feedback information from the UE to the gNB regarding the SI request procedure in which the UE was involved. However, within the SI-RequestReport-r17 IE, there is more reuse of parameters related to the RA-Report-r16 IE than in Example 1. The most relevant parts of the ASN.1 code are highlighted in yellow. This code does not include all the example information items discussed above, and the code also discloses examples of SI request-related feedback information that the UE reports to the network that may not be disclosed in the text above.

[0068] UE-MeasurementsAvailable information element -- ASN1START -- TAG-UE-MeasurementsAvailable-START UE-MeasurementsAvailable-r16 ::= SEQUENCE { logMeasAvailable-r16 ENUMERATED {true} OPTIONAL, logMeasAvailableBT-r16 ENUMERATED {true} OPTIONAL, logMeasAvailableWLAN-r16 ENUMERATED {true} OPTIONAL, connEstFailInfoAvailable-r16 ENUMERATED {true} OPTIONAL, rlf-InfoAvailable-r16 ENUMERATED {true} OPTIONAL, ... [[ si-RequestInfoAvailable-r17 ENUMERATED {true} OPTIONAL, ]] } -- TAG-UE-MeasurementsAvailable-STOP -- ASN1STOP

[0069] UEInformationRequest The UEInformationRequest message is used by the network to obtain information from the UE. Signaling Radio Bearer: SRB1 RLC-SAP:AM Logical channel: DCCH Direction: Network to UE

[0070] UEInformationRequest Message -- ASN1START -- TAG-UEINFORMATIONREQUEST-START UEInformationRequest-r16 ::= SEQUENCE { rrc-TransactionIdentifier RRC-TransactionIdentifier, criticalExtensions CHOICE { ueInformationRequest-r16 UEInformationRequest-r16-IEs, criticalExtensionsFuture SEQUENCE {} } } UEInformationRequest-r16-IEs ::= SEQUENCE { idleModeMeasurementReq-r16 ENUMERATED {true} OPTIONAL, -- Need N logMeasReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N connEstFailReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N ra-ReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N rlf-ReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N mobilityHistoryReportReq-r16 ENUMERATED {true} OPTIONAL, -- Need N lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension UEInformationRequest-v1700-IEs OPTIONAL } UEInformationRequest-v1700-IEs ::= SEQUENCE { si-RequestReportReq-r17 ENUMERATED {true} OPTIONAL, -- Need N nonCriticalExtension SEQUENCE {} OPTIONAL } -- TAG-UEINFORMATIONREQUEST-STOP -- ASN1STOP

[0071] UEInformationRequest-IE Field Descriptions connEstFailReportReq This field is used to indicate whether the UE reports information about connection failures. idleModeMeasurementReq This field indicates that the UE shall report idle / inactive measurement information, if any, to the network in the UEInformationResponse message. logMeasReportReq This field is used to indicate whether the UE reports information about logged measurements. mobilityHistoryReportReq This field is used to indicate whether the UE reports information about mobility history information. ra-ReportReq This field is used to indicate whether the UE reports information about the random access procedure. rlf-ReportReq This field is used to indicate whether the UE reports information about radio link failure. siRequestReportReq This field is used to indicate whether the UE reports information about the SI request procedure.

[0072] UEInformationResponse The UEInformationResponse message is used by the UE to transfer the requested information from the network. Signaling Radio Bearer: SRB1 or SRB2 (if logged measurement information is included) RLC-SAP:AM Logical channel: DCCH Direction: UE to network

[0073] UEInformationResponse Message -- ASN1START -- TAG-UEINFORMATIONRESPONSE-START UEInformationResponse-r16 ::= SEQUENCE { rrc-TransactionIdentifier RRC-TransactionIdentifier, criticalExtensions CHOICE { ueInformationResponse-r16 UEInformationResponse-r16-IEs, criticalExtensionsFuture SEQUENCE {} } } UEInformationResponse-r16-IEs ::= SEQUENCE { measResultIdleEUTRA-r16 MeasResultIdleEUTRA-r16 OPTIONAL, measResultIdleNR-r16 MeasResultIdleNR-r16 OPTIONAL, logMeasReport-r16 LogMeasReport-r16 OPTIONAL, connEstFailReport-r16 ConnEstFailReport-r16 OPTIONAL, ra-ReportList-r16 RA-ReportList-r16 OPTIONAL, rlf-Report-r16 RLF-Report-r16 OPTIONAL, mobilityHistoryReport-r16 MobilityHistoryReport-r16 OPTIONAL, lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension UEInformationResponse-v1700-IEs OPTIONAL } LogMeasReport-r16 ::= SEQUENCE { absoluteTimeStamp-r16 AbsoluteTimeInfo-r16, traceReference-r16 TraceReference-r16, traceRecordingSessionRef-r16 OCTET STRING (SIZE (2)), tce-Id-r16 OCTET STRING (SIZE (1)), logMeasInfoList-r16 LogMeasInfoList-r16, logMeasAvailable-r16 ENUMERATED {true} OPTIONAL, logMeasAvailableBT-r16 ENUMERATED {true} OPTIONAL, logMeasAvailableWLAN-r16 ENUMERATED {true} OPTIONAL, ... } LogMeasInfoList-r16 ::= SEQUENCE (SIZE (1..maxLogMeasReport-r16)) OF LogMeasInfo-r16 LogMeasInfo-r16 ::= SEQUENCE { locationInfo-r16 LocationInfo-r16 OPTIONAL, relativeTimeStamp-r16 INTEGER (0..7200), servCellIdentity-r16 CGI-Info-Logging-r16 OPTIONAL, measResultServingCell-r16 MeasResultServingCell-r16 OPTIONAL, measResultNeighCells-r16 SEQUENCE { measResultNeighCellListNR MeasResultListLogging2NR-r16 OPTIONAL, measResultNeighCellListEUTRA MeasResultList2EUTRA-r16 OPTIONAL }, anyCellSelectionDetected-r16 ENUMERATED {true} OPTIONAL, ... } ConnEstFailReport-r16 ::= SEQUENCE { measResultFailedCell-r16 MeasResultFailedCell-r16, locationInfo-r16 LocationInfo-r16 OPTIONAL, measResultNeighCells-r16 SEQUENCE { measResultNeighCellListNR MeasResultList2NR-r16 OPTIONAL, measResultNeighCellListEUTRA MeasResultList2EUTRA-r16 OPTIONAL }, numberOfConnFail-r16 INTEGER (1..8), perRAInfoList-r16 PerRAInfoList-r16, timeSinceFailure-r16 TimeSinceFailure-r16, ... } MeasResultServingCell-r16 ::= SEQUENCE { resultsSSB-Cell MeasQuantityResults, resultsSSB SEQUENCE{ best-ssb-Index SSB-Index, best-ssb-Results MeasQuantityResults, numberOfGoodSSB INTEGER (1..maxNrofSSBs-r16) } OPTIONAL } MeasResultFailedCell-r16 ::= SEQUENCE { cgi-Info CGI-Info-Logging-r16, measResult-r16 SEQUENCE { cellResults-r16 SEQUENCE{ resultsSSB-Cell-r16 MeasQuantityResults }, rsIndexResults-r16 SEQUENCE{ resultsSSB-Indexes-r16 ResultsPerSSB-IndexList } } } RA-ReportList-r16 ::= SEQUENCE (SIZE (1..maxRAReport-r16)) OF RA-Report-r16 RA-Report-r16 ::= SEQUENCE { cellId-r16 CHOICE { cellGlobalId-r16 CGI-Info-Logging-r16, pci-arfcn-r16 SEQUENCE { physCellId-r16 PhysCellId, carrierFreq-r16 ARFCN-ValueNR } }, ra-InformationCommon-r16 RA-InformationCommon-r16 OPTIONAL, raPurpose-r16 ENUMERATED {accessRelated, beamFailureRecovery, reconfigurationWithSync, ulUnSynchronized, schedulingRequestFailure, noPUCCHResourceAvailable, requestForOtherSI, spare9, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1}, ... } RA-InformationCommon-r16 ::= SEQUENCE { absoluteFrequencyPointA-r16 ARFCN-ValueNR, locationAndBandwidth-r16 INTEGER (0..37949), subcarrierSpacing-r16 SubcarrierSpacing, msg1-FrequencyStart-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL, msg1-FrequencyStartCFRA-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL, msg1-SubcarrierSpacing-r16 SubcarrierSpacing OPTIONAL, msg1-SubcarrierSpacingCFRA-r16 SubcarrierSpacing OPTIONAL, msg1-FDM-r16 ENUMERATED {one, two, four, eight} OPTIONAL, msg1-FDMCFRA-r16 ENUMERATED {one, two, four, eight} OPTIONAL, perRAInfoList-r16 PerRAInfoList-r16, ... } PerRAInfoList-r16 ::= SEQUENCE (SIZE (1..200)) OF PerRAInfo-r16 PerRAInfo-r16 ::= CHOICE { perRASSBInfoList-r16 PerRASSBInfo-r16, perRACSI-RSInfoList-r16 PerRACSI-RSInfo-r16 } PerRASSBInfo-r16 ::= SEQUENCE { ssb-Index-r16 SSB-Index, numberOfPreamblesSentOnSSB-r16 INTEGER (1..200), perRAAttemptInfoList-r16 PerRAAttemptInfoList-r16 } PerRACSI-RSInfo-r16 ::= SEQUENCE { csi-RS-Index-r16 CSI-RS-Index, numberOfPreamblesSentOnCSI-RS-r16 INTEGER (1..200) } PerRAAttemptInfoList-r16 ::= SEQUENCE (SIZE (1..200)) OF PerRAAttemptInfo-r16 PerRAAttemptInfo-r16 ::= SEQUENCE { contentionDetected-r16 BOOLEAN OPTIONAL, dlRSRPAboveThreshold-r16 BOOLEAN OPTIONAL, ... } RLF-Report-r16 ::= CHOICE { nr-RLF-Report-r16 SEQUENCE { measResultLastServCell-r16 MeasResultRLFNR-r16, measResultNeighCells-r16 SEQUENCE { measResultListNR-r16 MeasResultList2NR-r16 OPTIONAL, measResultListEUTRA-r16 MeasResultList2EUTRA-r16 OPTIONAL } OPTIONAL, c-RNTI-r16 RNTI-Value, previousPCellId-r16 CHOICE { nrPreviousCell-r16 CGI-Info-Logging-r16, eutraPreviousCell-r16 CGI-InfoEUTRALogging } OPTIONAL, failedPCellId-r16 CHOICE { nrFailedPCellId-r16 CHOICE { cellGlobalId-r16 CGI-Info-Logging-r16, pci-arfcn-r16 SEQUENCE { physCellId-r16 PhysCellId, carrierFreq-r16 ARFCN-ValueNR } }, eutraFailedPCellId-r16 CHOICE { cellGlobalId-r16 CGI-InfoEUTRALogging, pci-arfcn-r16 SEQUENCE { physCellId-r16 EUTRA-PhysCellId, carrierFreq-r16 ARFCN-ValueEUTRA } } }, reconnectCellId-r16 CHOICE { nrReconnectCellId-r16 CGI-Info-Logging-r16, eutraReconnectCellId-r16 CGI-InfoEUTRALogging } OPTIONAL, timeUntilReconnection-16 TimeUntilReconnection-16 OPTIONAL, reestablishmentCellId-r16 CGI-Info-Logging-r16 OPTIONAL, timeConnFailure-r16 INTEGER (0..1023) OPTIONAL, timeSinceFailure-r16 TimeSinceFailure-r16, connectionFailureType-r16 ENUMERATED {rlf, hof}, rlf-Cause-r16 ENUMERATED {t310-Expiry, randomAccessProblem, rlc-MaxNumRetx, beamFailureRecoveryFailure, lbtFailure-r16, bh-rlfRecoveryFailure, spare2, spare1}, locationInfo-r16 LocationInfo-r16 OPTIONAL, noSuitableCellFound-r16 ENUMERATED {true} OPTIONAL, ra-InformationCommon-r16 RA-InformationCommon-r16 OPTIONAL, ... }, eutra-RLF-Report-r16 SEQUENCE { failedPCellId-EUTRA CGI-InfoEUTRALogging, measResult-RLF-Report-EUTRA-r16 OCTET STRING, ... } } MeasResultList2NR-r16 ::= SEQUENCE(SIZE (1..maxFreq)) OF MeasResult2NR-r16 MeasResultList2EUTRA-r16 ::= SEQUENCE(SIZE (1..maxFreq)) OF MeasResult2EUTRA-r16 MeasResult2NR-r16 ::= SEQUENCE { ssbFrequency-r16 ARFCN-ValueNR OPTIONAL, refFreqCSI-RS-r16 ARFCN-ValueNR OPTIONAL, measResultList-r16 MeasResultListNR } MeasResultListLogging2NR-r16 ::= SEQUENCE(SIZE (1..maxFreq)) OF MeasResultLogging2NR-r16 MeasResultLogging2NR-r16 ::= SEQUENCE { carrierFreq-r16 ARFCN-ValueNR, measResultListLoggingNR-r16 MeasResultListLoggingNR-r16 } MeasResultListLoggingNR-r16 ::= SEQUENCE (SIZE (1..maxCellReport)) OF MeasResultLoggingNR-r16 MeasResultLoggingNR-r16 ::= SEQUENCE { physCellId-r16 PhysCellId, resultsSSB-Cell-r16 MeasQuantityResults, numberOfGoodSSB-r16 INTEGER (1..maxNrofSSBs-r16) OPTIONAL } MeasResult2EUTRA-r16 ::= SEQUENCE { carrierFreq-r16 ARFCN-ValueEUTRA, measResultList-r16 MeasResultListEUTRA } MeasResultRLFNR-r16 ::= SEQUENCE { measResult-r16 SEQUENCE { cellResults-r16 SEQUENCE{ resultsSSB-Cell-r16 MeasQuantityResults OPTIONAL, resultsCSI-RS-Cell-r16 MeasQuantityResults OPTIONAL }, rsIndexResults-r16 SEQUENCE{ resultsSSB-Indexes-r16 ResultsPerSSB-IndexList OPTIONAL, ssbRLMConfigBitmap-r16 BIT STRING (SIZE (64)) OPTIONAL, resultsCSI-RS-Indexes-r16 ResultsPerCSI-RS-IndexList OPTIONAL, csi-rsRLMConfigBitmap-r16 BIT STRING (SIZE (96)) OPTIONAL } OPTIONAL } } TimeSinceFailure-r16 ::= INTEGER (0..172800) MobilityHistoryReport-r16 ::= VisitedCellInfoList-r16 TimeUntilReconnection-16 ::= INTEGER (0..172800) UEInformationResponse-v1700-IEs ::= SEQUENCE { si-RequestReportList-r17 SI-RequestReportList-r17 ... } SI-RequestReportList-r17 ::= SEQUENCE (SIZE (1..maxSIRequestReport-r17)) OF SI-RequestReport-r17 SI-RequestReport-r17 ::= SEQUENCE { cellId-r16 CHOICE { cellGlobalId-r16 CGI-Info-Logging-r16, pci-arfcn-r16 SEQUENCE { physCellId-r16 PhysCellId, carrierFreq-r16 ARFCN-ValueNR } }, wantedSIB-Types-r17 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r17, siRequestType-r17 ENUMERATED {msg1Based, msg3Based, rrcConnectedStateRequest), perRAInfoList-r16 PerRAInfoList-r16 OPTIONAL, -- Cond msg1msg3Request si-RRC-ConnStateConfigInfo-r17 SI-RRC-ConnStateConfigInfo-r17 OPTIONAL, -- Cond rrcConnStateRequest perRRC-ConnStateSI-RequestAttemptInfoList-r17 SEQUENCE (SIZE (1..maxNoOfSI-RequestAttemptsRRC-ConnState) OF PerRRC-ConnStateSI-RequestAttemptInfo-r17 OPTIONAL, -- Cond rrcConnStateRequest initiationTime InitiationTimestamp, locationInfo LocationInfo-r16 OPTIONAL, outcome-r17 Outcome-r17, receivedSIB-Types-r17 SEQUENCE (SIZE (1..maxSIB)) OF SIB-Type-r17 OPTIONAL, -- Cond ackedAndSubsetOfWantedSIBsReceived si-MessageReceptionInfo-r17 SI-MessageReceptionInfo-r17 OPTIONAL, -- Cond si-MessageReceptionAttempted ... } SIB-Type-r17 ::= ENUMERATED {sibType2, sibType3, sibType4, sibType5, sibType6, sibType7, sibType8, sibType9, sibType10-v1610, sibType11-v1610, sibType12-v1610, sibType13-v1610, sibType14-v1610, spare3, spare2, spare1, ...} InitiationTimestamp ::= CHOICE { preciseUTC INTEGER (0..8796093022207), coarseUTC-HSFN-SFN-SlotSymbol CoarseUTC-HSFN-SFN-SlotSymbol, coarseUTC-HSFN-SFN-Slot CoarseUTC-HSFN-SFN-Slot, coarseUTC-HSFN-SFN CoarseUTC-HSFN-SFN, semiCoarseUTC-SFN-SlotSymbol SemiCoarseUTC-SFN-SlotSymbol, semiCoarseUTC-SFN-Slot SemiCoarseUTC-SFN-Slot, semiCoarseUTC-SFN SemiCoarseUTC-SFN, hsfn-SFN-SlotSymbol HSFN-SFN-SlotSymbol, hsfn-SFN-Slot HSFN-SFN-Slot, hsfn-SFN HSFN-SFN, gnssTime GNSS-Time } CoarseUTC-HSFN-SFN-SlotSymbol ::= SEQUENCE { coarseUTC INTEGER (0..268435455), hsfn INTEGER (0..1023), sfn INTEGER (0..1023), slot INTEGER (0..159), symbol INTEGER (0..13) } CoarseUTC-HSFN-SFN-Slot ::= SEQUENCE { coarseUTC INTEGER (0..268435455), hsfn INTEGER (0..1023), sfn INTEGER (0..1023), slot INTEGER (0..159) } CoarseUTC-HSFN-SFN ::= SEQUENCE { coarseUTC INTEGER (0..268435455), hsfn INTEGER (0..1023), sfn INTEGER (0..1023), slot INTEGER (0..159) } SemiCoarseUTC-SFN-SlotSymbol ::= SEQUENCE { semiCoarseUTC INTEGER (0..4294967295), sfn INTEGER (0..1023), slot INTEGER (0..159), symbol INTEGER (0..13) } SemiCoarseUTC-SFN-Slot ::= SEQUENCE { semiCoarseUTC INTEGER (0..4294967295), sfn INTEGER (0..1023), slot INTEGER (0..159) } SemiCoarseUTC-SFN ::= SEQUENCE { semiCoarseUTC INTEGER (0..4294967295), sfn INTEGER (0..1023) } HSFN-SFN-SlotSymbol ::= SEQUENCE { hsfn INTEGER (0..1023), sfn INTEGER (0..1023), slot INTEGER (0..159), symbol INTEGER (0..13) } HSFN-SFN-Slot ::= SEQUENCE { hsfn INTEGER (0..1023), sfn INTEGER (0..1023), slot INTEGER (0..159) } HSFN-SFN ::= SEQUENCE { hsfn INTEGER (0..1023), sfn INTEGER (0..1023) } GNSS-Time ::= SEQUENCE { timeSource CHOICE { gpsTime INTEGER (0..4398046511104), galileoTime INTEGER (0..4398046511104), glonassTime INTEGER (0..8796093022207), beidouTime INTEGER (0..4398046511104), ... }, leapSeconds INTEGER (-255..256) OPTIONAL, } Outcome-r17 ::= CHOICE { concluded-r17 ENUMERATED {ackedAndAllWantedSIBsReceived, ackedAndSubsetOfWantedSIBsReceived, ackedAndNoWantedSIBsReceived, maxAllowedAttemptsReachedWithoutAck}, abandoned-r17 ENUMERATED {wantedSIBsReceived, subsetOfWantedSIBsReceived, lossOfCoverage, rlf, cellReselection, spare3, spare2, spare1, ...}, ... } SI-MessageReceptionInfo-r17 ::= SEQUENCE (SIZE(1..maxSI-Message) OF PerSI-MessageReceptionInfo-r17) PerSI-MessageReceptionInfo-r17 ::= SEQUENCE { si-MessageNumber-r17 INTEGER (1..maxSI-Message), numberOfReceptionAttempts-r17 INTEGER, si-MessageReceptionResult-r17 ENUMERATED {success, failure}, ... } SI-RRC-ConnStateConfigInfo-r17 ::= SEQUENCE { absoluteFrequencyPointA-r16 ARFCN-ValueNR, locationAndBandwidth-r16 INTEGER (0..37949), subcarrierSpacing-r16 SubcarrierSpacing, ... } PerRRC-ConnStateSI-RequestAttemptInfo-r17 ::= SEQUENCE { numberOfHARQ-Retransmissions-r17 INTEGER, relativeTimestamp RelativeTimestamp OPTIONAL, -- In case of HARQ retransmissions, the relative timestamp indicates the time of the first transmission. ... } RelativeTimestamp ::= CHOICE { milliseconds INTEGER (0..1048575), slots INTEGER (0..4194303), symbols INTEGER (0..67108863), ... } -- TAG-UEINFORMATIONRESPONSE-STOP -- ASN1STOP

[0074] UEInformationResponse-IE field descriptions logMeasReport This field is used to provide measurements stored by the UE associated with the logged MDT. measResultIdleEUTRA EUTRA measurement results performed during RRC_INACTIVE or RRC_IDLE. measResultIdleNR NR measurement results performed during RRC_INACTIVE or RRC_IDLE. ra-ReportList This field is used to provide a list of RA reports that the UE stores up to the number maxRAReport-r16 of previous successful random access procedures. rlf-Report This field is used to indicate the RLF report related content. SI-RequestReportList This field contains a list of SI request reports that the UE stores for up to maxSIRequestReport number of previous SI request procedures.

[0075] RA-Report Field Descriptions absoluteFrequencyPointA This field indicates the absolute frequency location of the reference resource block (common RB0). cellID This field indicates the CGI of the cell in which the associated random access procedure was performed. contentionDetected This field is used to indicate whether a transmission preamble conflict was detected for the specified random access attempt. This field is not included if the UE uses a contention-free random access resource when making the random access attempt or if raPurpose is set to requestForOtherSI. csi-RS-Index This field is used to indicate the CSI-RS index that corresponds to the random access attempt. dlRSRPAboveThreshold This field is used to indicate whether the DL beam (SSB) quality associated with the random access attempt has gone above or below the threshold rsrp-ThresholdSSB in the beamFailureRecoveryConfig of the UL_BWP configuration of the UL_BWP selected for the random access procedure initiated for beam failure recovery. locationAndBandwidth The frequency domain location and bandwidth of the bandwidth portion associated with the random access resource used by the UE. numberOfPreamblesSentOnCSI-RS This field is used to indicate the total number of consecutive RA preambles transmitted in the corresponding CSI-RS. numberOfPreamblesSentOnSSB This field is used to indicate the total number of consecutive RA preambles transmitted in the corresponding SS / PBCH block. perRAAttemptInfoList This field provides detailed information about the random access attempt. perRAInfoList This field provides detailed information about each random access attempt in chronological order of the random access attempts. perRACSI-RSInfoList This field provides detailed information about successive random access attempts associated with the same CSI-RS. perRASSBInfoList This field provides detailed information about successive random access attempts related to the same SS / PBCH block. raPurpose This field is used to indicate the RA scenario for which the RA report entry is triggered. Initial access from RRC_IDLE, transition from RRC-INACTIVE, and RA access related to an SI request based on MSG3 are indicated using the indicator "accessRelated". The indicator beamFailureRecovery is used if an RA procedure related to beam failure recovery in the SpCell [3] is successful. The indicator reconfigurationWithSync is used if the UE has performed a reconfiguration with synchronization. The indicator ulUnSynchronized is used if a random access procedure is initiated in the SpCell by DL or UL data arrival during RRC_CONNECTED when the timeAlignmentTimer is not running in the PTAG, or if an RA procedure is initiated in the serving cell by a PDCCH order [3]. The indicator schedulingRequestFailure is used in case of an SR failure [3]. The indicator noPUCCHResourceAvailable is used if the UE does not have a valid SR_PUCCH resource configured [3]. The indicator requestForOtherSI is used for a request SI request based on MSG1. ra-InformationCommon This field is used to indicate random access related information that is common between RA and RLF reports. In RA reports, this field must be present. In RLF reports, this field is optionally present if connectionFailureType is set to 'hof' or if connectionFailureType is set to 'rlf' and rlf-Cause is equal to 'randomAccessProblem' or 'beamRecoveryFailure'. ssb-Index This field is used to indicate the SS / PBCH index of the SS / PBCH block that corresponds to the random access attempt. subcarrierSpacing The subcarrier spacing used in the BWP related to the random access resource used by the UE.

[0076] SI-RequestReport Field Descriptions cellID This field indicates the cell ID of the cell for which the associated SI request procedure was performed, in the form of a combination of CGI or PCI and carrier frequency. coarseUTC This field indicates the number of 32768 milliseconds since midnight between December 31, 1899 and January 1, 1900 according to UTC. contentionDetected This field is used to indicate whether a transmitted preamble collision was detected when attempting an Msg3 based SI request. This field is not included if the UE uses an Msg1 based SI request. dlRSRPAboveThreshold This field is used to indicate whether the RSRP of the DL beam (SSB) associated with the SI request attempt was greater than or equal to the threshold rsrp-ThresholdSSB in rach-ConfigCommon in the UL_BWP configuration of the UL_BWP selected for the SI request procedure. gnssTime This field indicates the number of milliseconds since the start of timekeeping for the respective GNSS time source. initiationTime This field indicates the time when the SI request procedure was started. For SI requests based on Msg1 and Msg3, this time is the start time of the first symbol of the PRACH occasion used for random access preamble transmission. For SI requests using the DedicatedSIBReqeust message in RRC_CONNECTED state, the indicated time is the start time of the first symbol of the PUSCH transmission carrying the DedicatedSIBReqeust message (or the first transmission in case of HARQ retransmissions). If the time representation used in the parameter has a coarser granularity, the indicated (rounded) time should be the value closest to the actual start time. locationInfo This field contains the UE's location information and possibly its velocity information. Ideally, it should indicate the UE's location (and velocity, if applicable) at the start of the SI request procedure, although the reported location information may have been collected at a different time, as indicated by the locationTimestamp parameter of the commonLocationInfoIE. outcome This field indicates the result of the SI request procedure. The presence of the field "concluded" indicates that the SI request procedure has either been acknowledged (by a matching RAPID field in Msg2 for an Msg1-based SI request, or by a matching UE_Contention_Resolution_ID_MAC_CE in Msg4 for an Msg3-based SI request, or by an RLC acknowledgement of the SI request using a DedicatedSIBRequest message) or continued until the maximum number of SI request attempts was reached without receiving an acknowledgement. If the SI request is acknowledged, the UE can receive all requested SIBs (i.e., the SIBs of the SI request). This is indicated by the ENUMERATED values ​​"ackedAndAllWantedSIBsReceived", "ackedAndSubsetOfWantedSIBsReceived", and "ackedAndNoWantedSIBsReceived". If the UE has made the maximum allowed number of SI request attempts without receiving an acknowledgement, the conceded field is set to the value "maxAllowedAttemptsReachedWithoutAck". The presence of the abandoned field indicates that the SI request procedure was abandoned before the maximum number of allowed attempts was performed, even if the SI request procedure did not receive an acknowledgment. The reason for abandoning the SI request procedure is indicated by the value provided by this field. perRRC-ConnStateSI-RequestAttemptInfoList This field provides detailed information about the number of consecutive SI request attempts performed through the transmission of DedicatedSIBRequest messages in the RRC_CONNECTED state. One SI request attempt may consist of a set of associated HARQ retransmissions. preciseUTC This field indicates the number of milliseconds since midnight between December 31, 1899 and January 1, 1900, based on UTC. receivedSIB-Types This field indicates the wanted SIBs (if any) received by the UE if the UE's SI request is confirmed (by a matching RAPID field in Msg2 for an Msg1-based SI request, or by a matching UE_Contention_Resolution_ID_MAC_CE in Msg4 for an Msg3-based SI request, or by a matching RLC acknowledgment for an SI request using a DedicatedSIBRequest message) and the UE has received at least one, but not all, of the wanted SIBs (i.e., SIBs of the types indicated in the wantedSIB-Types field). This field is present if the outcome field is present. This field is present if the outcome field contains a concluding field set to the value "ackedAndSubsetOfWantedSIBsReceived", and is absent otherwise. relativeTimestamp This field indicates the elapsed time from the time indicated by the initiationTime field to the start of the SI request attempt to which the relativeTimestamp field relates. For SI request attempts based on Msg1 and Msg3, the start of the SI request attempt is the start of the first symbol of the PRACH occasion used for random access preamble transmission. For SI request attempts using a DedicatedSIBRequest message, the start of the SI request attempt is the start of the first symbol of the PUSCH resource used for transmitting the DedicatedSIBRequest message. If the SI request attempt includes HARQ retransmissions, the relative timestamp indicates the start time of the first transmission. semiCoarseUTC This field indicates the time since midnight between December 31, 1899 and January 1, 1900, based on UTC, in units of 2048 milliseconds. si-MessageReceptionInfo This field provides information related to the reception or attempted reception of the requested SI message. This field is not present if the UE did not attempt to receive the requested SI message. This means that this field is present if the result field contains the concluding field set to one of the following values: "ackedAndAllWantedSIBsReceived", "ackedAndSubsetOfWantedSIBsReceived", or "ackedAndNoWantedSIBsReceived". si-RequestType This field indicates either an Msg1-based SI request, an Msg3-based SI request, or the type of SI request using a DedicatedSIBRequest message in the RRC_CONNECTED state. si-RRC-ConnStateConfigInfo This field provides general configuration information related to the SI request mechanism in the RRC_CONNECTED state. ssb-Index This field is used to indicate the SS / PBCH index of the SS / PBCH block that corresponds to the SI request attempt. wantedSIB-Types This field indicates which (all or a subset) of the SIBs in the requested SI message (during the SI request procedure to which this SI-RequestReport instance pertains) the UE is interested in. For example, if SIBX, SIBY, and SIBZ are included in the same SI message that is available on demand, and the wantedSIB-Types parameter of the SI-RequestReport indicates SIB types X and Y, this means that in the SI request procedure to which the SI-RequestReport pertains, the UE requested an SI message containing SIBX, SIBY, and SIBZ, but the UE was only interested in SIBX and SIBY, and not SIBZ. (Note: If, between successive attempts, the UE changes the requested SIBs or the requested SI message or SIBs, this should be considered a new SI request procedure and should be logged and reported as a new SI-RequestReport.)

[0077] SI-RRC-ConnStateConfigInfo Field Description absoluteFrequencyPointA This field indicates the absolute frequency location of the reference resource block (common RB0). locationAndBandwidth The frequency domain location and bandwidth of the bandwidth portion used for the transmission of the DedicatedSIBRequest message of the SI request procedure to which this SI-RequestReport pertains. subcarrierSpacing This field indicates the subcarrier spacing used for transmitting the DedicatedSIBRequest message of the SI request procedure to which this SI-RequestReport pertains.

[0078] Conditional Presence and Description ackedAndSubsetOfWantedSIBsReceived This field is present if the UE's SI request is acknowledged (matching RAPID field in Msg2 for Msg1-based SI requests, matching UE_Contention_Resolution_ID_MAC_CE in Msg4 for Msg3-based SI requests, or matching RLC acknowledgement for SI requests using a DedicatedSIBRequest message) and the UE has received at least one (but not all) of the desired SIBs (i.e., SIBs of the types indicated in the wantedSIB-Types field). Therefore, this field is mandatory if the outcome field contains the concluding field set to the value "ackedAndSubsetOfWantedSIBsReceived", otherwise this field is absent. msg1msg3Request This field is required if the SI request is performed with the Msg1-based SI request method or the Msg3-based SI request method, otherwise this field is not present if the SI request is performed by sending a DedicatedSIBRequest message. msg3Request This field is required if the SI request is performed using the Msg3-based SI request method. rrcConnStateRequest This field is required if the SI request is performed by sending a DedicatedSIBRequest message. si-MessageReceptionAttempted This field is mandatory to be present if the UE has attempted (either successfully or unsuccessfully) to receive at least one requested SI message.

[0079] LocationInfo The IE "LocationInfo" is used to transfer detailed location information, Bluetooth, WLAN and sensor measurements available in the UE.

[0080] LocationInfo information element -- ASN1START -- TAG-LOCATIONINFO-START LocationInfo-r16 ::= SEQUENCE { commonLocationInfo-r16 CommonLocationInfo-r16 OPTIONAL, bt-LocationInfo-r16 LogMeasResultListBT-r16 OPTIONAL, wlan-LocationInfo-r16 LogMeasResultListWLAN-r16 OPTIONAL, sensor-LocationInfo-r16 Sensor-LocationInfo-r16 OPTIONAL, ... } -- TAG-LOCATIONINFO-STOP -- ASN1STOP

[0081] CommonLocationInfo The IE "CommonLocationInfo" is used to transfer detailed location information available at the UE in order to associate measurements with the UE's location information.

[0082] CommonLocationInfo information element -- ASN1START -- TAG-COMMONLOCATIONINFO-START CommonLocationInfo-r16 ::= SEQUENCE { gnss-TOD-msec-r16 OCTET STRING OPTIONAL, locationTimestamp-r16 OCTET STRING OPTIONAL, locationCoordinate-r16 OCTET STRING OPTIONAL, locationError-r16 OCTET STRING OPTIONAL, locationSource-r16 OCTET STRING OPTIONAL, velocityEstimate-r16 OCTET STRING OPTIONAL } -- TAG-COMMONLOCATIONINFO-STOP -- ASN1STOP

[0083] CommonLocationInfo field descriptions gnss-TOD-msec Parameter type gnss-TOD-msec as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit. locationTimeStamp Parameter type DisplacementTimeStamp as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit. locationCoordinate Parameter type LocationCoordinates as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit. locationError Parameter LocationError as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit. locationSource Parameter LocationSource as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit. velocityEstimate Parameter type Velocity as defined in TS37.355

[49] . The first / leftmost bit of the first octet contains the most significant bit.

[0084] Example 3 The following is yet another non-limiting example.

[0085] UEInformationResponse Message -- ASN1START -- TAG-UEINFORMATIONRESPONSE-START UEInformationResponse-r16 ::= SEQUENCE { rrc-TransactionIdentifier RRC-TransactionIdentifier, criticalExtensions CHOICE { ueInformationResponse-r16 UEInformationResponse-r16-IEs, criticalExtensionsFuture SEQUENCE {} } } UEInformationResponse-r16-IEs ::= SEQUENCE { measResultIdleEUTRA-r16 MeasResultIdleEUTRA-r16 OPTIONAL, measResultIdleNR-r16 MeasResultIdleNR-r16 OPTIONAL, logMeasReport-r16 LogMeasReport-r16 OPTIONAL, connEstFailReport-r16 ConnEstFailReport-r16 OPTIONAL, ra-ReportList-r16 RA-ReportList-r16 OPTIONAL, rlf-Report-r16 RLF-Report-r16 OPTIONAL, mobilityHistoryReport-r16 MobilityHistoryReport-r16 OPTIONAL, SI-ReportList-r17 SI-ReportList-r17 OPTIONAL, lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension SEQUENCE {} OPTIONAL } SI-ReportList-r17 ::= SEQUENCE (SIZE (1..maxSIReport-r17)) OF SI-Report-r17 SI-Report-r17 ::= SEQUENCE { cellId-r17 CHOICE { cellGlobalId-r17 CGI-Info-Logging-r16, pci-arfcn-r17 SEQUENCE { physCellId-r16 PhysCellId, carrierFreq-r16 ARFCN-ValueNR } }, SuccessfulSIRequestAck-r17 BOOLEAN OPTIONAL, SuccessfulSIAcquiring-r17 BOOLEAN OPTIONAL, SuccessfulSIAcquiringWithAbortedRACH BOOLEAN OPTIONAL, ListenToNearestSIWindow BOOLEAN OPTIONAL, measResultServingCell-r16 MeasResultServingCell-r16 OPTIONAL, measResultNeighCells-r16 SEQUENCE { measResultNeighCellListNR MeasResultListLogging2NR-r16 OPTIONAL, measResultNeighCellListEUTRA MeasResultList2EUTRA-r16 OPTIONAL }, ... } LogMeasReport-r16 ::= SEQUENCE { absoluteTimeStamp-r16 AbsoluteTimeInfo-r16, traceReference-r16 TraceReference-r16, traceRecordingSessionRef-r16 OCTET STRING (SIZE (2)), tce-Id-r16 OCTET STRING (SIZE (1)), logMeasInfoList-r16 LogMeasInfoList-r16, logMeasAvailable-r16 ENUMERATED {true} OPTIONAL, logMeasAvailableBT-r16 ENUMERATED {true} OPTIONAL, logMeasAvailableWLAN-r16 ENUMERATED {true} OPTIONAL, ... } LogMeasInfoList-r16 ::= SEQUENCE (SIZE (1..maxLogMeasReport-r16)) OF LogMeasInfo-r16 LogMeasInfo-r16 ::= SEQUENCE { locationInfo-r16 LocationInfo-r16 OPTIONAL, relativeTimeStamp-r16 INTEGER (0..7200), servCellIdentity-r16 CGI-Info-Logging-r16 OPTIONAL, measResultServingCell-r16 MeasResultServingCell-r16 OPTIONAL, measResultNeighCells-r16 SEQUENCE { measResultNeighCellListNR MeasResultListLogging2NR-r16 OPTIONAL, measResultNeighCellListEUTRA MeasResultList2EUTRA-r16 OPTIONAL }, anyCellSelectionDetected-r16 ENUMERATED {true} OPTIONAL } ConnEstFailReport-r16 ::= SEQUENCE { measResultFailedCell-r16 MeasResultFailedCell-r16, locationInfo-r16 LocationInfo-r16 OPTIONAL, measResultNeighCells-r16 SEQUENCE { measResultNeighCellListNR MeasResultList2NR-r16 OPTIONAL, measResultNeighCellListEUTRA MeasResultList2EUTRA-r16 OPTIONAL }, numberOfConnFail-r16 INTEGER (1..8), perRAInfoList-r16 PerRAInfoList-r16, timeSinceFailure-r16 TimeSinceFailure-r16, ... } MeasResultServingCell-r16 ::= SEQUENCE { resultsSSB-Cell MeasQuantityResults, resultsSSB SEQUENCE{ best-ssb-Index SSB-Index, best-ssb-Results MeasQuantityResults, numberOfGoodSSB INTEGER (1..maxNrofSSBs-r16) } OPTIONAL } MeasResultFailedCell-r16 ::= SEQUENCE { cgi-Info CGI-Info-Logging-r16, measResult-r16 SEQUENCE { cellResults-r16 SEQUENCE{ resultsSSB-Cell-r16 MeasQuantityResults }, rsIndexResults-r16 SEQUENCE{ resultsSSB-Indexes-r16 ResultsPerSSB-IndexList } } } RA-ReportList-r16 ::= SEQUENCE (SIZE (1..maxRAReport-r16)) OF RA-Report-r16 RA-Report-r16 ::= SEQUENCE { cellId-r16 CHOICE { cellGlobalId-r16 CGI-Info-Logging-r16, pci-arfcn-r16 SEQUENCE { physCellId-r16 PhysCellId, carrierFreq-r16 ARFCN-ValueNR } }, ra-InformationCommon-r16 RA-InformationCommon-r16, raPurpose-r16 ENUMERATED {accessRelated, beamFailureRecovery, reconfigurationWithSync, ulUnSynchronized, schedulingRequestFailure, noPUCCHResourceAvailable, requestForOtherSI, spare9, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1} } RA-InformationCommon-r16 ::= SEQUENCE { absoluteFrequencyPointA-r16 ARFCN-ValueNR, locationAndBandwidth-r16 INTEGER (0..37949), subcarrierSpacing-r16 SubcarrierSpacing, msg1-FrequencyStart-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL, msg1-FrequencyStartCFRA-r16 INTEGER (0..maxNrofPhysicalResourceBlocks-1) OPTIONAL, msg1-SubcarrierSpacing-r16 SubcarrierSpacing OPTIONAL, msg1-SubcarrierSpacingCFRA-r16 SubcarrierSpacing OPTIONAL, msg1-FDM-r16 ENUMERATED {one, two, four, eight} OPTIONAL, msg1-FDMCFRA-r16 ENUMERATED {one, two, four, eight} OPTIONAL, perRAInfoList-r16 PerRAInfoList-r16 } PerRAInfoList-r16 ::= SEQUENCE (SIZE (1..200)) OF PerRAInfo-r16 PerRAInfo-r16 ::= CHOICE { perRASSBInfoList-r16 PerRASSBInfo-r16, perRACSI-RSInfoList-r16 PerRACSI-RSInfo-r16 } PerRASSBInfo-r16 ::= SEQUENCE { ssb-Index-r16 SSB-Index, numberOfPreamblesSentOnSSB-r16 INTEGER (1..200), perRAAttemptInfoList-r16 PerRAAttemptInfoList-r16 } PerRACSI-RSInfo-r16 ::= SEQUENCE { csi-RS-Index-r16 CSI-RS-Index, numberOfPreamblesSentOnCSI-RS-r16 INTEGER (1..200) } PerRAAttemptInfoList-r16 ::= SEQUENCE (SIZE (1..200)) OF PerRAAttemptInfo-r16 PerRAAttemptInfo-r16 ::= SEQUENCE { contentionDetected-r16 BOOLEAN OPTIONAL, dlRSRPAboveThreshold-r16 BOOLEAN OPTIONAL, ... } RLF-Report-r16 ::= CHOICE { nr-RLF-Report-r16 SEQUENCE { measResultLastServCell-r16 MeasResultRLFNR-r16, measResultNeighCells-r16 SEQUENCE { measResultListNR-r16 MeasResultList2NR-r16 OPTIONAL, measResultListEUTRA-r16 MeasResultList2EUTRA-r16 OPTIONAL } OPTIONAL, c-RNTI-r16 RNTI-Value, previousPCellId-r16 CHOICE { nrPreviousCell-r16 CGI-Info-Logging-r16, eutraPreviousCell-r16 CGI-InfoEUTRALogging } OPTIONAL, failedPCellId-r16 CHOICE { nrFailedPCellId-r16 CHOICE { cellGlobalId-r16 CGI-Info-Logging-r16, pci-arfcn-r16 SEQUENCE { physCellId-r16 PhysCellId, carrierFreq-r16 ARFCN-ValueNR } }, eutraFailedPCellId-r16 CHOICE { cellGlobalId-r16 CGI-InfoEUTRALogging, pci-arfcn-r16 SEQUENCE { physCellId-r16 EUTRA-PhysCellId, carrierFreq-r16 ARFCN-ValueEUTRA } } }, reconnectCellId-r16 CHOICE { nrReconnectCellId-r16 CGI-Info-Logging-r16, eutraReconnectCellId-r16 CGI-InfoEUTRALogging } OPTIONAL, timeUntilReconnection-16 TimeUntilReconnection-16 OPTIONAL, reestablishmentCellId-r16 CGI-Info-Logging-r16 OPTIONAL, timeConnFailure-r16 INTEGER (0..1023) OPTIONAL, timeSinceFailure-r16 TimeSinceFailure-r16, connectionFailureType-r16 ENUMERATED {rlf, hof}, rlf-Cause-r16 ENUMERATED {t310-Expiry, randomAccessProblem, rlc-MaxNumRetx, beamFailureRecoveryFailure, lbtFailure-r16, bh-rlfRecoveryFailure, spare2, spare1}, locationInfo-r16 LocationInfo-r16 OPTIONAL, noSuitableCellFound-r16 ENUMERATED {true} OPTIONAL, ra-InformationCommon-r16 RA-InformationCommon-r16 OPTIONAL, ... }, eutra-RLF-Report-r16 SEQUENCE { failedPCellId-EUTRA CGI-InfoEUTRALogging, measResult-RLF-Report-EUTRA-r16 OCTET STRING, ... } } MeasResultList2NR-r16 ::= SEQUENCE(SIZE (1..maxFreq)) OF MeasResult2NR-r16 MeasResultList2EUTRA-r16 ::= SEQUENCE(SIZE (1..maxFreq)) OF MeasResult2EUTRA-r16 MeasResult2NR-r16 ::= SEQUENCE { ssbFrequency-r16 ARFCN-ValueNR OPTIONAL, refFreqCSI-RS-r16 ARFCN-ValueNR OPTIONAL, measResultList-r16 MeasResultListNR } MeasResultListLogging2NR-r16 ::= SEQUENCE(SIZE (1..maxFreq)) OF MeasResultLogging2NR-r16 MeasResultLogging2NR-r16 ::= SEQUENCE { carrierFreq-r16 ARFCN-ValueNR, measResultListLoggingNR-r16 MeasResultListLoggingNR-r16 } MeasResultListLoggingNR-r16 ::= SEQUENCE (SIZE (1..maxCellReport)) OF MeasResultLoggingNR-r16 MeasResultLoggingNR-r16 ::= SEQUENCE { physCellId-r16 PhysCellId, resultsSSB-Cell-r16 MeasQuantityResults, numberOfGoodSSB-r16 INTEGER (1..maxNrofSSBs-r16) OPTIONAL } MeasResult2EUTRA-r16 ::= SEQUENCE { carrierFreq-r16 ARFCN-ValueEUTRA, measResultList-r16 MeasResultListEUTRA } MeasResultRLFNR-r16 ::= SEQUENCE { measResult-r16 SEQUENCE { cellResults-r16 SEQUENCE{ resultsSSB-Cell-r16 MeasQuantityResults OPTIONAL, resultsCSI-RS-Cell-r16 MeasQuantityResults OPTIONAL }, rsIndexResults-r16 SEQUENCE{ resultsSSB-Indexes-r16 ResultsPerSSB-IndexList OPTIONAL, ssbRLMConfigBitmap-r16 BIT STRING (SIZE (64)) OPTIONAL, resultsCSI-RS-Indexes-r16 ResultsPerCSI-RS-IndexList OPTIONAL, csi-rsRLMConfigBitmap-r16 BIT STRING (SIZE (96)) OPTIONAL } OPTIONAL } } TimeSinceFailure-r16 ::= INTEGER (0..172800) MobilityHistoryReport-r16 ::= VisitedCellInfoList-r16 TimeUntilReconnection-16 ::= INTEGER (0..172800)

[0086] 2 illustrates an example of a communications system 200 according to some embodiments. In this example, the communications system 200 includes a telecommunications network 202 including an access network 204, such as a radio access network (RAN), and a core network 206 including one or more core network nodes 208. The access network 204 includes one or more access network nodes, such as network nodes 210a and 210b (one or more of which may be referred to generally as network nodes 210), or other similar Third Generation Partnership Project (3GPP) access nodes or non-3GPP access points. The network nodes 210 facilitate direct or indirect connectivity of user equipment (UE) devices 212a, 212b, 212c, and 212d (one or more of which may be referred to generally as UEs 212) to the core network 206 via one or more wireless connections.

[0087] Exemplary wireless communication via wireless connections includes sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Additionally, in different embodiments, communication system 200 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals, whether via wired or wireless connections. Communication system 200 may include and / or interface with any type of communication, telecommunication, data, cellular, wireless network, and / or other similar type systems.

[0088] The UE 212 may be any of a wide variety of communication devices, including a wireless device arranged, configured, and / or operable to communicate wirelessly with the network node 210 and other communication devices. Similarly, the network node 210 is arranged, configured, and / or operable to communicate, directly or indirectly, with the UE 212 and / or with other network nodes or equipment within the telecommunications network 202, to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as management, within the telecommunications network 202.

[0089] In the depicted example, the core network 206 connects the network node 210 to one or more hosts, such as the host 216. These connections are made directly or indirectly through one or more intermediate networks or devices. In other examples, the network nodes may be directly coupled to the hosts. The core network 206 includes one or more core network nodes (e.g., the core network node 208) structured with hardware and software components. The functionality of these components may be substantially similar to that described with respect to a UE, a network node, and / or a host, and the description of such components is generally applicable to the corresponding components of the core network node 208. An exemplary core network node includes one or more functions of a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscriber identity suppression function (SIDF), a unified data management (UDM), a security edge protection proxy (SEPP), a network exposure function (NEF), and / or a user plane function (UPF).

[0090] The host 216 may be owned or under the control of, and operated by, or on behalf of, a service provider other than the operator or provider of the access network 204 and / or the telecommunications network 202. The host 216 may host various applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services such as acquiring and compiling data about various ambient conditions detected by multiple UEs, analytics functions, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and monitoring center, or any other such function performed by a server.

[0091] 2 enables connectivity between UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as, but not limited to, a particular standard, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G), a wireless local area network (WLAN) standard such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi), and / or other suitable wireless communication standards, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC), ZigBee, LiFi, and / or a low power wide area network (LPWAN) standard such as LoRa or Sigfox.

[0092] In some examples, the telecommunications network 202 is a cellular network that implements 3GPP standardized features. Thus, the telecommunications network 202 may support network slicing to provide different logical networks to different devices connected to the telecommunications network 202. For example, the telecommunications network 202 may provide Ultra-Reliable Low Latency Communication (URLLC) services to some UEs, while providing enhanced Mobile Broadband (eMBB) services to other UEs and / or massive machine-based communication (mMTC) / massive IoT services to additional UEs.

[0093] In some examples, the UE 212 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to the access network 204 on a predetermined schedule, when triggered by an internal or external event, or in response to a request from the access network 204. Furthermore, the UE may be configured to operate in a single or multi-RAT or multi-standard mode. For example, the UE may operate in any one or configuration of Wi-Fi, NR (New Radio), and LTE, i.e., may be configured for Multi-Radio Dual Connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

[0094] In an example, the hub 214 communicates with the access network 204 to facilitate indirect communication between one or more UEs (e.g., UEs 212c and / or 212d) and a network node (e.g., network node 210b). In some examples, the hub 214 may be a controller, a router, a content source and analysis, or any of the other communication devices described herein for a UE. For example, the hub 214 may be a broadband router that enables the UE to access the core network 206. As another example, the hub 214 may be a controller that sends commands or instructions to one or more actuators within the UE. The commands or instructions may be received from the UE, the network node 210, or by executable code, scripts, processes, or other instructions within the hub 214. As another example, the hub 214 may be a data collector that serves as temporary storage of UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 214 may be a content source. For example, in the case of a UE that is a VR headset, display, speaker, or other media distribution device, the hub 214 may obtain, via a network node, VR assets, video, audio, or other media or data related to sensory information, which the hub 214 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In yet another example, the hub 214 acts as a proxy server or orchestrator for the UEs, particularly when one or more UEs are low-energy IoT devices.

[0095] The hub 214 may have a constant / persistent or intermittent connection to the network node 210b. The hub 214 may also enable different communication schemes and / or schedules between the hub 214 and the UEs (e.g., UEs 212c and / or 212d) and between the hub 214 and the core network 206. In other examples, the hub 214 is connected to the core network 206 and / or one or more UEs via a wired connection. Additionally, the hub 214 may be configured to connect to an M2M service provider via the access network 204 and / or to another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with the network node 210b while remaining connected through the hub 214 via a wired or wireless connection. In some embodiments, the hub 214 may be a dedicated hub, i.e., a hub whose primary function is to route communications to and from the UEs to / from the network node 210b. In other embodiments, the hub 214 may be a non-dedicated hub, i.e., a device that is operable to route communications between the UE and the network node 210b, but that is additionally operable as a communication start point and / or communication end point for a particular data channel.

[0096] Figure 3 illustrates a UE 300 according to some embodiments. As used herein, a UE refers to a device configured, arranged, and / or operable to wirelessly communicate with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smartphone, a mobile phone, a cellular phone, a voice-over-IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a game console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded device (LEE), a laptop-mounted device (LME), a smart device, a wireless customer premises equipment (CPE), an in-vehicle or in-vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrowband Internet of Things (NB-IoT) UE, a machine-type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0097] A UE may support device-to-device (D2D) communications, for example, by implementing 3GPP standards for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-any (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Instead, a UE may represent a device intended for sale to or operation by a human user, but that is not, or may not initially be, associated with a particular human user (e.g., a smart sprinkler control device). Alternatively, a UE may represent a device not intended for sale to or operation by an end user, but that may be associated with or operated for the user's benefit (e.g., a smart electricity meter).

[0098] The UE 300 includes a processing circuit 302 operably coupled to an input / output interface 306, a power source 308, a memory 310, a communication interface 312, and / or any other components, or any combination thereof, via a bus 304. A particular UE may utilize all or a subset of the components shown in FIG. 3. The level of integration between components may vary from UE to UE. Furthermore, a particular UE may include multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0099] The processing circuitry 302 is configured to process instructions and data and may be configured to implement any sequential state machine that operates to execute instructions stored as a machine-readable computer program in the memory 310. The processing circuitry 302 may be implemented as one or more hardware-implemented state machines (e.g., discrete logic, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.), programmable logic with appropriate firmware, one or more stored computer programs, a general-purpose processor such as a microprocessor or digital signal processor (DSP) with appropriate software, or any combination of the above. For example, the processing circuitry 302 may include multiple central processing units (CPUs).

[0100] In this embodiment, the input / output interface 306 may be configured to provide an input device, an output device, or an interface to one or more input and / or output devices. Examples of output devices include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smart card, another output device, or any combination thereof. An input device enables a user to capture information into the UE 300. Examples of input devices include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a webcam, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, etc. A presence-sensitive display may include a capacitive or resistive touch sensor for sensing input from a user. The sensor may be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. The output device may use the same type of interface port as the input device. For example, a Universal Serial Bus (USB) port can be used to provide input and output devices.

[0101] In some embodiments, the power source 308 is configured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., a wall outlet), a photovoltaic device, or a power battery, can also be used. The power source 308 may further include power circuitry for supplying power to various parts of the UE 300 from the power source 308 itself and / or from an external power source via an interface, such as an input circuit or a power cable. The supply of power may be for charging the power source 308, for example. The power circuitry may perform any formatting, conversion, or other modification of the power from the power source 308 to make it suitable for each component of the UE 300 being powered.

[0102] The memory 310 can be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, hard disk, removable cartridge, flash drive, etc. In one example, the memory 310 includes one or more application programs 314, such as an operating system, a web browser application, a widget, a gadget engine, or other applications, and corresponding data 316. The memory 310 can store any of a variety of operating systems or combinations of operating systems for use by the UE 300.

[0103] The memory 310 may be configured as a redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, etc., an external mini dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), SDRAM in an external micro-DIMM, smart card memory such as a tamper-resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs) such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card." The memory 310 may enable the UE 300 to access instructions, application programs, etc. stored on a temporary or non-transitory memory medium, offload data, or upload data. An article of manufacture, such as one utilizing a communication system, may be embodied as or in contact with memory 310, which may be configured as a device-readable storage medium.

[0104] The processing circuit 302 may be configured to communicate with an access network or other networks using a communication interface 312. The communication interface 312 is comprised of one or more communication subsystems and may include or be communicatively coupled to an antenna 322. The communication interface 312 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in the access network). Each transceiver may include a transmitter 318 and / or a receiver 320 appropriate for providing network communications (e.g., optical, electrical, frequency allocation, etc.). Furthermore, the transmitter 318 and receiver 320 may be coupled to one or more antennas (e.g., antenna 322), may share circuit components, software, or firmware, or may be implemented separately.

[0105] In the illustrated embodiment, the communication capabilities of communication interface 312 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as use of a Global Positioning System (GPS) to determine location, another similar communication capability, or any combination thereof. Communication may be performed in accordance with one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0106] Regardless of the type of sensor, the UE can provide an output of data captured by its sensor via its communication interface 312 over a wireless connection to a network node. Data captured by a UE's sensor can be communicated over a wireless connection to a network node via another UE. The output can be periodic (e.g., once every 15 minutes when reporting sensed temperature), random (e.g., to balance the load of reporting from multiple sensors), in response to a trigger event (e.g., an alert is sent when moisture is detected), in response to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0107] As another example, a UE may comprise an actuator, motor, or switch associated with a communications interface configured to receive wireless input from a network node via a wireless connection. The actuator, motor, or switch may change state in response to the received wireless input. For example, a UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight in response to the received input, or a robotic arm that performs a medical procedure in response to the received input.

[0108] When the UE is in the form of an Internet of Things (IoT) device, it may be a device for use in one or more application areas, including, but not limited to, urban wearable technology, augmented industrial applications, and healthcare. Non-limiting examples of such IoT devices include connected refrigerators or freezers, televisions, connected lighting devices, power meters, robot vacuums, voice-controlled smart speakers, home security cameras, motion sensors, thermostats, smoke detectors, door / window sensors, flood / moisture sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smart watches, fitness trackers, augmented reality (AR) or virtual reality (VR) head-mounted displays, haptic or sensory augmentation wearables, water sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and medical devices of any kind, such as heart rate monitors and remote surgical robots. A UE in the form of an IoT device may be comprised of circuitry and / or software depending on the intended use of the IoT device, in addition to other components such as those described in relation to UE 300 shown in FIG. 3 .

[0109] As yet another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another UE and / or network node. In this case, the UE may be an M2M device, which may be referred to as an MTC device in the 3GPP context. As a specific example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, bus, truck, ship, or aircraft, or other equipment that can monitor and / or report its operating status or other functions related to its operation.

[0110] In practice, any number of UEs can be used together for a single use case. For example, a first UE may be a drone or may be integrated into a drone and provide drone speed information (obtained via a speed sensor) to a second UE, which may be a remote controller operating the drone. As the user makes changes from the remote controller, the first UE may adjust the drone's throttle (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first UE and / or second UE may also include one or more of the functionality described above. For example, a UE may include a sensor and an actuator and handle communication of data from both the speed sensor and the actuator.

[0111] FIG. 4 illustrates a network node 400 according to some embodiments.

[0112] As used herein, a network node refers to a device in a telecommunications network that is configured, arranged, and / or operable to communicate, directly or indirectly, with UEs and / or other network nodes or devices. Examples of network nodes include, but are not limited to, access points (APs) (e.g., wireless access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)).

[0113] Base stations are classified based on the amount of coverage they provide (in other words, their transmission power level), and are sometimes referred to as femto, pico, micro, or macro base stations depending on the amount of coverage they provide. A base station may be a relay node or a relay donor node that controls the relay. A network node may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU) (sometimes called a remote radio head (RRH)). Such remote radio units may or may not be integrated with an antenna, such as an antenna-integrated radio. Some distributed radio base stations may also be referred to as nodes of a distributed antenna system (DAS).

[0114] Other examples of network nodes include multi-transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) devices such as BSs in an MSR, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmitting nodes, multi-cell / multicast coordination entities (MCEs), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (e.g., evolved serving mobile location centers (E-SMLCs)), and / or minimized driven tests (MDTs).

[0115] The network node 400 includes processing circuitry 402, memory 404, a communication interface 406, and a power source 408. The network node 400 may be comprised of multiple physically separate components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own components. In certain scenarios where the network node 400 is comprised of multiple separate components (e.g., a BTS and a BSC component), one or more of the separate components may be shared among multiple network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair may, in some cases, be considered a single, separate network node. In some embodiments, the network node 400 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memories 404 for different RATs) and some components may be reused (e.g., the same antenna 410 is shared by different RATs). Network node 400 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 400, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID) or Bluetooth wireless technologies, etc. These wireless technologies may be integrated into the same or different chips or chipsets and other components within network node 400.

[0116] The processing circuitry 402 may be comprised of one or more microprocessors, controllers, microcontrollers, central processing units, digital signal processors, application specific integrated circuits, field programmable gate arrays, or any other suitable computing devices, resources, or combinations of hardware, software, and / or coded logic operable to provide, alone or in conjunction with other network node 400 components, such as memory 404, to provide the functionality of the network node 400.

[0117] In some embodiments, the processing circuit 402 comprises a system-on-chip (SOC). In some embodiments, the processing circuit 402 includes one or more of a radio frequency (RF) transceiver circuit 412 and a baseband processing circuit 414. In some embodiments, the radio frequency (RF) transceiver circuit 412 and the baseband processing circuit 414 may be on separate chips (or chipsets), boards, or units, such as a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuit 412 and the baseband processing circuit 414 may be on the same chip or chipset, board, or unit.

[0118] The memory 404 can constitute any form of volatile or non-volatile computer-readable memory, including, but not limited to, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disc (CD) or digital video disc (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by the processing circuit 402. The memory 404 can store any suitable instructions, data, or information, including computer programs, software, applications including one or more of logic, rules, code, tables, and / or other instructions that can be executed by the processing circuit 402 and utilized by the network node 400. The memory 404 can be used to store any calculations performed by the processing circuit 402 and / or any data received via the communication interface 406. In some embodiments, the processing circuitry 402 and the memory 404 are integrated.

[0119] The communication interface 406 is used in wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, the communication interface 406 comprises port(s) / terminal(s) 416 for transmitting and receiving data to and from a network, e.g., via a wired connection. The communication interface 406 also includes a radio front-end circuit 418 that is coupled to an antenna 410 or, in certain embodiments, is part of the antenna 410. The radio front-end circuit 418 is comprised of a filter 420 and an amplifier 422. The radio front-end circuit 418 may be connected to the antenna 410 and the processing circuit 402. The radio front-end circuit may be configured to condition signals communicated between the antenna 410 and the processing circuit 402. The radio front-end circuit 418 can receive digital data to be transmitted to other network nodes or UEs via a wireless connection. The radio front-end circuit 418 can convert the digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of the filter 420 and / or amplifier 422. The radio signals are then transmitted via antenna 410. Similarly, when receiving data, antenna 410 can collect radio signals that are converted to digital data by radio front-end circuitry 418. The digital data is passed to processing circuitry 402. In other embodiments, the communication interface may be comprised of different components and / or different combinations of components.

[0120] In an alternative embodiment, network node 400 does not include a separate radio front-end circuit 418; instead, processing circuit 402 includes the radio front-end circuitry and is connected to antenna 410. Similarly, in some embodiments, all or a portion of RF transceiver circuitry 412 is part of communication interface 406. In yet other embodiments, communication interface 406 includes one or more ports or terminals 416, radio front-end circuitry 418, and RF transceiver circuitry 412 as part of a radio unit (not shown), and communication interface 406 communicates with baseband processing circuitry 414 that is part of a digital unit (not shown).

[0121] Antenna 410 may include one or more antennas or an antenna array configured to transmit and / or receive wireless signals. Antenna 410 may be coupled to radio front-end circuitry 418 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, antenna 410 is separate from network node 400 and connectable to network node 400 via an interface or port.

[0122] The antenna 410, the communication interface 406, and / or the processing circuit 402 may be configured to perform any receiving operation and / or certain acquisition operations described herein as being performed by a network node. Any information, data, and / or signals may be received from a UE, another network node, and / or any other network equipment. Similarly, the antenna 410, the communication interface 406, and / or the processing circuit 402 may be configured to perform any transmitting operation described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to a UE, another network node, and / or any other network equipment.

[0123] The power source 408 provides power to the various components of the network node 400 in a form appropriate for each component (e.g., at the voltage and current levels required by each component). The power source 408 may further comprise or be coupled to power management circuitry that provides power to the components of the network node 400 to perform the functions described herein. For example, the network node 400 may be connectable to an external power source (e.g., a power grid, an outlet) via an input circuit or interface such as an electrical cable, whereby the external power source provides power to the power circuitry of the power source 408. As a further example, the power source 408 may consist of a power source in the form of a battery or battery pack connected to or built into the power circuitry. The battery can provide backup power in the event that the external power source fails.

[0124] 4 to provide certain aspects of the network node's functionality, including any of the functionality described herein and / or functionality necessary to support the subject matter described herein. For example, network node 400 may include user interface devices that allow for the input of information into network node 400 and the output of information from network node 400, thereby enabling a user to perform diagnostic, maintenance, repair, and other management functions on network node 400.

[0125] 5 is a block diagram of a host 500, which may be an embodiment of the host 216 of FIG. 2, in accordance with various aspects described herein. As used herein, the host 500 may be or consist of various combinations of hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container, or processing resources in a server farm. The host 500 may provide one or more services to one or more UEs.

[0126] Host 500 includes a processing circuit 502 operably coupled to an input / output interface 506, a network interface 508, a power supply 510, and a memory 512 via a bus 504. In other embodiments, other components may be included. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 3 and 4, such that the descriptions are generally applicable to the corresponding components of host 500.

[0127] The memory 512 may include one or more computer programs, including one or more host application programs 514, and data 516, which may include user data, e.g., data generated by the UE for the host 500 or data generated by the host 500 for the UE. An embodiment of the host 500 may utilize only a subset or all of the illustrated components. The host application programs 514 may be implemented in a container-based architecture and provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AVC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UE (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 514 may also provide user authentication and license checking, and may periodically report health, route, and content availability to a central node, such as a device within or at the edge of the core network. Thus, the host 500 can select and / or direct different hosts for over-the-top services for the UE. The host application program 514 can support various protocols such as HTTP Live Streaming (HLS) protocol, Real Time Messaging Protocol (RTMP), Real Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0128] FIG. 6 is a block diagram illustrating a virtualization environment 600 in which functionality implemented by some embodiments may be virtualized. As used herein, virtualization refers to creating a virtual version of an apparatus or device, which may include virtualizing a hardware platform, storage devices, and networking resources. As used herein, virtualization may apply to any apparatus or component thereof described herein and refers to implementations in which at least a portion of functionality is implemented as one or more virtual components. Some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 600 hosted by one or more hardware nodes, such as a network node, a UE, a core network node, or a hardware computing device acting as a host. Additionally, in embodiments in which the virtualized node does not require wireless connectivity (e.g., a core network node or a host), the node may be fully virtualized.

[0129] An application 602 (alternatively referred to as a software instance, a virtual appliance, a network function, a virtual node, a virtual network function, etc.) executes in the virtualized environment Q400 to implement certain features, functions, and / or advantages of the embodiments disclosed herein.

[0130] The hardware 604 includes processing circuitry, memory that stores software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices as described herein, such as network interfaces, input / output interfaces, etc. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 606 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 608a and 608b (one or more of which may be generally referred to as VMs 608), and / or perform any of the functions, features, and / or advantages described in connection with some embodiments described herein. The virtualization layer 606 may present a virtual operating platform that appears to be network hardware to the VMs 608.

[0131] A VM 608 may consist of virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be executed by a corresponding virtualization layer 606. Different embodiments of an instance of a virtual appliance 602 may be implemented on one or more of the VMs 608, and the implementation may be done in different ways. Hardware virtualization is referred to in some contexts as network functions virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry-standard, high-capacity server hardware, physical switches, and physical storage that may be located in a data center or on customer premises equipment.

[0132] In the context of NFV, a VM 608 may be a software implementation of a physical machine that executes programs as if they were running on a physical, non-virtualized machine. Each VM 608 and that portion of the hardware 604 on which it runs (hardware dedicated to that VM and / or hardware that it shares with other VMs) forms a separate virtual network element. Still in the context of NFV, a virtual network function runs in one or more VMs 608 on top of the hardware 604 and is responsible for handling specific network functions corresponding to applications 602.

[0133] The hardware 604 may be implemented in a standalone network node with generic or specific components. The hardware 604 may implement some functions via virtualization. Alternatively, the hardware 604 may be part of a larger cluster of hardware (e.g., in a data center or CPE) where many hardware nodes cooperate and are managed via a management and orchestration 610 that oversees, among other things, the lifecycle management of the application 602. In some embodiments, the hardware 604 is coupled to one or more radio units, each including one or more receivers that may be coupled to one or more transmitters and one or more antennas. The radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces or may be used in combination with virtual components to provide a virtual node with radio functionality, such as a radio access node or base station. In some embodiments, some signaling may be provided using a control system 612, which may alternatively be used for communication between the hardware nodes and the radio units.

[0134] 7 illustrates a communication diagram of a host 702 communicating with a UE 706 via a network node 704 over a partial wireless connection, according to some embodiments. Exemplary implementations of the UE (such as the UE 212a of FIG. 2 and / or the UE 300 of FIG. 3), network node (such as the network node 210a of FIG. 2 and / or the network node 400 of FIG. 4), and host (such as the host 216 of FIG. 2 and / or the host 500 of FIG. 5) described in the previous paragraphs, according to various embodiments, will now be described with reference to FIG.

[0135] Similar to host 500, an embodiment of host 702 includes hardware such as a communications interface, processing circuitry, and memory. Host 702 also includes software stored on or accessible by host 702 and executable by the processing circuitry. The software includes a host application operable to provide services to a remote user, such as a UE 706, connecting via an over-the-top (OTT) connection 750 extending between the UE 706 and host 702. In providing services to the remote user, the host application can provide user data that is transmitted using the OTT connection 750.

[0136] The network node 704 includes hardware that enables communication with the host 702 and the UE 706. The connection 760 may be direct or may pass through a core network (such as core network 206 of FIG. 2) and / or one or more other intermediate networks (such as one or more public, private, or hosted networks). For example, the intermediate network may be a backbone network or the Internet.

[0137] The UE 706 includes hardware and software that is stored on or accessible by the UE 706 and executable by the UE's processing circuitry. The software may include client applications, such as a web browser or operator-specific "apps," operable to provide services to a human or non-human user via the UE 706 with the support of the host 702. An executing host application in the host 702 can communicate with an executing client application via an OTT connection 750 that terminates at the UE 706 and the host 702. In providing a service to a user, the client application in the UE can receive request data from the host application in the host and provide user data in response to the request data. The OTT connection 750 can transfer both request data and user data. The client application in the UE can interact with the user to generate user data to provide to the host application via the OTT connection 750.

[0138] The OTT connection 750 may extend via a connection 760 between the host 702 and a network node 704 and via a wireless connection 770 between the network node 704 and the UE 706 to provide connectivity between the host 702 and the UE 706. The connections 760 and wireless connections 770 over which the OTT connection 750 may be provided are depicted abstractly to illustrate communication between the host 702 and the UE 706 via the network node 704, without explicit reference to intermediary devices and the precise routing of messages through these devices.

[0139] As an example of transmitting data over the OTT connection 750, in step 708, the host 702 provides user data that may be executed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 706. In other embodiments, the user data is associated with the UE 706, which shares data with the host 702 without explicit human interaction. In step 710, the host 702 initiates a transmission carrying user data toward the UE 706. The host 702 may initiate the transmission in response to a request sent by the UE 706. The request may be triggered by human interaction with the UE 706 or by the operation of a client application running on the UE 706. The transmission may be routed through the network node 704 in accordance with the teachings of the embodiments described throughout this disclosure. Thus, in step 712, the network node 704 transmits the user data carried in the host 702-initiated transmission to the UE 706 in accordance with the teachings of the embodiments described throughout this disclosure. In step 714 , the UE 706 receives the user data carried in the transmission, which may be executed by a client application running on the UE 706 associated with the host application executed by the host 702 .

[0140] In some examples, the UE 706 executes a client application that provides user data to the host 702. The user data may be provided in reaction or response to data received from the host 702. Thus, in step 716, the UE 706 can provide the user data, which can be executed by executing the client application. In providing the user data, the client application can further consider user input received from a user via an input / output interface of the UE 706. Regardless of the particular manner in which the user data is provided, the UE 706, in step 718, initiates transmission of the user data toward the host 702 via the network node 704. In step 720, in accordance with the teachings of embodiments described throughout this disclosure, the network node 704 receives the user data from the UE 706 and initiates transmission of the received user data toward the host 702. In step 722, the host 702 receives the user data carried in the transmission initiated by the UE 706.

[0141] One or more of the various embodiments improve the performance of the OTT service provided to the UE 706 using the OTT connection 750, of which the wireless connection 770 forms the final segment. More precisely, the teachings of these embodiments may improve, for example, one or more of data rate, latency, and / or power consumption, thereby providing benefits such as, for example, reduced user latency, relaxed file size limitations, improved content resolution, improved responsiveness, and / or extended battery life.

[0142] In one example scenario, factory status information may be collected and analyzed by the host 702. As another example, the host 702 may process audio and video data, possibly obtained from UEs, for use in creating maps. As another example, the host 702 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic signals). As another example, the host 702 may store surveillance video uploaded by UEs. As another example, the host 702 may store or control access to media content, such as video, audio, VR, or AR, that may be broadcast, multicast, or unicast to UEs. As another example, the host 702 may be used for energy pricing, remote control of non-timed electrical loads to balance power generation needs, location services, presentation services (such as compiling diagrams, etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing, and / or transmitting data.

[0143] In some examples, measurement procedures may be provided for the purpose of monitoring data rates, latency, and other factors that one or more embodiments improve. There may further be optional network functionality for reconfiguring the OTT connection 750 between the host 702 and the UE 706 in response to fluctuations in the measurement results. The measurement procedures and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 702 and / or the UE 706. In some embodiments, sensors (not shown) may be deployed in or associated with other devices through which the OTT connection 750 passes; the sensors may participate in the measurement procedures by providing values ​​of the monitored quantities exemplified above or other physical quantities from which software can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 750 may include message formats, retransmission settings, priority routing, etc.; reconfiguration need not directly change the operation of the network node 704. Such procedures and functionality are known and may be implemented in the art. In particular embodiments, the measurements may include proprietary UE signaling that facilitates measurements of throughput, propagation time, latency, etc. by the host 702. Measurements can be performed by having the software send messages, particularly empty or "dummy" messages, using the OTT connection 750 while monitoring propagation times, errors, and the like.

[0144] 8 illustrates a method 800 by wireless devices 212A-D for reporting information related to an on-demand SI / SIB request, according to a particular embodiment. The method includes, at step 802, transmitting information related to the on-demand SI / SIB request to network nodes 210A-B. The information indicates that the on-demand SI request was successful or that the on-demand SI request was not successful.

[0145] In a particular embodiment, the information includes an indication of at least one SIB requested by the wireless device 212A-D.

[0146] In a particular embodiment, the information indicates whether the wireless device received at least one SIB requested by the wireless device 212A-D.

[0147] In particular embodiments, the information indicates at least one of the following: whether an acknowledgment for the SI request was received from a lower layer, that an acknowledgment for the SI request was not received from a lower layer, that an acknowledgment for the SI request was received from a lower layer, whether acquisition of at least one SI message failed while an acknowledgment for the SI request was received from a lower layer, an indication that the wireless devices 212A-D received only a portion of at least one SI message requested by the wireless devices 212A-D, an indication of whether the wireless devices 212A-D examined the SI window for at least one SI message; an indication of how many SI window opportunities the wireless device 212A-D monitored for at least one SI message; an indication of how many attempts the wireless device 212A-D made to receive at least one SI message; the number of HARQ retransmissions the wireless device 212A-D made when sending an RRC message to request at least one SI message; an indication of whether the wireless device 212A-D received an acknowledgment from a lower layer HARQ procedure; location information of the wireless device 212A-D at the time the wireless device 212A-D sent the on-demand SI request; and a cell identifier of the cell in which the on-demand SI request is executed.

[0148] In particular embodiments, the wireless devices 212A-D log information while performing the SI request procedures associated with sending on-demand SI requests.

[0149] In certain embodiments, the information is transmitted in an RA report or a RACH report.

[0150] In certain embodiments, the RA report or the RACH report includes at least one RSRP measurement and / or path loss measurement.

[0151] In certain embodiments, the information is sent in reports dedicated to on-demand SI requests.

[0152] In a particular embodiment, the wireless devices 212A-D are user equipment.

[0153] 9 illustrates a method by network nodes 210A-B for processing information related to an on-demand SI / SIB request, according to a particular embodiment. The method includes receiving information related to an on-demand SI request of a wireless device 212A-D, in step 902. The information indicates that the on-demand SI request was successful or that the on-demand SI request was not successful.

[0154] In a particular embodiment, the information includes an indication of at least one SIB requested by the wireless device 212A-D.

[0155] In a particular embodiment, the information indicates whether the wireless device 212A-D received at least one SIB that the wireless device 212A-D requested.

[0156] In particular embodiments, the information indicates at least one of the following: whether an acknowledgment for the SI request was received from a lower layer; that an acknowledgment for the SI request was not received from a lower layer; that an acknowledgment for the SI request was received from a lower layer; whether acquisition of at least one SI message failed while an acknowledgment for the SI request was received from a lower layer; an indication that the wireless devices 212A-D received only a portion of the at least one SI message requested by the wireless devices 212A-D; an indication of whether the wireless devices 212A-D examined the SI window of the at least one SI message; - an indication of how many SI window opportunities the wireless device 212A-D monitored for at least one SI message; an indication of how many attempts the wireless device 212A-D made to receive at least one SI message; the number of HARQ retransmissions the wireless device 212A-D made when sending an RRC message to request at least one SI message; an indication of whether the wireless device 212A-D received an acknowledgment from a lower layer HARQ procedure; location information of the wireless device 212A-D at the time the wireless device 212A-D sent the on-demand SI request; and a cell identifier of the cell in which the on-demand SI request is executed.

[0157] In a particular embodiment, information is logged by the wireless devices 212A-D while performing an SI request procedure related to sending an on-demand SI request.

[0158] In a particular embodiment, the information is received in an RA report or a RACH report.

[0159] In certain embodiments, the RA report or the RACH report includes at least one RSRP measurement and / or path loss measurement.

[0160] In certain embodiments, the information is received in reports dedicated to on-demand SI requests.

[0161] In certain embodiments, the network nodes 210A-B constitute radio access nodes, and the method further includes forwarding the information to at least an O&M node.

[0162] In particular embodiments, the network nodes 210A-B constitute O&M nodes, and the information is received via radio access network nodes that communicate with the wireless devices 212A-D.

[0163] In certain embodiments, the network nodes 210A-B optimize, adapt, adjust, modify, or change a configuration for transmitting at least one SI message based on the information.

[0164] In certain embodiments, when optimizing, adapting, adjusting, modifying, or changing a configuration for transmitting at least one SI message based on the information, network node 210A-B performs at least one of the following: changing how multiple SIBs are grouped into different SI messages, changing whether at least one SI message is broadcast, changing the amount of PRACH resources dedicated for subsequent on-demand SI requests, changing an RA-related configuration associated with at least one subsequent on-demand SI request, changing a mapping between at least one RA preamble and at least one subsequent SI message in Msg1. and changing from an Msg1-based SI request to an Msg3-based SI request; changing whether at least one SI message is available via Msg1 or Msg3, changing the number of times subsequent SI messages are broadcast, changing the time slot for broadcasting subsequent SI messages, changing the scheduling periodicity of subsequent SI messages, changing the number of times SI messages are transmitted within an associated SI window, changing at least one beam in which the requested SI message is transmitted, changing the mapping between at least one SIB and at least one SI message, and changing the length of the SI window.

[0165] While the computing devices (e.g., UEs, network nodes, hosts) described herein may include combinations of the illustrated hardware components, other embodiments may include computing devices having different combinations of components. It should be understood that these computing devices may be configured with any suitable combination of hardware and / or software necessary to perform the tasks, features, functions, and methods disclosed herein. The determining, calculating, obtaining, or similar operations described herein may be performed by processing circuitry, which may process information by, for example, transforming the obtained information into other information, comparing the obtained or transformed information with information stored in a network node, and / or performing one or more operations based on the obtained or transformed information, and making a decision as a result of said processing. Furthermore, while components are depicted as a single box arranged within a larger box or as boxes nested within multiple boxes, in reality, a computing device may be composed of multiple different physical components that make up a single illustrated component, and functionality may be divided among the separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of a component may be divided between a processing circuit and a communication interface. In another example, the non-computationally intensive functions of any of such components may be implemented in software or firmware, while the computationally intensive functions may be implemented in hardware.

[0166] In particular embodiments, some or all of the functionality described herein may be provided by a processing circuit executing instructions stored in a memory, which in particular embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by a processing circuit without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner. In any of these particular embodiments, the processing circuit may be configured to perform the described functionality regardless of whether it executes instructions stored on a non-transitory computer-readable storage medium. Benefits provided by such functionality are not limited to just the processing circuit or to other components of the computing device, but are enjoyed by the computing device as a whole and / or by end users and wireless networks in general.

[0167] Example embodiment Group A Exemplary Embodiments Exemplary Embodiment A1. A method by a wireless device for recording fault information for an on-demand system information request procedure includes any of the steps, features, or functions of the wireless device described above, alone or in combination with other steps, features, or functions described above. Exemplary Embodiment A2. The method of any of the preceding embodiments, further including one or more additional wireless device steps, features, or functions described above. Exemplary Embodiment A3. A method according to any of the preceding embodiments, further comprising providing user data and transferring the user data to the host computer via transmission to a network node.

[0168] Group B Exemplary Embodiments Exemplary Embodiment B1. A method performed by a network node for processing recorded fault information for an on-demand system information request procedure, the method including any of the steps, features, or functions of the network node described above, either alone or in combination with other steps, features, or functions described above. Exemplary Embodiment B2. The method of any of the preceding embodiments, further comprising one or more additional network node steps, features, or functions as described above. Exemplary Embodiment B3. A method according to any of the preceding embodiments, further comprising obtaining user data and transferring the user data to a host or user device.

[0169] Group C Exemplary Embodiments Exemplary Embodiment C1. A method by a wireless device (e.g., a user equipment (UE), etc.) for recording failure information for an on-demand system information request procedure includes transmitting information related to an on-demand system information (SI) request to a network node. Exemplary embodiment C2. The information includes whether the on-demand SI request was successful; that the on-demand SI request was successful; that the on-demand SI request was not successful; whether an acknowledgment for the SI request was received from a lower layer (i.e., PHY, MAC, or RLC layer); that an acknowledgment for the SI request was not received from a lower layer; that an acknowledgment for the SI request was received from a lower layer; whether at least one SI message was unsuccessful while an acknowledgment for the SI request was received from a lower layer; an indication that the wireless device received only a portion of a requested system information block (SIB); an indication of whether the wireless device checked the SI window for at least one SI message before transmitting a preamble; at least one The method of exemplary embodiment C1, which indicates at least one of: an indication of the number of SI window opportunities monitored by the wireless device for SI messages; an indication of the number of attempts made by the wireless device to receive at least one SI message; the number of hybrid automatic repeat request (HARQ) retransmissions made by the wireless device when sending a radio resource control (RRC) message to request at least one SI message; an indication of whether the wireless device has received an acknowledgment from a HARQ procedure at a lower layer; an indication of whether the wireless device has received an acknowledgment from a radio link control (RLC) lower layer; location information of the wireless device when the wireless device initiated the on-demand SI request; and a cell identifier of the cell from which the on-demand SI request was made. Exemplary Embodiment C3. The method of any of Exemplary Embodiments C1-C2, wherein the on-demand SI request includes an on-demand system information block (SIB) request. Exemplary Embodiment C4. The method of any of Exemplary Embodiments C1-C3, further comprising recording information while performing an SI procedure associated with the on-demand SI request. Exemplary Embodiment C5. The method of any of exemplary embodiments C1-C4, wherein the information is transmitted in a random access report or a random access channel report. Exemplary Embodiment C6. The method of any of Exemplary Embodiments C1-C4, wherein the information is sent in a report dedicated to an on-demand SI request. Exemplary Embodiment C7. The method of any of Exemplary Embodiments C1-C6, wherein the information further includes at least one signal strength measurement associated with a synchronization signal block beam that provides coverage to the wireless device when acquiring the SI. Exemplary Embodiment C8. The method of exemplary embodiment C7, wherein the at least one signal strength measurement includes at least one of an RSRP measurement, an RSRQ measurement, an SINR measurement, an SNR measurement, an RSSI measurement, and a path loss measurement. Exemplary Embodiment C9. The method of any of Exemplary Embodiments C1-C8, further comprising: prior to transmitting the information to the network node, transmitting an indication to the network node that the information is available; and receiving a request for the information from the network node, wherein the information is transmitted to the network node in response to the request. Exemplary Embodiment C10. The method of any of Exemplary Embodiments C1-C9, wherein the wireless device is a user equipment. Exemplary Embodiment C11. The method of any of Exemplary Embodiments C1-C10, further comprising providing user data and forwarding the user data to the host via transmission to the network node. Exemplary Embodiment C12. A wireless device comprising processing circuitry configured to perform the method of any of exemplary embodiments C1-C12. Exemplary Embodiment C13. A wireless device comprising a processing circuit configured to perform the method of any of exemplary embodiments C1-C12. Exemplary Embodiment C14. A computer program comprising instructions that, when executed on a computer, perform the method of any of the exemplary embodiments C1-C12. Exemplary Embodiment C15. A computer program product including a computer program, the computer program including instructions for performing the method of any of the exemplary embodiments C1-C12 when the computer program is executed on a computer. Exemplary Embodiment C16. A non-transitory computer-readable medium storing instructions that, when executed by a computer, perform the method of any of Exemplary Embodiments C1-C12.

[0170] Group D Exemplary Embodiments Exemplary Embodiment D1. A method by a network node for processing fault information recorded for an on-demand system information request procedure includes receiving information related to an on-demand system information (SI) request from a wireless device. Exemplary embodiment D2. The information includes whether the on-demand SI request was successful; that the on-demand SI request was successful; that the on-demand SI request was not successful; whether an acknowledgment for the SI request was received from a lower layer (i.e., PHY, MAC, or RLC layer); that an acknowledgment for the SI request was not received from a lower layer; that an acknowledgment for the SI request was received from a lower layer; whether at least one SI message was not obtained while an acknowledgment for the SI request was received from a lower layer; an indication that the wireless device received only a portion of a requested system information block (SIB); an indication of whether the wireless device checked the SI window for at least one SI message before transmitting a preamble; at least one The method of exemplary embodiment D1, which indicates at least one of: an indication of the number of SI window opportunities monitored by the wireless device for SI messages; an indication of the number of attempts made by the wireless device to receive at least one SI message; the number of hybrid automatic repeat request (HARQ) retransmissions made by the wireless device when sending a radio resource control (RRC) message to request at least one SI message; an indication of whether the wireless device has received an acknowledgment from a HARQ procedure at a lower layer; an indication of whether the wireless device has received an acknowledgment from a radio link control (RLC) lower layer; location information of the wireless device when the wireless device initiated the on-demand SI request; and a cell identifier of the cell from which the on-demand SI request was made. Exemplary Embodiment D3. The method of any of Exemplary Embodiments D1-D2, wherein the on-demand SI request includes an on-demand system information block (SIB) request. Exemplary Embodiment D4. The method of any of Exemplary Embodiments D1-D3, wherein the information is recorded by the wireless device while performing an SI procedure associated with an on-demand SI request. Exemplary Embodiment D5. The method of any of exemplary embodiments D1-D4, wherein the information is received in a random access report or a random access channel report. Exemplary Embodiment D6. The method of any of exemplary embodiments D1-D4, wherein the information is received in a report dedicated to the on-demand SI request. Exemplary Embodiment D7. The method of any of Exemplary Embodiments D1-D6, wherein the information further includes at least one signal strength measurement associated with a synchronization signal block beam that provides coverage to the wireless device when acquiring the SI. Exemplary Embodiment D8. The method of exemplary embodiment D7, wherein the at least one signal strength measurement includes at least one of an RSRP measurement, an RSRQ measurement, an SINR measurement, an SNR measurement, an RSSI measurement, and a path loss measurement. Exemplary Embodiment D9 The method of any of Exemplary Embodiments D1-D8, further including, prior to receiving the information, receiving an indication from the wireless device that the information is available and sending a request for the information to the wireless device, wherein the information is received by the network node in response to the request. Exemplary Embodiment D10. The method of any of Exemplary Embodiments D1-D9, further comprising forwarding the information to at least one other network node. Exemplary Embodiment D11. The method of any of Exemplary Embodiments D1-D10, further comprising optimizing, adapting, adjusting, modifying, or changing the configuration of at least one SI transmission based on the information. Exemplary embodiment D12. The method described in exemplary embodiment D11, wherein optimizing, adapting, adjusting, modifying, or changing a configuration for at least one SI transmission based on the information includes at least one of: changing how SIBs are grouped into different SI messages; changing whether SIB / SI messages are broadcast; changing the amount of PRACH resources dedicated for SI requests, changing an RA-related configuration associated with at least one SI request; changing the mapping of random access preambles to SI messages for Msg1; changing from Msg1-based to Msg3-based SI requests; changing the SI messages available via Msg1 and / or the SI messages available via Msg3; changing the number of times or period for broadcasting SI messages; changing the scheduling periodicity of on-demand SI messages; changing the number of times on-demand SI messages are transmitted within the associated SI window; changing the beam in which the requested SI message is transmitted; changing the mapping of SIBs and SI messages; and changing the length of the SI window. Exemplary Embodiment D13. The method of any of Exemplary Embodiments D1-D, wherein the wireless device is a user equipment. Exemplary Embodiment D14. The method of any of exemplary embodiments D1-D13, wherein the network node includes a gNodeB (gNB). Exemplary Embodiment D15. The method of any of Exemplary Embodiments D1-D14, further comprising obtaining user data and transferring the user data to a host or user device. Exemplary Embodiment D16. A network node comprising processing circuitry configured to perform the method of any of exemplary embodiments D1-D15. Exemplary Embodiment D17. A computer program comprising instructions that, when executed on a computer, perform the method of any of the exemplary embodiments D1-D15. Exemplary Embodiment D18. A computer program product including a computer program, the computer program including instructions for performing the method of any of the exemplary embodiments D1-D15 when the computer program is executed on a computer. Exemplary Embodiment D19. A non-transitory computer-readable medium storing instructions that, when executed by a computer, perform the method of any of exemplary embodiments D1-D15.

[0171] Group E Exemplary Embodiments Exemplary Embodiment E1. A user equipment (UE) for recording fault information for an on-demand system information request procedure, comprising: a processing circuit configured to perform the steps of any of the exemplary embodiments of groups A and C; and a power supply circuit configured to supply power to the processing circuit. Exemplary embodiment E2. A network node for processing recorded fault information for an on-demand system information request procedure, comprising a processing circuit configured to perform the steps of any of the exemplary embodiments of groups B and D, and a power supply circuit configured to supply power to the processing circuit. Exemplary Embodiment E3. A user equipment (UE) for recording fault information for an on-demand system information request procedure, comprising: an antenna configured to transmit and receive radio signals; a radio front-end circuit connected to the antenna and the processing circuit and configured to condition signals communicated between the antenna and the processing circuit; a processing circuit configured to perform the steps of any of the exemplary embodiments of Groups A and C; an input interface connected to the processing circuit and configured to enable input of information to the UE to be processed by the processing circuit; an output interface connected to the processing circuit and configured to output information from the UE processed by the processing circuit; and a battery connected to the processing circuit and configured to provide power to the UE. Exemplary Embodiment E4. A host configured to operate in a communication system to provide over-the-top (OTT) services, comprising: a processing circuit configured to provide user data; and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE), the UE comprising a communication interface and a processing circuit, the communication interface and processing circuit of the UE configured to perform the steps of any of the exemplary embodiments of groups A and C to receive the user data from the host. Exemplary Embodiment E5. The host of the preceding exemplary embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit user data from the host to the UE. Exemplary Embodiment E6. The host of the preceding two exemplary embodiments, wherein the processing circuitry of the host is configured to execute a host application to provide user data, and the host application is configured to interact with a client application running on the UE, the client application being associated with the host application. Exemplary Embodiment E7. A method implemented by a host operating in a communication system further including a network node and a user equipment (UE), comprising: providing user data to the UE; and initiating a transmission conveying the user data to the UE via a cellular network including the network node, wherein the UE performs the operations of any of the exemplary embodiments of Group A to receive the user data from the host. Exemplary Embodiment E8. The method of the preceding exemplary embodiment, further including executing, at the host, a host application associated with the client application running on the UE to receive user data from the UE. Exemplary Embodiment E9. The method of the preceding exemplary embodiment, further including transmitting, at the host, input data to a client application executing on the UE, the input data being provided by executing the host application, and the user data being provided by the client application in response to the input data from the host application. Exemplary Embodiment E10. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising processing circuitry configured to provide user data and a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE), the UE comprising a communication interface and processing circuitry, the communication interface and processing circuitry of the UE configured to perform the steps of any of the exemplary embodiments of groups A and C to transmit the user data to the host. Exemplary Embodiment E11. The host of the preceding exemplary embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to transmit user data from the UE to the host. Exemplary Embodiment E12. The host of the preceding two exemplary embodiments, wherein the processing circuitry of the host is configured to execute a host application, thereby providing user data, and the host application is configured to interact with a client application running on the UE, the client application being associated with the host application. Exemplary Embodiment E13. A method implemented by a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising receiving, at the host, user data transmitted by the UE via the network node to the host, wherein the UE performs the steps of any of the exemplary embodiments of groups A and C to transmit the user data to the host. Exemplary Embodiment E14. The method of the preceding exemplary embodiment, further including executing, at the host, a host application associated with the client application running on the UE to receive user data from the UE. Exemplary Embodiment E15. The method of the preceding exemplary embodiment, further including transmitting, at the host, input data to a client application executing on the UE, the input data being provided by executing the host application, and the user data being provided by the client application in response to the input data from the host application. Exemplary Embodiment E16. A host configured to operate in a communications system to provide over-the-top (OTT) services, comprising: a processing circuit configured to provide user data; and a network interface configured to initiate transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communications interface and a processing circuit, the processing circuit of the network node configured to perform the operations of any of the exemplary embodiments of groups B and D to transmit the user data from the host to the UE. Exemplary Embodiment E17. The host of the preceding exemplary embodiment, wherein the processing circuitry of the host is configured to execute a host application that provides user data, and the UE comprises processing circuitry configured to execute a client application associated with the host application to receive transmissions of the user data from the host. Exemplary Embodiment E18. A method implemented in a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising: providing user data to the UE; and initiating a transmission carrying the user data to the UE via a cellular network including the network node, wherein the network node performs the operations of any of the exemplary embodiments of groups B and D to transmit the user data from the host to the UE. Exemplary Embodiment E19. The method of the preceding exemplary embodiment, further comprising, at the network node, transmitting user data provided by the host for the UE. Exemplary Embodiment E20. The method of the preceding two exemplary embodiments, wherein user data is provided at the host by executing a host application that interacts with a client application running on the UE, and the client application is associated with the host application. Exemplary Embodiment E21. A communications system configured to provide over-the-top services, comprising: a host comprising processing circuitry configured to provide user data to a user equipment (UE), the user data relating to the over-the-top services; and a network interface configured to initiate transmission of the user data towards a cellular network node for transmission to the UE, the network node comprising a communications interface and processing circuitry, the processing circuitry of the network node being configured to perform the operations of any of the exemplary embodiments of groups B and D to transmit the user data from the host to the UE. Exemplary Embodiment E22. The communication system of the preceding exemplary embodiment, further comprising a network node and / or a user device. Exemplary Embodiment E23. A host configured to operate in a communication system to provide over-the-top (OTT) services, the host comprising: a processing circuit configured to initiate reception of user data; and a network interface configured to receive the user data from a network node in a cellular network, the network node having a communication interface and a processing circuit, the processing circuit of the network node configured to perform the operations of any of the example embodiments of Groups B and D to receive the user data from a user equipment (UE) of the host. Exemplary Embodiment E24. The host of the preceding exemplary embodiment, wherein the processing circuitry of the host is configured to execute a host application, thereby providing user data, and the host application is configured to interact with a client application running on the UE, the client application being associated with the host application. Exemplary Embodiment E25. The host of any preceding two exemplary embodiments, wherein initiating reception of user data includes requesting the user data. Exemplary Embodiment E26. A method implemented by a host configured to operate in a communication system further including a network node and a user equipment (UE), comprising initiating, at the host, reception of user data from the UE, the user data originating from a transmission received by the network node from the UE, wherein the network node performs the steps of any of the exemplary embodiments of groups B and D to receive the user data from the UE for the host. Exemplary Embodiment E27. The method of the preceding exemplary embodiment, further comprising, at the network node, transmitting the received user data to the host.

Claims

1. 1. A method by a wireless device for reporting information associated with an on-demand system information (SI) request, the method comprising: transmitting, to a network node, information associated with the on-demand SI request, the information indicating that the on-demand SI request was successful or that the on-demand SI request was unsuccessful. Including, The information is whether or not at least one SI message has failed to be acquired while an acknowledgment to the SI request has been received from a lower layer; an indication that the wireless device has received only a portion of the at least one SI message requested by the wireless device; an indication of whether the wireless device has checked an SI window for the at least one SI message; an indication of a number of SI window opportunities monitored by the wireless device for the at least one SI message; a number of hybrid automatic repeat request (HARQ) retransmissions performed by the wireless device when transmitting a radio resource control (RRC) message to request the at least one SI message; an indication of whether the wireless device has received an acknowledgment from a HARQ procedure at a lower layer; A cell identifier of the cell from which the on-demand SI request was made; At least one of the following is shown: method.

2. The information includes an indication of at least one system information block (SIB) requested by the wireless device. The method of claim 1.

3. The information indicates whether the wireless device received the at least one SIB requested by the wireless device. The method of claim 2.

4. and logging the information while performing an SI request procedure associated with sending the on-demand SI request. The method of claim 1.

5. The information is transmitted in a Random Access (RA) report or a Random Access Channel (RACH) report. The method of claim 1.

6. The RA report or the RACH report includes at least one RSRP measurement and / or path loss measurement. The method according to claim 5.

7. 1. A method by a network node for processing information associated with an on-demand system information (SI) request, the method comprising: receiving information associated with the on-demand SI request at a wireless device, the information indicating that the on-demand SI request was successful or that the on-demand SI request was unsuccessful; Including, The information is whether or not at least one SI message has failed to be acquired while an acknowledgment to the SI request has been received from a lower layer; an indication that the wireless device has received only a portion of the at least one SI message requested by the wireless device; an indication of whether the wireless device has checked an SI window for the at least one SI message; an indication of a number of SI window opportunities monitored by the wireless device for the at least one SI message; a number of hybrid automatic repeat request (HARQ) retransmissions performed by the wireless device when transmitting a radio resource control (RRC) message to request the at least one SI message; an indication of whether the wireless device has received an acknowledgment from a HARQ procedure at a lower layer; A cell identifier of the cell from which the on-demand SI request was made; At least one of the following is shown: method.

8. The information includes an indication of at least one system information block (SIB) requested by the wireless device. The method of claim 7.

9. The information indicates whether the wireless device received the at least one SIB requested by the wireless device. The method according to claim 8.

10. The information is logged by the wireless device while performing an SI request procedure associated with transmitting the on-demand SI request. The method of claim 7.

11. The information is received in a Random Access (RA) report or a Random Access Channel (RACH) report. The method of claim 7.

12. The RA report or the RACH report includes at least one RSRP measurement and / or path loss measurement. The method of claim 11.

13. and optimizing, adapting, adjusting, modifying or changing a configuration for transmitting at least one SI message based on said information. The method according to claim 7.

14. optimizing, adapting, adjusting, modifying or changing the configuration for transmitting the at least one SI message based on the information, Varying how SIBs are grouped into different SI messages; Changing whether the at least one SI message is broadcast; Modifying the amount of physical random access channel (PRACH) resources dedicated to subsequent on-demand SI requests; modifying an RA-related configuration associated with at least one subsequent on-demand SI request; modifying the mapping of at least one RA preamble and at least one subsequent SI message to Msg1; Changing from Msg1 based SI requests to Msg3 based SI requests; Changing whether at least one SI message is available via Msg1 or Msg3; Changing the number of times subsequent SI messages are broadcast; Changing the time period for broadcasting subsequent SI messages; Changing the scheduling period of subsequent SI messages; Changing the number of times an SI message is transmitted within an associated SI window; modifying at least one beam over which the requested SI message is transmitted; modifying a mapping between at least one SIB and at least one SI message; Varying the length of the SI window; Contains at least one of The method of claim 13.

15. 1. A wireless device for reporting information associated with an on-demand system information (SI) request, the wireless device comprising: and adapted to transmit to a network node information associated with the on-demand SI request, the information indicating whether the on-demand SI request was successful; The information is whether or not at least one SI message has failed to be acquired while an acknowledgment to the SI request has been received from a lower layer; an indication that the wireless device has received only a portion of the at least one SI message requested by the wireless device; an indication of whether the wireless device has checked an SI window for the at least one SI message; an indication of a number of SI window opportunities monitored by the wireless device for the at least one SI message; a number of hybrid automatic repeat request (HARQ) retransmissions performed by the wireless device when transmitting a radio resource control (RRC) message to request the at least one SI message; an indication of whether the wireless device has received an acknowledgment from a HARQ procedure at a lower layer; A cell identifier of the cell from which the on-demand SI request was made; At least one of the following is shown: Wireless devices.

16. Further configured to carry out the method according to any one of claims 2 to 6.

16. The wireless device of claim 15.

17. 1. A network node for processing information associated with an on-demand system information (SI) request, the network node comprising: and adapted to receive information associated with the on-demand SI request of a wireless device, the information indicating that the on-demand SI request was successful or that the on-demand SI request was unsuccessful; The information is whether or not at least one SI message has failed to be acquired while an acknowledgment to the SI request has been received from a lower layer; an indication that the wireless device has received only a portion of the at least one SI message requested by the wireless device; an indication of whether the wireless device has checked an SI window for the at least one SI message; an indication of a number of SI window opportunities monitored by the wireless device for the at least one SI message; a number of hybrid automatic repeat request (HARQ) retransmissions performed by the wireless device when transmitting a radio resource control (RRC) message to request the at least one SI message; an indication of whether the wireless device has received an acknowledgment from a HARQ procedure at a lower layer; A cell identifier of the cell from which the on-demand SI request was made; At least one of the following is shown: Network node.

18. Further configured to carry out the method according to any one of claims 8 to 14.

18. A network node according to claim 17.

Images