Network management apparatus, device and method

Abstract

Various aspects of the present disclosure provide network management apparatuses, devices, and methods in various network systems to reduce power consumption of network-side apparatuses and / or devices. A network device can receive configuration information from a serving cell, the configuration information being used to configure the network device to determine whether to transmit a report indicating that a traffic event has occurred. The network device can determine, based on the configuration information, whether one or more conditions indicating that the traffic event has occurred are satisfied. When the one or more conditions indicating that the traffic event has occurred are satisfied, the network device can transmit the report to the serving cell.

Description

Technical Field

[0001] This disclosure generally relates to wireless communications, and more particularly to network management devices, apparatus, and methods. Background Technology

[0002] In wireless communication systems such as 4G (Fourth Generation) Long-Term Evolution (LTE) and 5G (Fifth Generation) New Radio (NR), power saving or power management functions have been implemented at the user equipment (UE) level. For example, discontinuous reception (DRX) and discontinuous transmission (DTX) are used to achieve power saving or power management in UEs to extend their battery life.

[0003] However, for network-side devices (such as transmission and receive points, TRPs), there are currently no standard functions equivalent to DRX or DTX modes. Therefore, energy saving or power management is typically not implemented on network-side devices. In fact, energy saving or power management is not a primary consideration for network-side devices in wireless communication systems.

[0004] However, energy conservation or power management on the network side is receiving increasing attention due to the growing need for carbon neutrality in many countries, especially those experiencing rising energy costs. Given that many countries have made carbon neutrality commitments, numerous network operators now need to implement energy conservation or power management on the network side. According to a recent report by the Global System for Mobile Communications Association (GSMA), the energy consumption of the radio access network (RAN) accounts for approximately [percentage missing] of network operators' operational expenditure (OPEX). .

[0005] Therefore, there is an urgent need for new network management devices and methods applicable to various communication networks (such as Sixth Generation (6G)), especially those involving energy saving and / or power management of network-side equipment. Summary of the Invention

[0006] In wireless communication systems such as 4G Long-Term Evolution (LTE) and 5G New Radio (NR), discontinuous reception (DRX) and discontinuous transmission (DTX) are used to achieve energy saving or power management for user equipment (UE). However, there are currently no standards for energy saving or power management for network-side equipment. Existing network-side energy saving and management methods are only applicable to one or more specific networks. Unfortunately, such network-specific energy saving and management schemes are difficult to manage, maintain, or scale, and therefore not ideal. Instead, a standardized energy saving and / or network management approach may be needed. Compared to network-specific energy saving and management, standardized energy saving and / or network management methods are likely easier to manage, maintain, or scale.

[0007] Various aspects of this disclosure provide methods, apparatus, systems, and devices for overcoming the aforementioned deficiencies, as well as specific network management methods applicable to various network systems.

[0008] According to one aspect of this disclosure, a network management method is provided. The method includes: a first network device receiving configuration information from a second network device, wherein the configuration information is used to configure the first network device to determine whether to send a report indicating that a traffic event has occurred. Accordingly, the network determines whether to send a report based on the configuration information.

[0009] In some implementations, the second network device is a device that can provide a serving cell for the first network device. Note that in this disclosure, the second network device can be replaced with a serving cell. For example, the phrase "the first network device receives from the second network device" can also be expressed as "the first network device receives from the serving cell," and should be understood in the same or similar manner.

[0010] In some implementations, configuration information is provided to the first network device to determine whether to send a report. For example, the configuration may include threshold information, indicating that a traffic event has occurred if a specific measured value of a traffic-related parameter is greater than or equal to, or less than or equal to, a threshold, and the first network device may send feedback or a report indicating that a traffic event has occurred.

[0011] In some implementations, the method further includes determining, based on configuration information, whether a traffic event has occurred. For example, the first network device determines whether one or more conditions for the traffic event (i.e., one or more conditions indicating that a traffic event has occurred) are met.

[0012] In some implementations, a report is sent when a traffic event has occurred. For example, a first network device may send a report when one or more conditions indicating that a traffic event has occurred are met.

[0013] In some implementations, the configuration information includes at least one of the following: information for identifying the type of traffic event to be monitored by the first network device; information indicating a threshold for the type of traffic event, wherein the threshold is used to compare with monitoring data to determine whether a traffic event has occurred; information indicating the duration of the traffic event that triggers the sending of a report; information indicating whether the first network device is specified to send a report when a traffic event has occurred; information indicating whether a network device group including the first network device is specified to send a report when a traffic event has occurred; or information indicating the reporting device within the network device group designated to send a report when a traffic event has occurred.

[0014] In some implementations, the type of traffic event to be monitored is related to at least one of the following: the service throughput of the first network device; the resource utilization of the first network device; or the number of terminal devices served by the first network device.

[0015] In some implementations, the report includes at least one of the following: information identifying the first network device; information identifying a group of network devices including the first network device; information indicating the type of service measured by the first network device; information indicating the direction of the service measured by the first network device; information indicating the traffic event data measured by the first network device according to configuration information before triggering the reporting of a traffic event; or information indicating the service carrier frequency measured by the first network device.

[0016] In some implementations, the service type is at least one of the following: enhanced mobile broadband (eMBB) service, ultra-reliable low-latency communication (URLLC) service, massive machine-type communication (mMTC) service, global connectivity service, sensing-related service, or service related to artificial intelligence (AI) or machine learning (ML) technologies applied to communication.

[0017] In some implementations, the method further includes receiving additional configuration information to be used to determine whether to send a report. The additional configuration information may include updates to configuration information previously received by the first network device from the second network device.

[0018] In some implementations, the method further includes: a first network device monitoring a control channel carrying control information from a second network device, wherein the control information message is used to schedule the transmission of configuration information.

[0019] In some implementations, the control channel is a common control channel shared with one or more other network devices in the network.

[0020] In some implementations, configuration information is carried on a system information block (SIB).

[0021] In some implementations, the control information includes a cyclic redundancy check (CRC) scrambled using a radio network temporary identifier (RNTI).

[0022] In some implementations, the control channel is a control channel dedicated to the first network device.

[0023] In some implementations, configuration information is carried in radio resource control (RRC) messages.

[0024] In some implementations, the first network device may be a first terrestrial transmission and receive point (T-TRP).

[0025] In some implementations, the second network device can be a second T-TRP.

[0026] In some implementations, when the first network device is the first T-TRP and the second network device is the second T-TRP, the second T-TRP can provide services and coverage for the first T-TRP, or it can be a serving cell that provides services and coverage for the first T-TRP.

[0027] In some implementations, the second network device is the first non-terrestrial transmission and receive point (NT-TRP).

[0028] In some implementations, when the first network device is the first T-TRP and the second network device is the first NT-TRP, the first NT-TRP can provide services and coverage for the first T-TRP, or serve as a serving cell for the first T-TRP.

[0029] In some implementations, the second network device is the first NT-TRP, wherein the first network device sends reports to the second network device or a second NT-TRP that is different from the first NT-TRP.

[0030] In some implementations, the second network device and the second NT-TRP are either on the same track or on one or more different tracks, where each track provides coverage for the first network device.

[0031] In some implementations, a first network device serves a first coverage area; and / or a second network device serves a second coverage area.

[0032] In some implementations, at least one of the following conditions must be met: the first coverage area is smaller than the second coverage area; at least a portion of the first coverage area is located within the second coverage area; or the first coverage area overlaps with the second coverage area.

[0033] According to one aspect of this disclosure, a first network device is provided. The first network device includes components for performing the methods mentioned in this disclosure. For example, the first network device includes a processor coupled to a computer-readable medium. The computer-readable medium stores computer-executable instructions, which, when executed, cause the processor to perform methods consistent with the embodiments described above and herein. A non-limiting example of the first network device is a terrestrial transmit and receive point (T-TRP). In some implementations, the first network device includes a chip, such as an integrated circuit (IC) chip. In some implementations, the first network device does not execute the above methods by means of a processor executing instructions; for example, the first network device may include circuitry for performing the above methods, such as a field-programmable gate array (FPGA), a graphics processing unit (GPU), or an application-specific integrated circuit (ASIC). Generally, the first network device may include modules, units, or components for performing the above methods.

[0034] According to one aspect of this disclosure, a network management method is provided. The method includes: a second network device sending configuration information to a first network device, wherein the configuration information is used by the first network device to determine whether to send a report indicating that a traffic event has occurred.

[0035] In some implementations, the second network device is a device that can provide a serving cell to the first network device. As mentioned above, in this disclosure, the second network device can be replaced by a serving cell. For example, "the second network device sends to the first network device" can also be expressed as "the serving cell sends to the first network device," and understood in the same or similar manner.

[0036] In some implementations, the method also includes receiving a report from a first network device.

[0037] In some implementations, the configuration information includes at least one of the following: information for identifying the type of traffic event to be monitored by the first network device; information indicating a threshold for the type of traffic event, wherein the threshold is used to compare with monitoring data so that the first network device can determine whether a traffic event has occurred; information indicating the duration of the traffic event that triggers the first network device to send a report; information indicating whether the first network device is specified to send a report when a traffic event has occurred; information indicating whether a network device group including the first network device is specified to send a report when a traffic event has occurred; or information indicating the reporting device within the network device group designated to send a report when a traffic event has occurred.

[0038] In some implementations, the type of traffic event to be monitored by the first network device is related to at least one of the following: the service throughput of the first network device; the resource utilization rate of the first network device; or the number of terminal devices served by the first network device.

[0039] In some implementations, the report includes at least one of the following: information identifying the first network device; information identifying a group of network devices including the first network device; information indicating the type of service measured by the first network device; information indicating the direction of the service measured by the first network device; information indicating the traffic event data measured by the first network device according to configuration information before triggering the reporting of a traffic event; or information indicating the carrier frequency of the service detected by the first network device.

[0040] In some implementations, the service type is at least one of the following: enhanced mobile broadband (eMBB) service, ultra-reliable low-latency communication (URLLC) service, massive machine-type communication (mMTC) service, global connectivity service, sensing-related service, or service related to artificial intelligence (AI) or machine learning (ML) technologies applied to communication.

[0041] In some implementations, the method further includes sending additional configuration information to a first network device, wherein the additional configuration information is used by the first network device to determine whether to send a report. The additional configuration information may include updates to configuration information previously sent by a second network device to the first network device.

[0042] In some implementations, control information is transmitted through a control channel, and this control information is used to schedule the transmission of configuration information.

[0043] In some implementations, the control channel is a common control channel shared with one or more other network devices in the network.

[0044] In some implementations, configuration information is carried on a system information block (SIB).

[0045] In some implementations, the control information includes a cyclic redundancy check (CRC) scrambled using a radio network temporary identifier (RNTI).

[0046] In some implementations, the control channel is a control channel dedicated to the first network device.

[0047] In some implementations, configuration information is carried in radio resource control (RRC) messages.

[0048] In some implementations, the first network device is the first terrestrial transmission and receive point (T-TRP).

[0049] In some implementations, the second network device is the second T-TRP.

[0050] In some implementations, when the first network device is the first T-TRP and the second network device is the second T-TRP, the second T-TRP can provide services and coverage for the first T-TRP, or it can be a serving cell that provides services and coverage for the first T-TRP.

[0051] In some implementations, the second network device is the first non-terrestrial transmission and receive point (NT-TRP).

[0052] In some implementations, when the first network device is the first T-TRP and the second network device is the first NT-TRP, the first NT-TRP can provide services and coverage for the first T-TRP, or serve as a serving cell for the first T-TRP.

[0053] In some implementations, the method further includes sending configuration information to a second NT-TRP that is different from the first NT-TRP, wherein the second NT-TRP is located on the first track where the first NT-TRP is located, or on a second track that is different from the first track, and both the first track and the second track provide coverage for the first network device.

[0054] In some implementations, the method further includes receiving configuration information from a third NT-TRP that is different from the first NT-TRP, wherein the first NT-TRP and the third NT-TRP are on the same or different tracks, and each track provides coverage for the first network device.

[0055] In some implementations, at least one of the following is satisfied: the first network device serves a first coverage area; or the second network device serves a second coverage area.

[0056] In some implementations, at least one of the following conditions must be met: the first coverage area is smaller than the second coverage area; at least a portion of the first coverage area is located within the second coverage area; or the first coverage area overlaps with the second coverage area.

[0057] According to one aspect of this disclosure, a second network device is provided. The second network device includes components for performing the methods mentioned in this disclosure. Specifically, the second network device includes a processor coupled to a computer-readable medium. The computer-readable medium stores computer-executable instructions, which, when executed, cause the processor to perform methods consistent with the embodiments described above and herein. A non-limiting example of the second network device is a terrestrial transmit and receive point (T-TRP), a non-terrestrial transmit and receive point (NT-TRP), a satellite, and / or one or more network-side devices. In some implementations, the second network device includes a chip, such as an IC chip. In some implementations, the second network device does not execute instructions via a processor to perform the methods described above; for example, the second network device may include circuitry for performing the methods described above, such as an FPGA, GPU, or ASIC. Generally, the second network device may include modules, units, or components for performing the methods described above.

[0058] According to one aspect of this disclosure, a computer-readable storage medium is provided. This computer-readable storage medium stores computer-executable instructions, which, when executed, cause a computer to perform methods described above or elsewhere in this disclosure. The computer-readable storage medium may be non-transitory.

[0059] According to one aspect of this disclosure, a computer program is provided. The computer program includes computer-executable instructions, wherein, when executed, the computer-executable instructions cause a computer to perform the methods described above or elsewhere in this disclosure.

[0060] In some aspects of this disclosure, an apparatus / chipset system is provided. This apparatus / chipset system includes components (such as at least one processor) for implementing the methods described above by a first network device of this disclosure (or at the network device of this disclosure). The apparatus / chipset system may be a first network device (such as a terrestrial TRP) or a module / component within the first network device. Specifically, at least one processor can execute instructions stored in a computer-readable medium to implement the methods described above.

[0061] In some aspects of this disclosure, an apparatus / chipset system is provided. This apparatus / chipset system includes components (such as at least one processor) for implementing the methods described above by a second network device of this disclosure (such as a terrestrial TRP, a non-terrestrial TRP, a satellite, or a network-side device). The apparatus / chipset system may be a second network device or a module / component within a second network device. Specifically, at least one processor can execute instructions stored in a computer-readable medium to implement the methods described above.

[0062] In some aspects of this disclosure, a system is provided. The system includes at least one of the means in (or at the location of) a first network device of this disclosure or a second network device (such as a satellite, network-side device) of this disclosure.

[0063] In some aspects of this disclosure, a method performed by a system is provided. The system includes at least one of means in (or at) a first network device of this disclosure or means in (or at) a second network device of this disclosure (such as a network-side device). Attached Figure Description

[0064] To gain a more comprehensive understanding of this embodiment and its advantages, the following description, taken by way of example and in conjunction with the accompanying drawings, is provided.

[0065] Figure 1 This is a schematic diagram of a communication system that can implement the embodiments of this disclosure.

[0066] Figure 2 This is another schematic diagram of a communication system that can implement the embodiments of this disclosure.

[0067] Figure 3 It is a block diagram of a unit or module in a device that can implement the embodiments of the present disclosure.

[0068] Figure 4 It is a block diagram of a unit or module in a device that can implement the embodiments of the present disclosure.

[0069] Figure 5 An exemplary network is shown in which network devices and serving cells communicate and operate according to embodiments of this disclosure.

[0070] Figure 6 Another exemplary network is shown in which network devices and service cells communicate and operate according to embodiments of this disclosure.

[0071] Figure 7 An exemplary communication link between a serving cell and a network device served by the serving cell is shown according to an embodiment of this disclosure.

[0072] Figure 8 An exemplary signal flow diagram of traffic event reporting in a network according to an embodiment of this disclosure is shown.

[0073] Figure 9 An example is shown of a network device according to an embodiment of the present disclosure reporting traffic events based on configuration information received from the serving cell.

[0074] Figure 10 An example is shown of a reporting network device within a group of network devices according to an embodiment of this disclosure, reporting traffic events based on configuration information received from the serving cell.

[0075] Figure 11 An example of configuration information transmission via a common control channel according to an embodiment of the present disclosure is shown.

[0076] Figure 12 An example of configuration information transmission via a dedicated control channel according to an embodiment of this disclosure is shown.

[0077] Figure 13 This is a signal flow diagram of an exemplary network management method according to embodiments of the present disclosure. Detailed Implementation

[0078] For illustrative purposes, specific exemplary embodiments are explained in detail below with reference to the accompanying drawings.

[0079] The embodiments described herein illustrate information sufficient to practice the claimed subject matter and explain methods for practicing such subject matter. Those skilled in the art will understand the concepts of the claimed subject matter after reading the following description with reference to the accompanying drawings, and will recognize that the application of these concepts is not specifically mentioned herein. It should be understood that these concepts and applications are within the scope of this disclosure and the appended claims.

[0080] Furthermore, it should be understood that any module, component, or device disclosing executable instructions herein may include or otherwise access one or more non-transitory computer / processor-readable storage media to store information, such as computer / processor-readable instructions, data structures, program modules, and / or other data. A non-exhaustive list of examples of non-transitory computer / processor-readable storage media includes magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices, compact disc read-only memory (CD-ROM), digital video disc, or digital versatile disc (DVD). Optical discs or other optical storage devices; volatile and non-volatile, removable and non-removable media implemented in any method or technology; random-access memory (RAM); read-only memory (ROM); electrically erasable programmable read-only memory (EEPROM); flash memory or other storage technologies. Any such non-transitory computer / processor storage medium may be part of a device or accessible or connected to a device. Computer / processor-readable / executable instructions used to implement the applications or modules described herein may be stored or otherwise preserved by such non-transitory computer / processor-readable storage media.

[0081] As described above, in wireless communication systems (such as Fourth Generation (4G) Long-Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR)), discontinuous reception (DRX) and discontinuous transmission (DTX) are used to achieve energy saving and / or power management for user equipment (UE). For example, when a UE is operating in sleep mode in DRX mode, it does not receive any physical layer signals / channels. For instance, the UE does not detect and measure reference signals (RS), nor does it detect and decode messages carried in logical channels (such as the physical downlink control channel (PDCCH) and / or the physical downlink shared channel (PDSCH)). Similarly, when a UE is operating in sleep mode in DTX mode, it does not transmit any physical layer signals / channels. For example, the user equipment (UE) does not perform signal processing related to generating uplink signals or uplink logical channels (such as the physical uplink control channel (PUCCH) and / or the physical uplink shared channel (PUSCH)). Using these techniques, the UE can reduce power consumption by only activating its receivers or transmitters when the UE is in active DRX and / or DTX mode.

[0082] Currently, there are no standards for energy saving or power management of network-side devices (such as transmission and receive points, TRPs). However, attempts have been made to achieve energy saving in network-side devices in existing technologies.

[0083] One proposed approach to achieve energy savings in network-side equipment is to use a "simplified" synchronization signal (SS) / physical broadcast channel (PBCH) (SS / PBCH) block. This approach suggests simplifying the SS / PBCH block to reduce power consumption in network-side equipment. For example, the SS / PBCH block can be simplified by including only one of the primary synchronization signal (PSS) and the secondary synchronization signal (SSS). Other variants that can be considered simplified SS / PBCH blocks may have longer periods, significantly exceeding the periods of SS / PBCH blocks supported by wireless communication systems such as 5G NR.

[0084] The second proposed solution for energy saving on network-side equipment is to use "cell DRX" and "cell DTX," which essentially mimics the DRX / DTX modes mentioned above for user equipment. For example, when the TRP is in sleep mode in cell DRX mode, the TRP does not receive any physical layer signals / channels (e.g., it does not detect and measure reference signals (RS), nor does it detect and decode messages carried in logical channels (such as PUCCH and / or PUSCH). Similarly, when the TRP is running in sleep mode in DTX mode, the TRP does not transmit any physical layer signals / channels (e.g., it does not perform any signal processing related to generating downlink signals or downlink logical channels (such as PDCCH and / or PDSCH)).

[0085] A third method proposed to achieve energy saving in network-side equipment is bandwidth part (BWP) adaptation. For example, by performing cell handover, data transmission can be performed using a narrower BWP, reducing the power consumption required for data transmission compared to data transmission on a wider-bandwidth BWP. To achieve this, the UE can be configured with multiple BWPs (e.g., supporting dynamic adjustment of its bandwidth) and instructed to switch from one BWP (e.g., a wider-bandwidth BWP) to another (e.g., a narrower-bandwidth BWP). Instructions for BWP handover can be sent via DCI signaling, etc.

[0086] Network-side energy saving and management methods (as described above) may be network-specific. Network-specific or customized energy saving implementations are feasible when, for example, network operators are able to perform energy saving and management based on heuristics, traffic load management, and balancing.

[0087] However, as mentioned above, network energy-saving and management technologies specific to certain networks can be difficult to manage, maintain, or scale. For example, some network-specific energy-saving and management technologies may require network operators to use network equipment and facilities from only one network hardware vendor. Given that network operators typically use a variety of network equipment and facilities from multiple network hardware vendors, network-specific energy-saving and management technologies may not be ideal. Instead, standardized energy-saving and / or network management approaches may be preferred because they are likely easier to manage, maintain, or scale compared to network-specific technologies, especially when network operators use network equipment and facilities from multiple network hardware vendors.

[0088] This disclosure provides methods and apparatus for overcoming the aforementioned deficiencies, as well as specific network management methods applicable to various network systems. According to some implementations of this disclosure, a serving cell can support traffic management within the coverage area served by a network device (such as a terrestrial TRP). The serving cell can be considered as a base station that allows and supports traffic management based on traffic event reports sent by the network device. In some implementations, the base station can be a terrestrial base station. In some implementations, the base station can be a non-terrestrial base station. In some implementations, the network device can be a terrestrial base station. The network device can send a report indicating that a traffic event has occurred. A traffic event can be an event in which at least one monitoring metric is greater than or equal to, or less than or equal to, a threshold. The network device can send a report based on configuration information received from the serving cell when one or more conditions indicating that a traffic event has occurred are met. This configuration information can be used by the network device to determine whether to send a report indicating that a traffic event has occurred.

[0089] In some implementations, configuration information transmission can be scheduled via a control channel carrying control information messages. In some implementations, this control channel can be a common control channel shared with one or more other network devices (such as base stations) in the network. In some implementations where the control channel is a common control channel, the configuration information can be carried on a system information block (SIB). In some implementations where the control channel is a common control channel, the control information message can include a cyclic redundancy check (CRC) scrambled using a radio network temporary identifier (RNTI) (such as a traffic event monitoring RNTI (TM-RNTI)). In some implementations, the control channel can be a control channel dedicated to network devices. In some implementations where the control channel is a control channel dedicated to network devices, the configuration information can be carried in a radio resource control (RRC) configuration message.

[0090] According to some aspects of this disclosure, carbon neutrality can be achieved while providing seamless global network coverage in various network systems, such as terrestrial network systems, non-terrestrial network systems, and integrated terrestrial and non-terrestrial network systems (e.g., network systems where terrestrial and non-terrestrial equipment can coexist). According to some aspects of this disclosure, network traffic load can be effectively managed in various network systems.

[0091] While the various aspects of this disclosure are primarily described in network systems (such as integrated terrestrial and non-terrestrial network systems), it should be noted that the various aspects of this disclosure are not limited to the integrated terrestrial and non-terrestrial network systems described herein, but can be more broadly applied to terrestrial network systems, non-terrestrial network systems, or other types of network systems that can utilize the methods, apparatus, and / or devices described herein. In other words, the various aspects of this disclosure are not limited to specific types of communication or specific wireless access technologies.

[0092] The following Figure 1 , Figure 2 and Figure 3 A network and device context is provided, which may be located in the network and may implement various aspects of this disclosure.

[0093] refer to Figure 1 , Figure 1This is a non-limiting illustrative example, providing a simplified schematic diagram of a communication system. Communication system 100 includes a radio access network 120. Radio access network 120 can be a next-generation (such as sixth-generation, 6G, or later) radio access network, or a traditional (such as 5G, 4G, 3G, or 2G) radio access network. One or more electronic devices (EDs) 110a to 120j (generally referred to as 110) can be interconnected with each other and can additionally or alternatively connect to one or more network nodes (170a, 170b (generally referred to as 170); 172) in radio access network 120. Network nodes 170a and 170b can be terrestrial network nodes, and network node 172 can be a non-terrestrial network node. It should be noted that... Figure 1 The connection between one or more communication ED 110s and one or more network nodes 170 and / or 172 described herein is merely an example, and other connections may also exist. Figure 1 One or more connections not explicitly described in the code. For example, although... Figure 1 The connection between ED 110e and network node 172 is not explicitly included, but ED 110e and network node 172 may be interconnected. Core network 130 may be part of the communication system and may rely on or be independent of the wireless access technology used in communication system 100. Furthermore, communication system 100 includes a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0094] Figure 2 An exemplary communication system 100 is illustrated, in which this disclosure can be implemented. Generally, system 100 enables multiple wireless or wired units to transmit data and other content. The purpose of system 100 may be to provide content (voice, data, video, text) via broadcast, narrowcast, user equipment to user equipment, etc. System 100 can operate efficiently by sharing resources such as bandwidth.

[0095] In this example, the communication system 100 includes electronic devices (EDs) 110a to 110c, radio access networks (RANs) 120a and 120b, a core network 130, a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160. Although Figure 2 A certain number of these components or units are shown, but the system 100 may include any suitable number of these components or units.

[0096] EDs 110a to 110c are used for operation and / or communication within system 100. For example, EDs 110a to 110c are used for transmitting and / or receiving via a wireless communication channel. Each ED 110a to 110c represents any end-user equipment suitable for wireless operation and may include (or may be referred to as) devices such as: user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, mobile user unit, cellular telephone, station (STA), machine type communication (MTC) device, personal digital assistant (PDA), smartphone, laptop computer, computer, touchpad, wireless sensor, or consumer electronic device.

[0097] Figure 2 An exemplary communication system 100 is illustrated, in which this disclosure can be implemented. Generally, the communication system 100 enables multiple wireless or wired units to transmit data and other content. The purpose of the communication system 100 may be to provide content (voice, data, video, text) via broadcast, multicast, unicast, user equipment to user equipment, etc. The communication system 100 can operate by sharing resources such as bandwidth.

[0098] In this example, the communication system 100 includes electronic devices (EDs) 110a to 110d, radio access networks (RANs) 120a to 120c, a core network 130, a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160. Although Figure 2 A certain number of these components or units are shown, but the communication system 100 may include any suitable number of these components or units.

[0099] EDs 110a to 110d are used to operate and / or communicate in communication system 100. For example, EDs 110a to 110d are used to transmit and / or receive via a wireless communication channel or a wired communication channel. Each ED 110a to 110d represents any suitable end-user equipment for wireless operation and may include (or be referred to as) devices such as: user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular telephone, station (STA), machine type communication (MTC) device, personal digital assistant (PDA), smartphone, laptop computer, computer, tablet computer, wireless sensor, or consumer electronic device.

[0100] exist Figure 2 In this configuration, RAN 120a and 120b include base stations 170a and 170b, respectively. Each base station 170a and 170b is used to establish a wireless connection with one or more EDs (EDs) from ED 110a to 110c, enabling access to any other base stations 170a and 170b, core network 130, PSTN 140, Internet 150, and / or other networks 160. For example, base stations 170a and 170b may include (or may be) one or more of several well-known devices, such as a base transceiver station (BTS), Node-B (NodeB), evolved NodeB (eNodeB), home eNodeB, gNodeB, transmission and receive point (TRP), site controller, access point (AP), or wireless router.

[0101] In some examples, one or more of base stations 170a and 170b may be ground-based base stations connected to the ground. For example, ground-based base stations may be installed on buildings or towers. Alternatively, one or more of base stations 172 may be non-ground-based base stations or non-terrestrial TRPs (NT-TRPs) not connected to the ground. A flying base station is an example of a non-ground-based base station. A flying base station can be implemented using communication equipment carried or transported by flying equipment. Non-limiting examples of flying equipment include airborne platforms (such as small airships or spacecraft), balloons, quadcopters, and other aircraft. In some implementations, a flying base station may be carried or transported by an unmanned aerial system (UAS) or an unmanned aerial vehicle (UAV) (such as a drone or quadcopter). A flying base station may be a mobile or portable base station, which can be flexibly deployed in different locations to meet network requirements. A satellite base station is another example of a non-ground-based base station. A satellite base station can be implemented using communication equipment carried or transported by a satellite. A satellite base station may also be referred to as an orbital base station.

[0102] Alternatively or additionally, any ED 110a to 110d can be used to connect, access, or communicate with any other base station 170a and 170b, Internet 150, core network 130, PSTN 140, other network 160, or any combination thereof.

[0103] EDs 110a to 110d and base stations 170a, 170b, and 172 are examples of communication devices that can be used to implement some or all of the operations and / or embodiments described herein. Figure 2In the example shown, base station 170a is part of RAN 120a, which may include other base stations, one or more base station controllers (BSCs), one or more radio network controllers (RNCs), relay nodes, cells, and / or devices. Any base station 170a, 170b can be a single cell as shown, or multiple cells distributed within the corresponding RAN, etc. Similarly, base station 170b is part of RAN 120b, which may include other base stations, cells, and / or devices. Each base station 170a and 170b transmits and / or receives radio signals within a specific geographical area or region (sometimes referred to as a "cell" or "coverage area"). A cell may be further divided into cell sectors, and base stations 170a and 170b may, for example, use multiple transceivers to provide services to multiple sectors. In some implementations, established picocells or femtocells supported by radio access technologies may exist. In some implementations, multiple transceivers can be used for each cell using multiple-input multiple-output (MIMO) technology, etc. The number of RANs 120a and 120b shown are merely exemplary. Any number of RANs can be envisioned when designing the communication system 100.

[0104] Base stations 170a, 170b, and 172 use radio frequency (RF), microwave, and infrared (IR) wireless communication links to communicate with one or more EDs (EDs) from ED 110a to ED 110d through one or more air interfaces 190a and 190c. Air interfaces 190a and 190c can employ any suitable wireless access technology. For example, communication system 100 can implement one or more orthogonal or non-orthogonal channel access methods in air interfaces 190a and 190c, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA).

[0105] Base stations 170a, 170b, and 172 communicate with each other via one or more air interfaces 190e and 190f using radio frequency (RF), microwave, or infrared (IR) wireless communication links. Air interfaces 190e and 190f can employ any suitable wireless access technology and can be substantially similar to, but not substantially different from, the air interfaces 190a and 190c used by ED 110a to 110d to communicate with one or more of base stations 170a, 170b, and 172. For example, communication system 100 can implement one or more channel access methods in the SL air interfaces 190e and 190f, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA).

[0106] Base stations 170a, 170b, and 172 can implement Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access (UTRA) to establish air interfaces 190a and 190c using wideband CDMA (WCDMA). In this way, base stations 170a, 170b, and 172 can implement protocols such as High Speed ​​Packet Access (HSPA) and Evolved HPSA (HSPA+), where HSPA+ optionally includes High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA). Alternatively, base stations 170a, 170b, and 172 can use LTE, LTE-A, and / or LTE-B to establish air interfaces 190a and 190c with Evolved UMTS Terrestrial Radio Access (E-UTRA). It is conceivable that the communication system 100 can use multi-channel access operation, including the schemes described above. Other wireless technologies used to implement the air interface include IEEE 802.11, 802.15, 802.16, CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, IS-2000, IS-95, IS-856, GSM, EDGE, and GERAN. Of course, other multiple access schemes and wireless protocols can also be used.

[0107] RANs 120a and 120b communicate with core network 130 to provide various services, such as voice, data, and other services, to EDs 110a to 110c. RANs 120a and 120b, and / or core network 130, can communicate directly or indirectly with one or more other RANs (not shown), which may or may not be directly served by core network 130, and may or may not use the same radio access technology as RANs 120a and / or RAN 120b. Core network 130 can also serve as a gateway access between (i) RANs 120a and 120b, and / or EDs 110a to 110c, and (ii) other networks (such as PSTN 140, Internet 150, and other networks 160).

[0108] EDs 110a to 110d use radio frequency (RF), microwave, infrared (IR), or other wireless communication links to communicate with each other through one or more sidelink (SL) air interfaces 190b and 190d. The SL air interfaces 190b and 190d can employ any suitable wireless access technology and can be substantially similar to, or substantially different from, the air interfaces 190a and 190c used by EDs 110a to 110c to communicate with one or more base stations 170a and 170b. For example, communication system 100 can implement one or more channel access methods in the SL air interfaces 190b and 190d, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA). In some implementations, SL air interface 190b and 190d can be implemented at least partially on unlicensed spectrum.

[0109] Additionally, some or all of EDs 110a to 110d may include operations for communicating with different wireless networks via different wireless links using different wireless technologies and / or protocols. EDs may communicate with service providers or exchanges (not shown) via wired communication channels and with the Internet 150, rather than wirelessly (or also wirelessly). PSTN 140 may include a circuit-switched telephone network for providing plain old telephone service (POTS). The Internet 150 may include computer networks and / or subnets (internal networks) and include protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). EDs 110a to 110d may be multimode devices capable of operating according to multiple wireless access technologies and include multiple transceivers required to support multiple wireless access technologies.

[0110] In some implementations, the signal is transmitted from a terrestrial BS to the UE, or directly from the UE to the terrestrial BS; in both cases, the signal is not reflected by the RIS. However, the signal may be reflected by obstacles and reflectors such as buildings, walls, and furniture. In some implementations, the signal is transmitted between the UE and a non-terrestrial BS (such as satellites, drones, and high-altitude platforms). In some implementations, the signal is transmitted between a relay and the UE, between a relay and a BS, or between two relays. In some implementations, the signal is transmitted between two UEs. In some implementations, one or more RIS are used to reflect signals from a transmitter and a receiver, where either the transmitter or receiver includes the UE, a terrestrial or non-terrestrial BS, and a relay.

[0111] Figure 3 Another example of ED 110 and network equipment is shown, including base stations 170a and 170b (as shown in 170) and NT-TRP 172. ED 110 is used to connect people, things, machines, etc. ED 110 can be widely used in various scenarios, such as cellular communication, device-to-device (D2D), vehicle-to-everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), machine-type communication (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, and so on.

[0112] Each ED 110 represents any suitable end-user equipment for wireless operation and may include (or be referred to as): user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, station (STA), machine-type communication (MTC) device, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, consumer electronics, smartbook, vehicle, automobile, truck, bus, train, or IoT device, industrial equipment, or devices within the aforementioned equipment (such as communication modules, modems, or chips), etc. Next-generation ED 110 may be referred to using other terms. Base stations 170a and 170b are T-TRPs, referred to below as T-TRP 170. Similarly... Figure 3 As shown, NT-TRP is referred to as NT-TRP 172 below. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 can be dynamically or semi-statically started (i.e., established, activated, or enabled), shut down (i.e., released, deactivated, or disabled), and / or configured in response to one or more of connectivity availability and connectivity necessity.

[0113] ED 110 includes a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is shown in the figure. One, some, or all of the antennas may also be panels. The transmitter 201 and receiver 203 may be integrated, for example, integrated as a transceiver. The transceiver is used to modulate data or other content for transmission through at least one antenna 204 or a network interface controller (NIC). The transceiver may also be used to demodulate data or other content received through at least one antenna 204. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or for processing signals received wirelessly or wiredly. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless or wired signals.

[0114] ED 110 includes at least one memory 208. Memory 208 stores instructions and data used, generated, or collected by ED 110. For example, memory 208 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by one or more processing units 210. Each memory 208 includes any suitable one or more volatile and / or non-volatile storage and retrieval devices. Any suitable type of memory can be used, such as random access memory (RAM), read-only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) card, and processor cache, etc.

[0115] ED 110 may also include one or more input / output devices (not shown) or interfaces (such as those connected to...). Figure 1 or Figure 2 (Wired interface of Internet 150 in the network). Input / output devices support interaction with the user or other devices in the network. Each input / output device includes any suitable structure for providing or receiving information from the user, such as a speaker, microphone, keypad, keyboard, display, or touchscreen, including network interface communication.

[0116] ED 110 also includes a processor 210 for performing the following operations: operations related to preparing to transmit uplink transmissions to NT-TRP 172 and / or T-TRP 170; operations related to processing downlink transmissions received from NT-TRP 172 and / or T-TRP 170; and operations related to processing sidelink transmissions transmitted to and from other ED 110s. Processing operations related to preparing to transmit uplink transmissions may include operations such as encoding, modulation, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulation, and decoding of received symbols. According to a specific embodiment, the downlink transmission may be received by receiver 203 via receive beamforming, and processor 210 may extract signaling from the downlink transmission (e.g., by detecting and / or decoding signaling). An example of signaling may be a reference signal transmitted by NT-TRP 172 and / or T-TRP 170. In some implementations, processor 210 performs transmit beamforming and / or receive beamforming based on beam direction indications (such as beam angle information (BAI)) received from T-TRP 170. In some implementations, processor 210 can perform operations related to network access (such as initial access) and / or downlink synchronization, such as operations related to detecting synchronization sequences, decoding, and acquiring system information. In some implementations, processor 210 can perform channel estimation, for example, using reference signals received from NT-TRP 172 and / or T-TRP 170.

[0117] Although not shown in the figures, processor 210 may be part of transmitter 201 and / or receiver 203. Although not shown in the figures, memory 208 may be part of processor 210.

[0118] The processing components in processor 210, transmitter 201, and receiver 203 can be implemented by the same or different processors, which execute instructions stored in memory (such as memory 208). Alternatively, some or all of the processing components in processor 210, transmitter 201, and receiver 203 can be implemented using special-purpose circuits such as a field-programmable gate array (FPGA), a graphics processing unit (GPU), or an application-specific integrated circuit (ASIC).

[0119] In some implementations, ED 110 can be a device (also referred to as a component) such as a communication module, modem, chip, or chipset, including at least one processor 210 and an interface or at least one pin. In this scenario, transmitter 201 and receiver 203 can be replaced by an interface or at least one pin, wherein the interface or at least one pin is used to connect the device (such as a chip) and other devices (such as chips, memory, or a bus). Therefore, sending information to NT-TRP 172 and / or T-TRP 170 and / or other ED 110 can be referred to as sending information to an interface or at least one pin, or sending information to NT-TRP 172 and / or T-TRP 170 and / or other ED 110 via an interface or at least one pin. Receiving information from NT-TRP 172 and / or T-TRP 170 and / or other ED 110 can be referred to as receiving information from an interface or at least one pin, or receiving information from NT-TRP 172 and / or T-TRP 170 and / or other ED 110 via an interface or at least one pin. This information may include control signaling and / or data. Similar rules may apply to other nodes / entities in this disclosure. In some implementations, T-TRP 170 may be referred to by other names, such as base station, base transceiver station (BTS), wireless base station, network node, network device, network-side device, transmitting / receiving node, NodeB, evolved NodeB (eNodeB or eNB), home eNodeB, next generation NodeB (gNB), transmission point (TP), site controller, access point (AP) or wireless router, relay station, ground node, ground network device or ground base station, baseband unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), location node, etc. T-TRP 170 can be a macro BS, a pico BS, a relay node, or a donor node, or a combination thereof. T-TRP 170 can refer to the aforementioned device or a component within the aforementioned device (such as a communication module, modem, or chip). Although the accompanying drawings and descriptions of the examples and embodiments of this disclosure generally use the terms "AP," "BS," and "AP" or "BS," it should be understood that such a device can be any of the types described above.

[0120] In some implementations, the various parts of T-TRP 170 can be distributed. For example, some modules in T-TRP 170 may be located remotely from the device housing the antenna of T-TRP 170 and may be coupled to the device housing the antenna via a communication link (not shown) sometimes referred to as the fronthaul (e.g., the Common Public Radio Interface, CPRI). Therefore, in some implementations, the term "T-TRP 170" may also refer to network-side modules that perform processing operations such as determining the location of ED 110, resource allocation (scheduling), message generation, and encoding / decoding; these modules are not necessarily part of the device housing the antenna of T-TRP 170. These modules may also be coupled to other T-TRPs. In some implementations, T-TRP 170 may actually be multiple T-TRPs that operate together to serve ED 110, for example, through cooperative multicast.

[0121] T-TRP 170 includes at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is shown in the figure. One, some, or all of the antennas may also be panels. The transmitter 252 and receiver 254 may be integrated as a transceiver. T-TRP 170 also includes a processor 260 for performing operations related to: preparing to transmit downlink transmissions to ED 110, processing uplink transmissions received from ED 110, preparing to transmit backlink transmissions to NT-TRP 172, and processing transmissions received from NT-TRP 172 via backlink. Processing operations related to preparing to transmit downlink or backlink transmissions may include encoding, modulation, precoding (such as multiple-input multiple-output (MIMO) precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the uplink or backlink may include receive beamforming, demodulation, and decoding of received symbols. Processor 260 can also perform operations related to network access (such as initial access) and / or downlink synchronization, such as generating the contents of a synchronization signal block (SSB), generating system information, etc. In some implementations, processor 260 also generates beam direction indications, such as BAI, which can be scheduled for transmission by scheduler 253. Processor 260 performs other network-side processing operations described herein, such as determining the location of ED 110, determining the location for deploying NT-TRP 172, etc. In some implementations, processor 260 can generate signaling, such as for configuring one or more parameters of ED 110 and / or one or more parameters of NT-TRP 172. Any signaling generated by processor 260 is transmitted by transmitter 252. It should be noted that the term "signaling" as used herein may also be referred to as control signaling. Dynamic signaling can be transmitted in control channels such as the physical downlink control channel (PDCCH), while static or semi-static higher-layer signaling can be included in data packets transmitted in data channels such as the physical downlink shared channel (PDSCH).

[0122] Scheduler 253 may be coupled to processor 260. Scheduler 253 may be included within T-TRP 170 or may operate separately from T-TRP 170. Scheduler 253 may schedule uplink, downlink, and / or backlink transmissions, including issuing scheduling grants and / or configuring schedule-free (“configuration grants”) resources. T-TRP 170 also includes memory 258 for storing information and data. Memory 258 stores instructions and data used, generated, or collected by T-TRP 170. For example, memory 258 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by processor 260.

[0123] Although not shown in the figures, processor 260 may constitute part of transmitter 252 and / or receiver 254. Furthermore, although not shown in the figures, processor 260 may implement scheduler 253. Although not shown in the figures, memory 258 may constitute part of processor 260.

[0124] The processing components in processor 260, scheduler 253, transmitter 252, and receiver 254 can be implemented by the same or different processors, which execute instructions stored in memory (such as memory 258). Alternatively, some or all of the processing components in processor 260, scheduler 253, transmitter 252, and receiver 254 can be implemented using dedicated circuitry such as FPGA, GPU, or ASIC.

[0125] When T-TRP 170 is a device (also referred to as a component) such as a communication module, modem, chip, or chipset in a device, it includes at least one processor and an interface or at least one pin. In this scenario, transmitter 252 and receiver 254 can be replaced by an interface or at least one pin, wherein the interface or at least one pin is used to connect the device (such as a chip) and other devices (such as chips, memory, or a bus). Therefore, sending information to NT-TRP 172 and / or T-TRP 170 and / or ED 110 can be referred to as sending information to an interface or at least one pin. Receiving information from NT-TRP 172 and / or T-TRP 170 and / or ED 110 can be referred to as receiving information from an interface or at least one pin. This information may include control signaling and / or data.

[0126] Although the NT-TRP 172 is exemplified only as a drone, it can be implemented using any suitable non-terrestrial form. Furthermore, in some implementations, the NT-TRP 172 may be referred to by other names, such as a non-terrestrial node, a non-terrestrial network device, or a non-terrestrial base station. The NT-TRP 172 includes a transmitter 272 and a receiver 274 coupled to one or more antennas 280. Only one antenna 280 is shown in the figure. One, some, or all of the antennas may also be panels. The transmitter 272 and receiver 274 may be integrated as a transceiver. The NT-TRP 172 also includes a processor 276 for performing operations related to: preparing downlink transmissions to ED 110, processing uplink transmissions received from ED 110, preparing return transmissions to T-TRP 170, and processing transmissions received from T-TRP 170 via return. Processing operations related to preparing downlink or backhaul transmissions may include encoding, modulation, precoding (such as MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing receive transmissions in the uplink or backhaul may include receive beamforming, demodulation, and decoding of received symbols. In some implementations, processor 276 performs transmit beamforming and / or receive beamforming based on beam direction information (such as BAI) received from T-TRP 170. In some implementations, processor 276 may generate signaling to configure one or more parameters of ED 110, etc. In some implementations, NT-TRP 172 implements physical layer processing but not higher-layer functions, such as those in the medium access control (MAC) layer or radio link control (RLC) layer. Since this is only an example, NT-TRP 172 typically implements higher-layer functions in addition to physical layer processing.

[0127] The NT-TRP 172 also includes a memory 278 for storing information and data. Although not shown in the figures, a processor 276 may form part of the transmitter 272 and / or the receiver 274. Although not shown in the figures, the memory 278 may form part of the processor 276.

[0128] The processing components in processor 276, transmitter 272, and receiver 274 can be implemented by the same or different processors, which execute instructions stored in memory (such as memory 278). Alternatively, some or all of the processing components in processor 276, transmitter 272, and receiver 274 can be implemented using dedicated circuitry such as a programmable FPGA, GPU, or ASIC. In some implementations, NT-TRP 172 can actually be multiple NT-TRPs operating together to serve ED 110, for example, through cooperative multicast.

[0129] When NT-TRP 172 is a device within a machine (such as a communication module, modem, chip, or chipset), it includes at least one processor, an interface, or at least one pin. In this scenario, transmitter 272 and receiver 257 can be replaced by an interface or at least one pin, wherein the interface or at least one pin is used to connect the device (such as a chip) and other devices (such as chips, memory, or a bus). Therefore, sending information to T-TRP 170 and / or other NT-TRP 172 and / or ED 110 can be referred to as sending information to an interface or at least one pin. Receiving information from T-TRP 170 and / or other NT-TRP 172 and / or ED 110 can be referred to as receiving information from an interface or at least one pin. This information may include control signaling and / or data.

[0130] T-TRP 170, NT-TRP 172 and / or ED 110 may include other components, but for clarity these components are omitted.

[0131] It should be noted that, for simplicity, the term "signaling" used in this article can also be referred to as control signaling, control message, control information, or message. Signaling between a BS (such as network node 170) and a terminal or sensing device (such as ED 110), or between different terminals or sensing devices (such as ED 110i and ED 110j), can be carried in physical layer signaling (also known as dynamic signaling), which is transmitted in the physical layer control channel. For the downlink, physical layer signaling can be called downlink control information (DCI), which is transmitted in the physical downlink control channel (PDCCH). For the uplink, physical layer signaling can be called uplink control information (UCI), which is transmitted in the physical uplink control channel (PUCCH). For the sidelink, signaling between different terminals or sensing devices (such as between ED110i and ED110j) can be called sidelink control information (SCI), which is transmitted in the physical sidelink control channel (PSCCH). Signaling can be carried in higher-layer (e.g., above the physical layer) signaling, which is transmitted in the physical layer data channel. For example, downlink signaling is transmitted in the physical downlink shared channel (PDSCH), uplink signaling in the physical uplink shared channel (PUSCH), and sidelink signaling in the physical sidelink shared channel (PSSCH). Higher-layer signaling can also be called static signaling or semi-static signaling. Higher-layer signaling can also be radio resource control (RRC) protocol signaling or media access control-control element (MAC-CE) signaling. Signaling can be included in a combination of physical layer signaling and higher layer signaling.

[0132] It should be noted that in this disclosure, when "information" and "message" are different, it can be contained in a single message or in multiple separate messages.

[0133] One or more steps of the method provided in this article can be derived from... Figure 3 The corresponding unit or module provided will be executed. Figure 3 The diagram illustrates units or modules within a device (such as ED 110, T-TRP 170, or NT-TRP 172). For example, signals may be transmitted by a transmitting unit or transmitting module. Signals may be received by a receiving unit or receiving module. Signals may be processed by a processing unit or processing module. Other steps may be performed by an artificial intelligence (AI) module or a machine learning (ML) module. The corresponding units or modules may be implemented using hardware, one or more components or devices executing software, or a combination thereof. For example, one or more of these units or modules may be integrated circuits, such as a programmable FPGA, GPU, or ASIC. It should be understood that if these modules are implemented using software executed by a processor, etc., then these modules may be retrieved by the processor, wholly or partially, individually or collectively, for processing, in one or more instances, and these modules themselves may include instructions for further deployment and instantiation.

[0134] Further details regarding ED 110, T-TRP 170, and NT-TRP 172 are known to those skilled in the art. Therefore, these details are omitted herein.

[0135] One or more steps of the method provided in this article can be derived from... Figure 4 The corresponding unit or module provided will be executed. Figure 4 The diagram illustrates units or modules within a device (such as ED 110, T-TRP 170, or NT-TRP 172). For example, signals may be transmitted by a transmitting unit or transmitting module. Signals may be received by a receiving unit or receiving module. Signals may be processed by a processing unit or processing module. Other steps may be performed by an artificial intelligence (AI) module or a machine learning (ML) module. The corresponding units or modules may be implemented using hardware, one or more components or devices executing software, or a combination thereof. For example, one or more of these units or modules may be integrated circuits, such as a programmable FPGA, GPU, or ASIC. It should be understood that if these modules are implemented using software executed by a processor, etc., then these modules may be retrieved by the processor, wholly or partially, individually or collectively, for processing, in one or more instances, and these modules themselves may include instructions for further deployment and instantiation.

[0136] Further details regarding ED 110, T-TRP 170, and NT-TRP 172 are known to those skilled in the art. Therefore, these details are omitted herein.

[0137] In future wireless networks, new devices are likely to grow exponentially and possess a wide variety of functions. Furthermore, with increasingly diverse quality of service requirements, future wireless networks may see far more new applications and use cases than those present in 5G. These factors will bring highly challenging new key performance indicators (KPIs) to future wireless networks (e.g., 6G networks), thus leading to the introduction of sensing technologies and AI technologies, especially ML (deep learning), in the telecommunications field to improve system performance and efficiency.

[0138] AI / ML technology can be applied to communications, including AI / ML communication at the physical layer and at the media access control (MAC) layer. At the physical layer, AI / ML communication can be used to optimize component design and improve algorithm performance, such as in channel coding, channel modeling, channel estimation, channel decoding, modulation, demodulation, MIMO, waveform analysis, multiple access, PHY unit parameter optimization and updating, beamforming and tracking, sensing, and localization. At the MAC layer, AI / ML communication can leverage AI / ML capabilities to learn, predict, and make decisions to solve complex optimization problems using better strategies and optimal solutions. For example, it can optimize MAC functions such as intelligent TRP management, intelligent beam management, intelligent channel resource allocation, intelligent power control, intelligent spectrum utilization, intelligent modulation and coding schemes (MCS), intelligent hybrid automatic repeat request (HARQ) strategies, intelligent transmit / receive (Tx / Rx) mode adaptation, and so on.

[0139] AI / ML architectures typically consist of multiple nodes, which can be organized in centralized or distributed modes, both of which can be deployed in access networks, core networks, edge computing systems, or third-party networks. Centralized training and computing architectures are limited by potentially large communication overhead and strict user data privacy. Distributed training and computing architectures include several frameworks, such as distributed machine learning and federated learning. AI / ML architectures include intelligent controllers, which can perform as single or multiple agents based on joint optimization or individual optimization. New protocols and signaling mechanisms are needed to personalize the corresponding interface links using custom parameters to meet specific requirements, while minimizing signaling overhead and maximizing the overall system's spectral efficiency through personalized AI technologies.

[0140] Furthermore, both terrestrial and non-terrestrial networks can enable a range of new services and applications, such as earth monitoring, remote sensing, passive sensing and positioning, navigation, tracking, autonomous delivery, and mobility. Terrestrial-based and non-terrestrial-based sensing can provide intelligent context-aware networks to enhance the user experience. For example, terrestrial-based and non-terrestrial-based sensing can offer opportunities for positioning and sensing applications based on a new set of functionalities and service capabilities. Applications such as terahertz (THz) imaging and spectroscopy have the potential to provide continuous, real-time physiological information for future digital health technologies through dynamic, non-invasive, and contactless measurements. Simultaneously, simultaneous localization and mapping (SLAM) methods can not only enable advanced cross-reality (XR) applications but also enhance navigation for autonomous objects such as vehicles and drones. Moreover, in both terrestrial and non-terrestrial networks, measured channel data, as well as sensing and positioning data, can be obtained through high bandwidth, additional spectrum, dense networks, and additional light-of-sight (LOS) links. Based on this data, a radio environment map can be determined using AI / ML methods, where channel information is linked to its corresponding location or environmental information to provide an enhanced physical layer design based on the map.

[0141] A sensing coordinator is a node in the network that assists in sensing operations. These nodes can be independent nodes dedicated solely to sensing operations, or they can be other nodes (such as TRP 170, ED 110, or core network nodes) that perform sensing operations in parallel with communication transmissions. New protocols and signaling mechanisms may be needed to allow for the use of custom parameters to execute corresponding interface links to meet specific requirements, while minimizing signaling overhead and maximizing the overall system's spectral efficiency.

[0142] AI / ML and perception methods require massive amounts of data. To apply AI / ML and perception to wireless communications, increasingly more data needs to be collected, stored, and exchanged. The characteristics of wireless data extend considerably across multiple dimensions, such as from sub-6 GHz, millimeter wave to terahertz carrier frequencies, from spatial, outdoor to indoor scenes, and from text, voice to video. These data collection, processing, and usage operations are performed within a unified framework or different frameworks.

[0143] Some embodiments described herein refer to control information. Control information may also be referred to as control signaling or signaling. In some cases, control information can be transmitted dynamically, for example, in physical layer control channels such as the physical uplink control channel (PUCCH), physical uplink shared channel (PUSCH), or physical downlink control channel (PDCCH). An example of dynamically indicated control information is information sent in physical layer control signaling, such as uplink control information (UCI) sent in PUCCH or PUSCH, or downlink control information (DCI) sent in PDCCH. Dynamic indication can be an indication in a lower layer, such as physical layer / layer 1 signaling, rather than an indication in a higher layer (e.g., not in RRC signaling or MAC CE). Semi-static indication can be an indication in semi-static signaling. Semi-static signaling as used herein can refer to non-dynamic signaling, such as higher layer signaling (e.g., RRC signaling) and / or MAC CE. The dynamic signaling used in this article can refer to dynamic signaling, such as physical layer control signaling sent in the physical layer, such as DCI sent in PDCCH or UCI sent in PUCCH or PUSCH.

[0144] This disclosure discloses network management apparatus, devices, and methods applicable to various network systems, including terrestrial network systems, non-terrestrial network systems, and integrated terrestrial and non-terrestrial network systems (such as network systems where terrestrial and non-terrestrial equipment can coexist). Network management can be performed based on traffic event reporting from network devices, such as terrestrial transmission and receive points (T-TRPs).

[0145] Some aspects of this disclosure relate to traffic event reporting. For example, a network device (such as a T-TRP) can send a report indicating that a traffic event has occurred (e.g., the traffic event occurred within the coverage area served by the network device). The network device can send this report to a given network entity (such as a non-terrestrial TRP). The report can be generated based on one or more metrics and key performance indicators (KPIs). Some examples of metrics used in the report may include served cell throughput, instantaneous resource utilization, filtered resource utilization, and the number of terminal devices (e.g., user equipment (UE)) served by the network device. Therefore, a traffic event can be an event in which at least one metric is greater than or equal to, or less than or equal to, a threshold. For example, a traffic event can be considered to have occurred when served cell throughput is equal to or exceeds a certain threshold, or when instantaneous resource utilization is equal to or exceeds a certain threshold, or when filtered resource utilization is equal to or exceeds a certain threshold, or when the number of terminal devices is equal to or exceeds a certain threshold. In some implementations, the report may include information indicating the type of service measured by the network device. The type of service may include at least one of the following: enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), massive machine-type communication (mMTC), global connectivity, sensing-related services, or services associated with artificial intelligence (AI) or machine learning (ML) technologies applied to communications. In some implementations, the type of service may be determined based on the quality of service (QoS) provided by the network equipment (to be provided).

[0146] Some aspects of this disclosure relate to the configuration of traffic events or the configuration of traffic event reporting. Network devices (such as T-TRPs) can receive configuration information from the serving cell, which is used to configure the network device to determine whether to send a report indicating that a traffic event has occurred. In some implementations, this configuration information can be sent from the serving cell to the network device via a common signaling mechanism, such as a common control channel that can be shared with one or more other network devices in the network. For example, the common configuration information can be provided from the serving cell to multiple network devices via a system information block (SIB) in a multicast manner. In some implementations, the configuration information can be sent from the serving cell to a specific network device via a dedicated signaling mechanism, such as a control channel dedicated to a network device. For example, configuration information dedicated to a specific network device can be provided from the serving cell to the specific network device via a radio resource control (RRC) configuration message in a unicast manner.

[0147] In the context of cellular networks, a serving cell can refer to the geographical area where a terminal device (such as a UE or similar device) can receive, detect, and measure signals associated with its physical cell identity (PCI). This is typically associated with primary synchronization signals (PSS) and secondary synchronization signals (SSS), whose pseudo-random noise (PRN) sequences are generated based on the PCI. For example, when a terminal device detects a PSS and / or SSS with a received power greater than a certain threshold within a certain (coverage) area served by a given cell, the terminal device is considered to be within the coverage area of ​​that given cell. From the terminal device's perspective, a "serving cell" can refer to an area where one or more terminal devices (such as UEs) can camp, or it can refer to a cell where one or more network devices can monitor certain information (such as system information). In fact, the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 38.304 defines a "serving cell" as "the cell where a UE camps."

[0148] Based on the above, it can be assumed that a cell, serving cell, or beam associated with a cell / serving cell can be associated with the same PCI. Therefore, according to one possible interpretation, a cell, serving cell, beam associated with a cell, or beam associated with a serving cell can refer to any network entity that can broadcast the same PCI through its physical synchronization signals and channels (such as PSS, SSS, PBCH, and / or synchronization signal block (SSB)). Some aspects of this disclosure are described based on this possible broad interpretation.

[0149] In some implementations, a serving cell can refer to a base station that serves a coverage area and provides network services and coverage to one or more network devices. A serving cell can serve and / or correspond to a coverage area, where one or more network devices can reside or monitor certain information (such as system information, traffic-related information, power-saving commands, etc.). A serving cell can be a non-terrestrial TRP (such as airborne aircraft, spacecraft, satellites (low Earth orbit (LEO) satellites / medium Earth orbit (MEO) satellites / geostationary equatorial orbit (GEO) satellites), drones, balloons, high-altitude platform stations (HAPS), and unmanned airborne vehicles (UAVs)) or a terrestrial TRP (such as a base station). In some implementations, a network device can refer to a device that serves a coverage area and provides network services and coverage to one or more terminal devices (such as user equipment (UE)). Network equipment can serve a coverage area, where one or more terminal devices can reside, or where one or more terminal devices can monitor certain information (such as system information) within the coverage area. Network equipment can be a terrestrial TRP (such as a base station).

[0150] In some implementations, the coverage area served by the network device can be smaller than the coverage area corresponding to the serving cell. For example, the following will combine... Figure 7 Further details are provided. In some implementations, at least a portion of the coverage area served by the network device may lie within the coverage area corresponding to the serving cell. In some implementations, the coverage area served by the network device may overlap with the coverage area corresponding to the serving cell.

[0151] Some aspects of this disclosure can be implemented by any device that supports terrestrial TRPs (such as base stations) and non-terrestrial TRPs (such as airborne aircraft, spacecraft, satellites (low Earth orbit (LEO) satellites / medium Earth orbit (MEO) satellites / geostationary equatorial orbit (GEO) satellites), drones, balloons, high-altitude platform stations (HAPS), and unmanned airborne vehicles (UAVs)). However, this disclosure is not limited to devices supporting a specific wireless access network or specific wireless access technology, but can include any type of wireless access technology supporting terrestrial and / or non-terrestrial types of communication.

[0152] Furthermore, as stated above, although the various aspects of this disclosure are primarily described in some network systems (such as integrated terrestrial and non-terrestrial network systems), it should be noted that the various aspects of this disclosure are not limited to the integrated terrestrial and non-terrestrial network systems described herein, but can be more broadly applied to terrestrial network systems, non-terrestrial network systems, or other types of network systems that can use the methods, apparatus, and / or devices described herein. In other words, the various aspects of this disclosure are not limited to specific types of communication or specific wireless access technologies.

[0153] Figure 5 An exemplary network 500 is illustrated in which network devices and serving cells communicate and operate according to embodiments of the present disclosure. Network 500 may be an integrated terrestrial and non-terrestrial network system. Network 500 includes network devices 501a, 501b, 501c, 511a, 511b, and 511c. Network 500 also includes a first serving cell represented by non-terrestrial network device 502, a second serving cell represented by non-terrestrial network device 512, and a third serving cell represented by non-terrestrial network device 522. Network 500 also includes a non-terrestrial network (NTN) gateway 524, a first terrestrial network (TN) gateway 526, a second terrestrial network (TN) gateway 528, and a core network 530.

[0154] In some implementations, network devices 501a, 501b, 501c, 511a, 511b, and 511c can all be terrestrial TRPs. Network device 501a can serve coverage area 503a, one or more terminal devices ( Figure 5 (Not shown in the image) can reside within this coverage area. Similarly, as... Figure 5 As shown, other network devices 501b, 501c, 511a, 511b, and 511c can respectively serve coverage areas 503b, 503c, 513a, 513b, and 513c, and one or more terminal devices ( Figure 5 (Not shown in the image) can reside within these coverage areas. Network devices 501a, 501b, and 501c can communicate with the first serving cell via non-terrestrial network device 502, and network devices 511a, 511b, and 511c can communicate with the second serving cell via non-terrestrial network device 512. Network devices 501a, 501b, and 501c can communicate with the core network 530 via the first TN gateway 526. Alternatively, network devices 501a, 501b, and 501c can communicate with the core network 530 via the first serving cell represented by non-terrestrial network device 502 and NTN gateway 524. Network devices 511a, 511b, and 511c can communicate with the core network 530 via the second TN gateway 528. Alternatively, network devices 511a, 511b, and 511c can communicate with the core network 530 via the second serving cell represented by non-terrestrial network device 512 and NTN gateway 524.

[0155] The first, second, and third serving cells can all be part of a satellite constellation. This constellation typically includes multiple satellite orbits, each containing multiple satellites (such as non-terrestrial network devices 502, 512, and 522). Some or all of the satellites in this constellation (such as the first serving cell 502 and the second serving cell 512) can provide wireless coverage or network services to the ground (such as network devices 501a, 501b, 501c, 511a, 511b, and 511c).

[0156] This satellite constellation can communicate with the core network 530 via a dedicated satellite gateway. For example, as... Figure 5 The first serving cell, the second serving cell, and the third serving cell can communicate with the core network 530 through non-terrestrial network equipment 502, non-terrestrial network equipment 512, non-terrestrial network equipment 522, and NTN gateway 524 dedicated to the first serving cell, the second serving cell, and the third serving cell, respectively.

[0157] Figure 6Another exemplary network 600 is shown, in which network devices and serving cells communicate and operate according to embodiments of this disclosure. Network 600 may be an integrated terrestrial and non-terrestrial network system. Network 600 may be as described above and Figure 5 This is a variant of network 500 described herein. Network 600 includes network devices 601a, 601b, 601c, 611a, 611b, and 611c. Network 600 also includes a first serving cell represented by non-terrestrial network device 602, a second serving cell represented by non-terrestrial network device 612, and a third serving cell represented by non-terrestrial network device 622. Network 600 also includes an NTN gateway 624 and a core network 630.

[0158] In some implementations, network devices 601a, 601b, 601c, 611a, 611b, and 611c can all be terrestrial TRPs. Network device 601a can serve coverage area 603a, one or more terminal devices ( Figure 6 (Not shown) can reside within this coverage area. Similarly, other network devices 601b, 601c, 611a, 611b, and 611c can serve coverage areas 603b, 603c, 613a, 613b, and 613c respectively, and one or more terminal devices ( Figure 6 (Not shown in the image) can reside within these coverage areas. Network devices 601a, 601b, and 601c can communicate with the first serving cell via non-terrestrial network device 602 (e.g., using a wireless link). Figure 6 As shown, network devices 601a, 601b, and 601c can communicate with the core network 630 through a first serving cell represented by non-terrestrial network device 602, a third serving cell represented by non-terrestrial network device 622, and NTN gateway 624. Network devices 611a, 611b, and 611c can communicate with a second serving cell through non-terrestrial network device 612 (e.g., using a radio link). Figure 6 As shown, network devices 611a, 611b and 611c can communicate with the core network 630 through a second serving cell represented by non-terrestrial network device 612, a third serving cell represented by non-terrestrial network device 622 and NTN gateway 624.

[0159] like Figure 6 As shown, the first serving cell, the second serving cell, and the third serving cell can communicate with each other via non-terrestrial network device 602, non-terrestrial network device 612, and non-terrestrial network device 622 (e.g., via free-space optical links (such as lasers)).

[0160] In some implementations, the first serving cell, the second serving cell, and the third serving cell can all be part of a satellite constellation. This constellation typically includes multiple satellite orbits, each containing multiple satellites (such as non-terrestrial network devices 602, 612, and 622). Some (or all) of the satellites in this constellation (such as non-terrestrial network devices 602 and 612) can provide radio coverage or network services to terrestrial devices (such as network devices 601a, 601b, 601c, 611a, 611b, and 611c). The satellites in this constellation (such as non-terrestrial network devices 602, 612, and 622) can effectively serve as gateways for terrestrial network devices (such as network devices 601a, 601b, 601c, 611a, 611b, and 611c). The satellites in this constellation can communicate with the core network 630 via a radio link through a terrestrial NTN gateway. For example, as... Figure 6 As shown, non-terrestrial network devices 602, 612, and 622 can communicate with the core network 630 through the NTN gateway 624.

[0161] In some implementations, the NTN gateway 624 can communicate with the core network 630 via a wireless link, a wired link (such as a fiber optic link), or a combination thereof.

[0162] Figure 7 An exemplary communication link between a serving cell and a network device served by the serving cell is illustrated according to an embodiment of this disclosure. Network 700 may be an integrated terrestrial and non-terrestrial network system. Network 700 includes a first network device 701, a second network device 711, a third network device 721, and a serving cell represented by a non-terrestrial network device 702.

[0163] refer to Figure 7 The first network device 701 can serve the first coverage area 703, one or more terminal devices ( Figure 7 (Not shown) can reside within this coverage area. Similarly, the second network device 711 and the third network device 721 can serve the second coverage area 713 and the third coverage area 723 respectively, and one or more terminal devices ( Figure 7 (Not shown in the image) can reside within these coverage areas. The serving cell represented by the non-terrestrial network device 702 can serve the coverage area 704. The first network device 701, the second network device 711, and the third network device 721 can reside within this coverage area, or the first network device 701, the second network device 711, and the third network device 721 can monitor certain information (such as system information, traffic-related information, energy-saving commands, etc.) within this coverage area.

[0164] In some implementations, such as Figure 7As shown, the first coverage area 703, the second coverage area 713, and / or the third coverage area 723 may be smaller than the coverage area 704 corresponding to the serving cell represented by the non-terrestrial network device 702. In some implementations, the first coverage area 703, the second coverage area 713, and / or the third coverage area 723 may be located within the coverage area 704. In some implementations, at least a portion of the first coverage area 703, the second coverage area 713, and / or the third coverage area 723 may be located within the coverage area 704. In some implementations, the overlap between the first coverage area 703, the second coverage area 713, and / or the third coverage area 723 and the coverage area 704 may be [different from the previous implementation]. Figure 7 The differences are as follows. For example, only a portion of the first coverage area 703, the second coverage area 713, and / or the third coverage area 723 may be included within the coverage area 704, while other portions of the first coverage area 703, the second coverage area 713, and / or the third coverage area 723 may be located outside the coverage area 704.

[0165] In some implementations, the first network device 701, the second network device 711, and the third network device 721 can serve terminal devices on the ground. Figure 7 (Not shown in the diagram) and / or other devices (such as smart meters, smart traffic lights, various devices that can be considered Internet of Things (IoT) devices) and provide network services to these devices. In some cases, the first network device 701, the second network device 711, and the third network device 721 may experience certain traffic events, such as traffic surges and / or excessive network traffic (e.g., traffic spikes or exceeding a given threshold). When such traffic events occur, the first network device 701, the second network device 711, and the third network device 721 can send a report to the serving cell via the non-terrestrial network device 702. This report indicates that certain traffic events have occurred on the ground (e.g., within the first coverage area 703, the second coverage area 713, and / or the third coverage area 723). This report may be based on the amount of throughput of the served cell, instantaneous resource utilization, filtered resource utilization, the number of terminal devices served by the network devices, and / or other traffic events, etc.

[0166] In some implementations, when a traffic event occurs within a first coverage area 703, a first network device 701 can send a report to the serving cell via a non-terrestrial network device 702, indicating that the traffic event has occurred, for example, within the first coverage area 703. Similarly, when a traffic event occurs within a second coverage area 713, a second network device 711 can send a report to the serving cell via a non-terrestrial network device 702, indicating that the traffic event has occurred, for example, within the second coverage area 713. When a traffic event occurs within a third coverage area 723, a third network device 721 can send a report to the serving cell via a non-terrestrial network device 702, indicating that the traffic event has occurred, for example, within the third coverage area 723.

[0167] In some implementations, based on the occurrence of a traffic event, for example, occurring in a combined area of ​​the first coverage area 703, the second coverage area 713, and the third coverage area 723, the report can be sent to the serving cell via a non-terrestrial network device 702. For example, when a traffic event occurs (commonly) in one or more of the first coverage area 703, the second coverage area 713, and the third coverage area 723, one of the network devices 701, 711, and 721 (or other devices designated to report traffic events occurring within the first coverage area 703, the second coverage area 713, and the third coverage area 723) can send a report indicating that the traffic event has occurred within the combined area of ​​the first coverage area 703, the second coverage area 713, and the third coverage area 723.

[0168] like Figure 7As shown, the first network device 701, the second network device 711, and / or the third network device 721 can communicate with the serving cell via the non-terrestrial network device 702. In some implementations, the first network device 701, the second network device 711, and the third network device 721 can communicate with the serving cell via the non-terrestrial network device 702 and a bidirectional radio link. For ease of explanation, each bidirectional radio link between the network device and the serving cell can be considered to include a downlink and an uplink, wherein the downlink can refer to a link from the serving cell (e.g., via a non-terrestrial TRP) to the network device (e.g., a terrestrial TRP), and the uplink can refer to a link from the network device to the serving cell. In network 700, the first network device 701 can transmit to the serving cell represented by the non-terrestrial network device 702 via the uplink 705u and receive from the serving cell represented by the non-terrestrial network device 702 via the downlink 705d. Similarly, the second network device 711 can send to the serving cell represented by the non-terrestrial network device 702 via the uplink 715u and receive from the serving cell represented by the non-terrestrial network device 702 via the downlink 715d; the third network device 721 can send to the serving cell represented by the non-terrestrial network device 702 via the uplink 725u and receive from the serving cell represented by the non-terrestrial network device 702 via the downlink 725d.

[0169] It should be noted that a downlink can be different from a downstream link (DL), which can be considered as a link from the network to the terminal device. Similarly, an uplink can be different from an upstream link (UL), which can be considered as a link from the terminal device to the network.

[0170] It should also be noted that, although Figure 7 As not shown, some network devices (such as terrestrial TRPs) can establish communication connections with serving cells (such as non-terrestrial TRPs) through one-way radio links, or a combination of two-way radio links and one-way radio links.

[0171] Figure 8A signal flow diagram of an exemplary process 800 for traffic event reporting in a network according to an embodiment of this disclosure is shown. Process 800 illustrates signaling between a terrestrial TRP (T-TRP) 801 and a non-terrestrial TRP (NT-TRP) 802. In some implementations, T-TRP 801 may be one of the network devices described above or elsewhere in this disclosure, and NT-TRP 802 may be a device in one of the serving cells described above or elsewhere in this disclosure. In some implementations, NT-TRP 802 may be located within a satellite constellation and may continuously move along a satellite orbit.

[0172] In step 810, NT-TRP 802 may send signaling carrying configuration information for traffic event reporting. This configuration information may be sent from NT-TRP 802 to T-TRP 801 via a common signaling mechanism (such as a common control channel that can be shared with one or more other TRPs in the network) or a dedicated signaling mechanism (such as a control channel dedicated to T-TRP 801). This configuration information may be used to configure T-TRP 801 to determine whether to send a report indicating that a traffic event has occurred (e.g., the traffic event may have occurred within the coverage area served by T-TRP 801). Some non-limiting examples of this configuration information may include information for identifying the type of traffic event to be monitored by T-TRP 801; information indicating a threshold used to compare with monitoring data to determine whether a traffic event has occurred; information indicating the duration for which a traffic event occurs to trigger the sending of a report; and information indicating whether T-TRP 801 is specified to send a report when a traffic event has occurred.

[0173] In some implementations where NT-TRP 802 is located within a satellite constellation and continuously moves along a satellite orbit, NT-TRP 802 may send additional configuration information for traffic event reporting in step 820 via a public signaling mechanism or a dedicated signaling mechanism. In some implementations, this additional configuration information may include updates to the configuration information sent from NT-TRP 802 to T-TRP 801 in step 810. Step 820 may be optional.

[0174] In step 830, when T-TRP 801 determines that a traffic event has occurred (e.g., within the coverage area served by T-TRP 801), T-TRP 801 may send a report to NT-TRP 802 indicating that the traffic event has occurred. Whether a traffic event has occurred can be determined based on configuration information received from NT-TRP 802.

[0175] although Figure 8As not shown in the diagram, in some implementations, after receiving a report indicating that a traffic event has occurred, NT-TRP 802 can send network management-related command signaling to T-TRP 801.

[0176] although Figure 8 As not shown, in some implementations where multiple NT-TRPs, including NT-TRP 802, move along the same track, T-TRP 801 can send traffic event reports to other NT-TRPs different from NT-TRP 802, and / or receive network management-related command signaling from other NT-TRPs different from NT-TRP 802.

[0177] It should be noted that although procedure 800 shows the signaling between T-TRP 801 and NT-TRP 802, traffic event reporting can also be performed between the two T-TRPs, with one T-TRP acting as a super base station instead of NT-TRP acting as the serving cell, in a manner similar to that described above or elsewhere in this disclosure.

[0178] As described above, in various aspects of this disclosure, a serving cell (such as a non-terrestrial TRP or a terrestrial TRP used as a super base station) can support traffic management within the coverage area served by a network device (such as a terrestrial TRP). The serving cell can transmit control information messages via a control channel. These control information messages can be used to schedule configuration information, which can be used to configure the network device to determine whether to send a report indicating that a traffic event has occurred. In some implementations, the traffic event may include traffic events occurring within the coverage area served by the network device. The configuration information and its transmission will be further discussed below or elsewhere in this disclosure.

[0179] In some implementations, a report indicating that a traffic event has occurred may be sent based on whether a metric such as service throughput, resource utilization, or the number of terminal devices served by a single network device (such as terrestrial TRP) exceeds a configured threshold.

[0180] Network devices can monitor signaling from the serving cell (such as a non-terrestrial TRP operating in a given constellation diagram) and can receive signaling from the serving cell carrying configuration information for traffic event reporting. This signaling can be higher-layer signaling (such as radio resource control (RRC) signaling).

[0181] For example, network devices can monitor control channels carrying control information messages from the serving cell. These control information messages can be used to schedule the transmission of configuration information, which can then be used to configure the network device to determine whether to send traffic event reports. This configuration information can be carried within an RRC configuration message.

[0182] In some implementations, the configuration information used for traffic event reporting can be an information element (IE) (an example of such an IE could be named "TrafficEventReportConfig"), which can be carried in higher-level signaling (such as RRC signaling). This configuration information can indicate one or more metrics that need to be monitored and used to determine whether a traffic event has occurred. The following uses abstract syntax notation 1 (ASN.1) to describe an example of an abstraction or template of this configuration information, called the configuration information abstract syntax (1):

[0183]

[0184] Configuration Information Abstract Syntax (1)

[0185] In some implementations, the configuration information abstract syntax (1) or configuration information abstract (or configuration information template) may include one or more of the following parameters and their values, specifically based on the value of the parameter “trafficEventType”.

[0186] Referring to the configuration information abstract syntax (1) shown above, the parameter "trafficEventType" can carry information to identify the type of traffic event to be monitored by the network device (such as a terrestrial TRP) to determine whether a traffic event has occurred. In the configuration information abstract syntax (1), the possible values ​​for the parameter "trafficEventType" are "servedThroughput", "resourceUtilization", and "numOfUes". "servedThroughput" can indicate the throughput of the network device service, "resourceUtilization" can indicate the resource utilization of the network device, and "numOfUes" can indicate the number of terminal devices served by the network device.

[0187] The parameter “servedThroughputThreshold” can carry information indicating a threshold for “servedThroughput”, which is used to compare with monitoring data to determine (by the network device) whether a traffic event has occurred. In the configuration information abstract syntax (1), the possible values ​​for “servedThroughputThreshold” are 5 Mbps, 10 Mbps, 20 Mbps, 40 Mbps, 80 Mbps, 160 Mbps, 320 Mbps, 640 Mbps, and 1280 Mbps.

[0188] The parameter “resourceUtilizationThreshold” can carry information indicating a threshold for “resourceUtilization”, which is used to compare with monitoring data to determine (by the network device) whether a traffic event has occurred. In the configuration information abstract syntax (1), the possible values ​​for “resourceUtilizationThreshold” are 0p1, 0p2, 0p3, 0p4, 0p5, 0p6, 0p7, 0p8, and 0p9.

[0189] The parameter “numOfUesThreshold” can carry information indicating the threshold of “numOfUes”, which is used to compare with monitoring data to determine (by the network device) whether a traffic event has occurred. In the configuration information abstract syntax (1), the possible values ​​for “numOfUesThreshold” are 5k, 10k, 20k, and 40k.

[0190] The parameter “timeDuration” can carry information indicating the duration for which a traffic event occurs to trigger the (network device) to send a report. In the configuration information abstract syntax (1), the possible values ​​for “timeDuration” are 10 seconds, 30 seconds, 60 seconds, 600 seconds, and 3600 seconds.

[0191] The parameter “reportPerTrp” can carry information indicating whether a given network device is specified (or expected to be) to send a report when a traffic event has occurred. For example, the traffic event occurred within the coverage area served by the given network device. The value of “reportPerTrp” can also indicate whether a traffic event has occurred, for example, within the coverage area served by the network device. In the configuration information abstract syntax (1), “reportPerTrp” is a Boolean parameter, so the value of “reportPerTrp” can be “true” and “false” (or “0” and “1”; or “TRUE” and “FALSE”).

[0192] It should be noted that the configuration information abstract syntax (1) described above is merely an example of a configuration information abstraction or configuration information template, and the configuration information used for traffic event reporting can be based on it. Other configuration information abstractions or configuration information templates may include one or more other parameters not described above, and / or one or more parameters shown in the configuration information abstract syntax (1) may not be included in other configuration information abstractions or templates. In addition, other configuration information abstractions or configuration information templates may include one or more parameters that are the same as those included in the configuration information abstract syntax (1), but their possible values ​​may differ from the possible values ​​shown above for the configuration information abstract syntax (1).

[0193] An example of configuration information based on the abstract syntax (1) and having specific parameter values ​​is shown below, referred to as configuration information (1):

[0194]

[0195] Configuration information (1)

[0196] As shown above, configuration information (1) is used to configure the network device to monitor the throughput of the network device service and determine whether a traffic event has occurred (e.g., the measured service throughput exceeds the service throughput threshold "servedThroughputThreshold" within the timeduration configured in configuration information (1), for example, within the coverage area of ​​the network device service). According to configuration information (1), when the service throughput exceeds 10 Mbps for at least 10 seconds, the network device is triggered to send a report. In other words, when the (measured) service throughput exceeds 10 Mbps for at least 10 seconds, a traffic event can be considered to have occurred.

[0197] In some implementations, a network device may send a report to the serving cell indicating that a traffic event has occurred, for example, within the coverage area served by the network device. The network device may send a traffic event report when one or more conditions indicating that a traffic event has occurred are met. The network device may determine whether one or more conditions indicating that a traffic event has occurred are met based on configuration information received from the serving cell (such as configuration information (1)).

[0198] In some implementations, traffic event reports can be information elements (IEs) (an example of such an IE could be named "TrafficEventReport"). The following uses ASN.1 to describe an example of an abstraction or template for a report (or traffic event report), referred to as the Traffic Event Report Abstract Syntax (1):

[0199]

[0200] Abstract syntax for traffic event reporting (1)

[0201] In some implementations, the traffic event reporting abstract syntax (1) or traffic event reporting abstract (or traffic event reporting template) may include one or more of servedThroughput, resourceUtilization, numOfUes and / or other related parameters and their values, specifically based on the value of the parameter “trafficEventType” in the configuration information received from the serving cell.

[0202] Referring to the abstract syntax for traffic event reporting (1) shown above, the parameter " "It can carry information that identifies network devices (such as terrestrial TRPs), for example, the physical layer identifier of the network device. According to the traffic event reporting abstract syntax (1), the parameter " The possible values ​​for “ can be integers between 0 and 4095.

[0203] parameter" "It can carry information indicating the type of service measured by the network device. According to the traffic event reporting abstract syntax (1), the parameter " The possible values ​​for "" can be "eMBB", "URLLC", or "mMTC", which respectively indicate enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine-type communication (mMTC). This parameter can be included in other traffic event reporting abstractions (or templates). Other possible values ​​for “” could include global connectivity services, services related to sensing, or services related to artificial intelligence (AI) or machine learning (ML) technologies applied to communications, but are not indicated in the Traffic Event Reporting Abstract Syntax (1).

[0204] parameter" "It can carry information indicating the direction of traffic measured by network devices. According to the traffic event reporting abstract syntax (1), the parameter " The possible values ​​for “” can be “downward” or “upward”. It should be noted that “downward” and “upward” are different from “downlink” and “uplink” discussed above or elsewhere in this disclosure.

[0205] parameter" "It can carry information indicating the throughput of the network device within a duration configured according to the configuration information before triggering the reporting of a traffic event. The service throughput can be determined by the duration configured by the network device in the configuration information (such as the '" in the configuration information (1)). Measurements are performed within the range of ) . In the abstract syntax (1) for traffic event reporting, the parameter " The value of "" can be an integer and is understood in "megabits per second (Mbps)". According to the abstract syntax of traffic event reporting (1), the parameter " The possible values ​​for "" can be integers between 0 and 1280. Generally, in some traffic event reporting abstractions (or templates), this parameter represents the amount of data that changes over time and can be expressed in units other than Mbps.

[0206] parameter" "It can carry information indicating the resource utilization of the network device within a specified duration according to the configuration information before triggering the reported traffic event. The resource utilization can be determined by the duration configured by the network device in the configuration information (such as the '...' in the configuration information (1)." Measurements are performed within the range of ) . In the abstract syntax (1) for traffic event reporting, the parameter " The value of "" can be an integer and is interpreted as a percentage (%). According to the abstract syntax of traffic event reporting (1), the parameter " The possible values ​​for "" can be integers between 0 and 99. Generally, in some traffic event reporting abstractions (or templates), this parameter represents the resource utilization level and can be represented in other ways.

[0207] parameter" "It can carry information indicating the number of terminal devices (such as UEs) served by the network device within a duration configured according to the configuration information before triggering a traffic reporting event. The number of terminal devices served can be determined by the duration configured by the network device in the configuration information (such as the '...' in the configuration information (1)." Measurements are performed within the range of ) . In the abstract syntax (1) for traffic event reporting, the parameter " The possible values ​​for “numOfUes” can be integers between 0 and 10000. Generally, in some traffic event reporting abstractions (or templates), the possible values ​​for the parameter “numOfUes” can be integers greater than 10000.

[0208] parameter" "It can carry information indicating the service carrier frequency used by network devices to measure or monitor a given metric. For example, the parameter " "This can be the carrier frequency used to measure or monitor the throughput, resource utilization, or number of terminal devices served by the terrestrial TRP. In the Traffic Event Reporting Abstract Syntax (1), the parameter " The value of “carrierFrequency” can be an integer and is understood in “megahertz (MHz)”. According to the traffic event reporting abstract syntax (1), the possible values ​​of the parameter “carrierFrequency” can be integers between 1 and 10,000,000. Generally, in some traffic event reporting abstractions (or templates), this parameter represents the carrier frequency and can be expressed in units other than MHz.

[0209] It should be noted that the traffic event reporting abstract syntax (1) described above is merely an example of a traffic event reporting abstract or template, and traffic event reports can be based on it. Other traffic event reporting abstracts or templates may include one or more other parameters not described above, and / or one or more parameters shown in the traffic event reporting abstract syntax (1) may not be included in other traffic event reporting abstracts or templates. Furthermore, other traffic event reporting abstracts or templates may include one or more parameters that are the same as those included in the traffic event reporting abstract syntax (1), but their possible values ​​may differ from the possible values ​​shown above for the traffic event reporting abstract syntax (1).

[0210] Figure 9 An example of a network device reporting traffic events based on configuration information received from a serving cell, according to an embodiment of this disclosure, is shown. Network 900 includes a first network device 901, a second network device 911, and a serving cell represented by a non-terrestrial network device 902. The first network device 901 and the second network device 911 may be terrestrial TRPs, and the non-terrestrial network device 902 may be a non-terrestrial TRP.

[0211] refer to Figure 9 The first network device 901 can serve a first coverage area 903, where one or more machine-type devices (such as smart meters, smart traffic lights, and / or any other devices that can be considered Internet of Things (IoT) devices) can reside. Similarly, the second network device 911 can serve a second coverage area 913, where one or more UEs can reside.

[0212] like Figure 9As shown, the first network device 901 and the second network device 911 can communicate with the serving cell represented by the non-terrestrial network device 902. The first network device 901 can send traffic event reports to the serving cell represented by the non-terrestrial network device 902 via uplink 905u, and receive configuration information from the serving cell represented by the non-terrestrial network device 902 via downlink 905d. Similarly, the second network device 911 can send traffic event reports to the serving cell represented by the non-terrestrial network device 902 via uplink 915u, and receive configuration information from the serving cell represented by the non-terrestrial network device 902 via downlink 915d.

[0213] In some implementations, the first network device 901 and the second network device 911 can receive configuration information (1) from the serving cell represented by the non-terrestrial network device 902 via downlinks 905d and 915d, respectively. Based on the configuration information (1), the first network device 901 and the second network device 911 can be used to monitor the throughput of the services provided by the network devices 901 and 911, respectively. In a specific example of the traffic event described above, when the service throughput exceeds 10 Mbps for at least 10 seconds, the first network device 901 and the second network device 911 can be triggered to send traffic event reports, respectively. In other words, when the service throughput exceeds 10 Mbps for at least 10 seconds, both the first network device 901 and the second network device 911 can be considered to have experienced a traffic event. However, it should be understood that for different network devices that receive different configuration information (i.e., configuration information different from configuration information (1)), one or more thresholds for defining a traffic event may be different from the same thresholds described above.

[0214] exist Figure 9 In a specific example described herein, when the service throughput measured by the first network device 901 exceeds 10 Mbps for at least 10 seconds, the first network device 901 can send a report indicating that a traffic event has occurred to the serving cell represented by the non-terrestrial network device 902 via the uplink 905u. An example of the report sent by the first network device 901 is shown below, referred to as a traffic event report (1):

[0215]

[0216] Traffic event report (1)

[0217] Traffic event report (1) indicates that the first network device 901 reported a high traffic event for the mMTC service type. Based on traffic event report (1), the first network device 901 sends a report indicating that the identifier of the first network device 901 is "19" (" =19), the type of service measured by the first network device 901 is "mMTC" ("=19) =mMTC), the direction of the service measured by the first network device 901 is "uplink" ("=mMTC"). The first network device 901 measured a service throughput of 11 (=uplink). =11), the service carrier frequency used by the first network device 901 to measure or monitor service throughput is 5000 MHz or 5 GHz ("=11), =5000).

[0218] Similarly, when the service throughput measured by the second network device 911 exceeds 10 Mbps for at least 10 seconds, the second network device 911 can send a report indicating that a traffic event has occurred to the serving cell represented by the non-terrestrial network device 902 via the uplink 915u. An example of the report sent by the second network device 911 is shown below, referred to as a traffic event report (2):

[0219]

[0220] Traffic event report (2)

[0221] Traffic event report (2) indicates that the second network device 911 reported a high traffic event for the eMBB service type. Based on traffic event report (2), the second network device 911 sends a report indicating that the identifier of the second network device 911 is "45" (" =45), the type of service measured by the second network device 911 is "eMBB" ("=45), =eMBB), the direction of the service measured by the second network device 911 is "downlink" ("=eMBB"). The second network device 911 measured a service throughput of 13 ("=downlink), =13), the service carrier frequency used by the second network device 911 to measure or monitor service throughput is 30000 MHz or 30 GHz ("=13), =30000).

[0222] In some implementations, reports indicating that a traffic event has occurred within the coverage area can be sent based on whether a metric such as service throughput, resource utilization, or the number of terminal devices served by a network device group (e.g., a terrestrial TRP group) exceeds a configured threshold. In some implementations, it can be assumed that one or more logical network device groups exist within the network. Within each network device group, there can be one or more network devices, each of which can be configured to have a logical identifier (e.g., an integer value between 0 and 99).

[0223] In some implementations, one or more network devices within a logical network device group can monitor signaling from the serving cell (such as a non-terrestrial TRP operating in a given constellation) and can receive signaling from the serving cell carrying configuration information for traffic event reporting. This signaling can be higher-layer signaling (such as radio resource control (RRC) signaling).

[0224] For example, a group of network devices can monitor the control channel carrying control information messages originating from the serving cell. These control information messages can be used to schedule the transmission of configuration information, which can then be used to configure the network devices to determine whether to send a report indicating that a traffic event has occurred. This configuration information can be carried within an RRC configuration message.

[0225] In some implementations, the configuration information used for traffic event reporting can be an information element (IE) (an example of such an IE could be named "TrafficEventReportConfig"), which can be carried in higher-level signaling (such as RRC signaling). This configuration information can indicate one or more metrics that can be monitored by each network device in the network device group and used to determine whether a traffic event has occurred. The following describes an example of an abstraction or template of such configuration information using ASN.1, referred to as the configuration information abstract syntax (2):

[0226]

[0227] Configuration Information Abstract Syntax (2)

[0228] In some implementations, the configuration information abstract syntax (2) or configuration information abstract (or configuration information template) may include one or more of “servedThroughputThreshold”, “resourceUtilizationThreshold”, “numOfUesThreshold” and / or other related parameters and their values, in a manner similar to the configuration information abstract syntax (1).

[0229] Some parameters included in the configuration information abstract syntax (2) are similar to some parameters included in the configuration information abstract syntax (1). Specifically, the interpretation of “trafficEventType”, “servedThroughputThreshold”, “resourceUtilizationThreshold”, “numOfUesThreshold” and “timeDuration” in the configuration information abstract syntax (2) can be the same as or similar to the corresponding parameters in the configuration information abstract syntax (1).

[0230] The parameter “reportPerGroup” can carry information indicating whether a given group of network devices is specified (or expected to be) to send a report when a traffic event has occurred. For example, the traffic event occurred within a coverage area (commonly) served by the given group of network devices (all network devices) (e.g., each network device serves at least a portion of the coverage area, and all network devices in the given group collectively serve the entire coverage area). The value of “reportPerGroup” can also indicate whether a traffic event has occurred, for example, within a coverage area (commonly) served by the given group of network devices (all network devices). In the configuration information abstract syntax (2), “reportPerGroup” is a Boolean parameter, so the possible values ​​of “reportPerGroup” can be “true” and “false” (or “0” and “1”; or “TRUE” and “FALSE”).

[0231] The parameter "reportingTrpLogicalIdentity" can carry information indicating the reporting device within a given network device group that is designated to send a report when a traffic event has occurred (e.g., within the coverage area served by the given network device group). According to the configuration information abstract syntax (2), the possible values ​​for the parameter "reportingTrpLogicalIdentity" can be integers between 0 and 99. Generally, in some configuration information abstractions (or templates), it should be understood that the possible values ​​for the parameter "reportingTrpLogicalIdentity" can be integers greater than 99.

[0232] It should be noted that the configuration information abstract syntax (2) described above is merely an example of a configuration information abstraction or configuration information template, and the configuration information used for traffic event reporting can be based on it. Other configuration information abstractions or configuration information templates may include one or more other parameters not described above, and / or one or more parameters shown in the configuration information abstract syntax (2) may not be included in other configuration information abstractions or templates. In addition, other configuration information abstractions or configuration information templates may include one or more parameters that are the same as those included in the configuration information abstract syntax (2), but their possible values ​​may differ from the possible values ​​shown above for the configuration information abstract syntax (2).

[0233] An example of configuration information based on the abstract syntax (2) and having specific parameter values ​​is shown below, referred to as configuration information (2):

[0234]

[0235] Configuration Information (2)

[0236] As shown above, configuration information (2) is used to configure each network device in the network device group to monitor or measure resource utilization and determine whether a traffic event has occurred (e.g., the measured resource utilization exceeds the resource utilization threshold "resourceUtilizationThreshold" within the timeDuration configured in configuration information (2)) within the coverage area of ​​all network devices (commonly) serving the network device group. According to configuration information (2), when the resource utilization of the network device group exceeds 10% for at least 10 seconds, a report is triggered on the network device with logical identifier 0. In other words, a traffic event can be considered to have occurred when the (measured) resource utilization of the network device group exceeds 10% for at least 10 seconds within the coverage area of ​​the (common) service of the network device group.

[0237] In some implementations, a network device within a network device group, designated as a reporting device based on configuration information received from the serving cell, can send a report to the serving cell indicating that a traffic event has occurred, for example, within the coverage area served (commonly) by all network devices within the network device group. The reporting network device can send a traffic event report when one or more conditions indicating that a traffic event has occurred are met. In some implementations, the network device group can jointly determine whether one or more conditions indicating that a traffic event has occurred are met based on configuration information received from the serving cell (such as configuration information (2)).

[0238] In some implementations, traffic event reports can be information elements (IEs) (an example of such an IE could be named "TrafficEventReport"). The following uses ASN.1 to describe an example of an abstraction or template for a report (or traffic event report), referred to as the Traffic Event Report Abstract Syntax (2):

[0239]

[0240] Abstract Syntax for Traffic Event Reporting (2)

[0241] In some implementations, the traffic event reporting abstract syntax (2) or traffic event reporting abstract (or template) may include one or more of “servedThroughput”, “resourceUtilization”, “numOfUes” and / or other related parameters and their values, in a manner similar to the traffic event reporting abstract syntax (1).

[0242] Referring to the abstract syntax for traffic event reporting (2) shown above, the parameter " "It can carry information that identifies a given group of network devices (such as terrestrial TRPs). Parameters" The value of "" can be regarded as the group identifier assigned to the given network device group. According to the traffic event reporting abstract syntax (2), the parameter " The possible values ​​for "" can be integers between 0 and 999. Generally, it should be understood that in some traffic event reporting abstractions (or templates), the parameter "" The possible values ​​of “” can be integers greater than 999.

[0243] Other parameters included in the traffic event reporting abstract syntax (2) are similar to some parameters included in the traffic event reporting abstract syntax (1). Specifically, the interpretation of “trafficEventType”, “trafficDirection”, “servedThroughput”, “resourceUtilization”, “numOfUes” and “CarrierFrequency” in the traffic event reporting abstract syntax (2) can be the same as or similar to the corresponding parameters in the traffic event reporting abstract syntax (1).

[0244] It should be noted that the traffic event reporting abstract syntax (2) described above is merely an example of a traffic event reporting abstract or template, and traffic event reports can be based on it. Other traffic event reporting abstracts or templates may include one or more other parameters not described above, and / or one or more parameters shown in the traffic event reporting abstract syntax (2) may not be included in other traffic event reporting abstracts or templates. Furthermore, other traffic event reporting abstracts or templates may include one or more parameters that are the same as those included in the traffic event reporting abstract syntax (2), but their possible values ​​may differ from the possible values ​​shown above for the traffic event reporting abstract syntax (2).

[0245] Figure 10 An example is shown of a reporting network device within a network device group according to an embodiment of the present disclosure reporting traffic events based on configuration information received from a serving cell. Network 1000 includes network devices 1001a, 1001b, 1001c, 1001d, 1011a, 1011b, 1011c and a serving cell represented by a non-terrestrial network device 1002. Network devices 1001a, 1001b, 1001c, and 1001d can be collectively referred to as a first network device group 1001, and network devices 1011a, 1011b, and 1011c can be collectively referred to as a second network device group 1011. The first network device group 1001 and the second network device group 1011 can be terrestrial TRPs, and the non-terrestrial network device 1002 can be a non-terrestrial TRP.

[0246] refer to Figure 10 Network device 1001a can serve coverage area 1003a, where one or more machine-type devices (such as smart meters, smart traffic lights, and / or any other devices that can be considered Internet of Things (IoT) devices) can reside. Similarly, network devices 1001b, 1001c, and 1001d can serve coverage areas 1003b, 1003c, and 1003d, respectively. One or more machine-type devices can reside in coverage areas 1003b, 1003c, and 1003d, respectively. Coverage areas 1003a, 1003b, 1003c, and 1003d can be collectively considered as the first coverage area 1003. Therefore, one or more machine-type devices (such as smart meters, smart traffic lights, and / or any other devices that can be considered Internet of Things (IoT) devices) can reside in the first coverage area 1003.

[0247] Similarly, network devices 1011a, 1011b, and 1011c can serve coverage areas 1013a, 1013b, and 1013c, respectively. One or more UEs can camp within coverage areas 1013a, 1013b, and 1013c, respectively. Coverage areas 1013a, 1013b, and 1013c can be collectively considered as a second coverage area 1013. Therefore, one or more UEs can camp within the second coverage area 1013.

[0248] like Figure 10 As shown, the first network device group 1001 and the second network device group 1011 can establish a communication connection with the serving cell through the non-terrestrial network device 1002. Specifically, network device 1001a can send traffic event reports to the serving cell represented by the non-terrestrial network device 1002 via uplink 1005u, and receive configuration information from the serving cell represented by the non-terrestrial network device 1002 via downlink 1005d. Similarly, network device 1011a can send traffic event reports to the serving cell represented by the non-terrestrial network device 1002 via uplink 1015u, and receive configuration information from the serving cell represented by the non-terrestrial network device 1002 via downlink 1015d. Although Figure 10 It is not explicitly described in the text, but in some implementations, other network devices 1001b, 1001c, 1001d, 1011b and 1011c can communicate with the serving cell through the non-terrestrial network device 1002. That is, these network devices can all receive configuration information from the serving cell through the downlink.

[0249] In some implementations, network devices 1001a and 1011a can receive configuration information (2) from the serving cell represented by non-terrestrial network device 1002 via downlinks 1005d and 1015d, respectively. In some implementations, network devices 1001b, 1001c, and 1001d can receive configuration information (2) from the serving cell represented by non-terrestrial network device 1002 or from network device 1001a. Similarly, in some implementations, network devices 1011b and 1011c can receive configuration information (2) from the serving cell represented by non-terrestrial network device 1002 or from network device 1011a.

[0250] Based on the configuration information (2), the first network device group 1001 and the second network device group 1011 can be used to monitor the resource utilization of the first network device group 1001 and the second network device group 1011 respectively.

[0251] exist Figure 10In this context, it is assumed that the logical identifiers of network device 1001a and network device 1011a are both 0. Therefore, based on configuration information (2), network device 1001a can be considered as a reporting network device that sends a report when a traffic event has occurred within the coverage area of ​​the service of the first network device group 1001. Similarly, based on configuration information (2), network device 1011a can be considered as a reporting network device that sends a report when a traffic event has occurred within the coverage area of ​​the service of the second network device group 1011. For a specific set of thresholds defining traffic events, when the (measured) resource utilization of the first network device group 1001 exceeds 10% for at least 10 seconds within the first coverage area 1003, network device 1001a can be triggered to send a traffic event report to the serving cell via non-terrestrial network device 1002; when the (measured) resource utilization of the second network device group 1011 exceeds 10% for at least 10 seconds within the coverage area 1013, network device 1011a can be triggered to send a traffic event report to the serving cell via non-terrestrial network device 1002. In other words, when the resource utilization exceeds 10% for at least 10 seconds within the corresponding coverage area, both the first network device group 1001 and the second network device group 1011 can be considered as having experienced a traffic event. However, it should be understood that the thresholds for defining traffic events may differ for different network device groups that receive different configuration information (i.e., configuration information different from configuration information (2)), and may differ from the same thresholds described above.

[0252] exist Figure 10 In a specific example described, when the resource utilization of the first network device group 1001 exceeds 10% for at least 10 seconds within the first coverage area 1003, network device 1001a can send a report indicating that a traffic event has occurred to the serving cell represented by the non-terrestrial network device 1002 via uplink 1005u. An example of the report sent by network device 1001a is shown below, referred to as a traffic event report (3):

[0253]

[0254] Traffic event report (3)

[0255] Traffic event report (3) indicates that network device 1001a reported a high traffic event for the mMTC service type. Based on traffic event report (3), network device 1001a sends a report indicating that the identifier of the first network device group 1001, including network device 1001a, is "17" ("groupIdentity" = 17), and the type of service measured by the first network device group 1001 is "mMTC" ("groupIdentity" = 17). =mMTC), the direction of the service measured by the first network device group 1001 is "uplink" ("=mMTC"). The resource utilization rate measured for the first network device group 1001 (all network devices) is 34%. =34), the service carrier frequency used by the first network equipment group 1001 to measure or monitor resource utilization is 5000 MHz or 5 GHz ("=34), =5000).

[0256] Similarly, continuing the example above, when the resource utilization rate of the second network device group 1011 exceeds 10% for 10 seconds within the second coverage area 1013, network device 1011a can send a report indicating that a traffic event has occurred to the serving cell represented by the non-terrestrial network device 1002 via uplink 1015u. An example of the report sent by network device 1011a is shown below, referred to as a traffic event report (4):

[0257]

[0258] Traffic event report (4)

[0259] Traffic event report (4) indicates that network device 1011a reported a high traffic event for the eMBB service type. Based on traffic event report (4), network device 1011a sends a report indicating that the identifier of the second network device group 1011, including network device 1011a, is "29" ("groupIdentity" = 29), and the type of service measured by the second network device group 1011 is "mMTC" ("29"). =mMTC), the direction of the service measured by the second network device group 1011 is "downlink" ("=mMTC"). The resource utilization rate measured for the second network device group 1011 (all network devices) was 52%. =52), the service carrier frequency used by the second network equipment group 1011 to measure or monitor resource utilization is 30000 MHz or 30 GHz ("=52), =30000).

[0260] In some implementations, configuration information used to configure network devices to determine whether to send traffic event reports can be sent to terrestrial network devices via a common control channel. This common control channel can be shared with one or more other network devices in the network. (See below and other parts of this disclosure.) Figure 11 This describes the transmission of configuration information via a common control channel.

[0261] Figure 11An example of configuration information transmission via a common control channel according to an embodiment of this disclosure is shown. Network 1100 includes network devices 1101a, 1101b, 1101c, 1101d, 1111a, 1111b, 1111c, and a serving cell represented by non-terrestrial network device 1102. For ease of explanation, it is assumed that network devices 1101a, 1101b, 1101c, 1101d, 1111a, 1111b, 1111c are divided into two groups. Network devices 1101a, 1101b, 1101c, and 1101d can be collectively referred to as the first network device group 1101, and network devices 1111a, 1111b, and 1111c can be collectively referred to as the second network device group 1111. The first network device group 1101 and the second network device group 1111 can be terrestrial TRPs, and the non-terrestrial network device 1102 can be a non-terrestrial TRP.

[0262] refer to Figure 11 First network device 1101a can serve coverage area 1103a, where one or more terminal devices (now shown) can reside. Similarly, network devices 1101b, 1101c, and 1101d can serve coverage areas 1103b, 1103c, and 1103d, respectively. One or more terminal devices can reside in coverage areas 1103b, 1103c, and 1103d, respectively. Coverage areas 1103a, 1103b, 1103c, and 1103d can be collectively considered as the first coverage area 1103. Similarly, network devices 1111a, 1111b, and 1111c can serve coverage areas 1113a, 1113b, and 1113c, respectively. One or more terminal devices can reside in coverage areas 1113a, 1113b, and 1113c, respectively. Coverage areas 1113a, 1113b and 1113c can be collectively regarded as the second coverage area 1113.

[0263] In some implementations, one or more serving cells in a constellation (e.g., may include non-terrestrial TRPs) can provide network services and coverage for one or more network devices on the ground. In network 1100, the serving cell represented by non-terrestrial network device 1102 can be located within the constellation and can continuously move along its orbit. Serving cell 1102 can provide network services and coverage for first network device group 1101 and second network device group 1111. In other words, the serving cell represented by non-terrestrial network device 1102 can serve coverage area 1104, where first network device group 1101 and second network device group 1111 can reside, or where first network device group 1101 and second network device group 1111 can monitor certain information (such as system information, traffic-related information, power-saving commands, etc.) within the coverage area. Coverage area 1104 may include first coverage area 1103 and second coverage area 1113.

[0264] The serving cell represented by non-terrestrial network device 1102 can send control information messages to the first network device group 1101 and the second network device group 1111. The first network device group 1101 and the second network device group 1111 can monitor the control channel carrying control information messages originating from the serving cell represented by non-terrestrial network device 1102. These control information messages can be used to schedule the transmission of configuration information, which configures the first network device group 1101 and / or the second network device group 1111 to perform traffic event reporting. The control information messages originating from the serving cell represented by non-terrestrial network device 1102 can be detected and decoded by the first network device group 1101 and the second network device group 1111.

[0265] In some implementations, the cyclic redundancy check (CRC) of these control information messages can be scrambled using a radio network temporary identifier (RNTI). In other words, each control information message may include a CRC scrambled using an RNTI. In some implementations, the RNTI may be a multicast RNTI (such as a traffic event monitoring RNTI (TM-RNTI)). In some implementations, TM-RNTI enables network devices (such as terrestrial TRPs) to monitor and / or detect physical layer control channels carrying control information messages. These control information messages can be used to schedule physical layer data channels carrying traffic event monitoring signaling. In other words, as described above, these control information messages can be used to schedule the transmission of configuration information.

[0266] In a specific example, to monitor and / or detect physical layer control channels carrying control information messages, the first network device group 1101 can be configured to use TM-RNTI=0xfff0, and the second network device group 1111 can be configured to use TM-RNTI=0xfff1. In some implementations, TM-RNTI can be a 16-bit RNTI in hexadecimal representation. A certain range of values ​​can be assigned or reserved for the RNTI of the physical layer control channel. For example, the following TM-RNTI values ​​can be reserved for control information messages carried in the control channel: 0xfff0; 0xfff1; 0xfff2; 0xfff3; 0xfff4; 0xfff5; 0xfff6; 0xfff7; 0xfff8; 0xfff9; 0xfffa; 0xfffb; 0xfffc; 0xfffd; 0xfffe. It should be noted that the values ​​reserved for TM-RNTI can differ from the exemplary values ​​above and can vary depending on the network operator.

[0267] refer to Figure 11 The first network device group 1101 can monitor the physical layer control channel carrying control information messages. The control information message may include a CRC scrambled using multicast TM-RNTI. The multicast TM-RNTI scrambled using the CRC of the control information message can be “0xfff0”. The first network device group 1101 can receive configuration information from the serving cell represented by the non-terrestrial network device 1102 according to the scheduling of the control information message. In some implementations, the configuration information may be carried on a system information block (SIB), such as a SIB trafficevent monitoring (SIB-TM) message. In one example, the SIB-TM message received by the first network device group 1101 may carry configuration information, such as an information element (IE) (an example of such an IE may be named “TrafficEventReportConfig”). An example of the configuration information in the SIB-TM message received by the first network device group 1101 is shown below and is called configuration information (3):

[0268]

[0269] Configuration information (3)

[0270] Configuration information (3) configures the first network device group 1101 to monitor the throughput of the service provided by the first network device group 1101 and determine whether a traffic event has occurred. The service throughput threshold is set to 10 Mbps and the duration is set to 30 seconds. Therefore, when the (measured) service throughput exceeds 10 Mbps and lasts for at least 30 seconds, it can be considered that a traffic event has occurred within the coverage area of ​​the service provided by the first network device group 1101. According to configuration information (3), when a traffic event has occurred (i.e., when the (measured) service throughput exceeds 10 Mbps and lasts for at least 30 seconds), the network device with logical identifier 0 in the first network device group 1101 is triggered to send a report.

[0271] Similar to the first network device group 1101, the second network device group 1111 can monitor the physical layer control channel carrying control information messages. This control information message may include a CRC scrambled using a multicast TM-RNTI. The multicast TM-RNTI scrambled using the CRC of the control information message can be “0xfff1”. The second network device group 1111 can receive configuration information from the serving cell 1102 according to the scheduling of the control information messages. In some implementations, this configuration information can be carried on a system information block (SIB), for example, a SIB traffic event monitoring (SIB-TM) message. In one example, the SIB-TM message received by the second network device group 1111 may carry configuration information, such as an information element (IE) (an example of such an IE could be named “TrafficEventReportConfig”). An example of the configuration information in the SIB-TM message received by the second network device group 1111 is shown below, referred to as configuration information (4):

[0272]

[0273] Configuration information (4)

[0274] Configuration information (4) configures the second network device group 1111 to monitor the throughput of the service provided by the second network device group 1111 and determine whether a traffic event has occurred. The service throughput threshold is set to 40 Mbps and the duration is set to 10 seconds. Therefore, when the (measured) service throughput exceeds 40 Mbps for at least 10 seconds, it can be considered that a traffic event has occurred within the coverage area of ​​the service provided by the second network device group 1111. According to configuration information (4), when a traffic event has occurred (i.e., when the (measured) service throughput exceeds 40 Mbps for at least 10 seconds), the network device with logical identifier 0 in the second network device group 1111 is triggered to send a report.

[0275] In some implementations, a one-to-one association can be established between network device groups and TM-RNTIs. For example, the first network device group 1101 and the second network device group 1111 can each use their respective TM-RNTIs to monitor traffic event monitoring signaling messages carrying corresponding configuration information. The association between network device groups and TM-RNTIs can be changed based on the configuration provided by the network operator and / or satellite constellation.

[0276] In some implementations, configuration information used to configure network devices to determine whether to send traffic event reports can be sent to the terrestrial network devices via a dedicated control channel. This dedicated control channel can be a control channel dedicated to a specific network device or a group of network devices. The following section combines... Figure 12 The description refers to the transmission of configuration information via a dedicated control channel.

[0277] Figure 12 An example of configuration information transmission via a dedicated control channel according to an embodiment of this disclosure is shown. Network 1200 includes network devices 1201, 1211, 1221 and a serving cell represented by non-terrestrial network device 1202. Network devices 1201, 1211, and 1221 may be terrestrial TRPs, and non-terrestrial network device 1202 may be a non-terrestrial TRP. Network device 1201 may serve coverage area 1203, where one or more terminal devices (now shown) may reside. Similarly, network devices 1211 and 1221 may serve coverage areas 1213 and 1223, respectively. One or more terminal devices may reside in coverage areas 1213 and 1223, respectively.

[0278] In some implementations, one or more serving cells in a constellation (such as non-terrestrial TRPs) can provide network services and coverage for one or more network devices on the ground. In network 1200, the serving cell represented by non-terrestrial network device 1202 and one or more other serving cells ( Figure 12 (Not shown in the diagram) can be located within a constellation and can continuously move along the same orbit. The serving cell represented by non-terrestrial network device 1202, as well as one or more other serving cells, can provide network services and coverage for network devices 1201, 1211, and 1221. In other words, the serving cell represented by non-terrestrial network device 1202 can serve coverage area 1204, and network devices 1201, 1211, and 1221 can reside within this coverage area, or network devices 1201, 1211, and 1221 can monitor certain information (such as system information, traffic-related information, energy-saving commands, etc.) within this coverage area. Coverage area 1204 may include coverage areas 1203, 1213, and 1223.

[0279] In some implementations, network devices 1201, 1211, and 1221 can be deployed based on one or more of the network operator’s plans.

[0280] In some implementations, network devices 1201, 1211, and 1221, the serving cell represented by non-terrestrial network device 1202, and one or more other serving cells ( Figure 12 (Not shown in the diagram) can run based on a protocol stack (such as a control plane protocol stack). This protocol stack may include radio resource control (RRC) protocol, packet data convergence protocol (PDCP), radio link control (RLC) protocol, medium access control (MAC) protocol, and physical layer interface (PHY). Figure 12 As shown, in the protocol stack of a network device and the protocol stack of the serving cell, the RRC protocol can be located at the top of the protocol stack, above the PDCP. The PDCP can be located below the RRC protocol, above the RLC protocol. The RLC protocol can be located below the PDCP protocol, above the MAC protocol. The MAC protocol can be located below the RLC protocol, above the PHY protocol. The PHY layer can be located below the MAC protocol, forming the bottom layer of the protocol stack.

[0281] In some implementations, configuration information can be sent from the serving cell to the network devices associated with that configuration information via Radio Resource Control (RRC) configuration messages. For traffic event reporting, the serving cell can send RRC signaling to the relevant network devices (those associated with the configuration information carried in the RRC signaling). This allows individual network devices (such as each of network devices 1201, 1211, and 1221) to be configured via dedicated RRC configuration messages. For example, as... Figure 12 As shown, the serving cell represented by the non-terrestrial network device 1202 can send a dedicated RRC configuration message 1210 to the network device 1211, which includes configuration information for use by the network device 1211.

[0282] Figure 13 This is a signal flow diagram of an exemplary network management process according to examples of this disclosure.

[0283] The exemplary process 1300 includes steps 1305, 1310, 1320, 1325, 1330, 1335, 1340, 1345, 1350, 1360, and 1365. Some of these steps may be optional. It should be understood that in some implementations, the order of one or more steps 1305, 1310, 1320, 1325, 1330, 1335, 1340, 1345, 1350, 1360, and 1365 may be changed.

[0284] In step 1305, the serving cell 1302 can send a control information message to the network device 1301 via a control channel. This control information message can be used to schedule the transmission of configuration information. This configuration information can be used to configure the network device 1301 to determine whether to send a report indicating that a traffic event has occurred. In other words, this configuration information can be used by the network device 1301 to determine whether to send a report indicating that a traffic event has occurred.

[0285] In step 1310, network device 1301 can monitor the control channel and receive control information messages from serving cell 1302 through the control channel.

[0286] In some implementations, the control channel can be a common control channel shared with one or more other network devices in the network. In some implementations where the control channel is a common control channel, configuration information can be carried on a system information block (SIB). In some implementations where the control channel is a common control channel, the control information message may include a cyclic redundancy check (CRC) scrambled using a radio network temporary identifier (RNTI).

[0287] In some implementations, the control channel can be a control channel dedicated to network device 1301. In some implementations where the control channel is dedicated to network device 1301, configuration information can be carried in radio resource control (RRC) configuration messages.

[0288] In some implementations, network device 1301 may be a first terrestrial transmission and receive point (T-TRP). In some implementations, serving cell 1302 may be a second T-TRP or a first non-terrestrial transmission and receive point (NT-TRP).

[0289] In some implementations, network device 1301 may serve a first coverage area. In some implementations, serving cell 1302 may correspond to a second coverage area. In some implementations, the first coverage area may be smaller than the second coverage area. In some implementations, at least a portion of the first coverage area may be located within the second coverage area. In some implementations, the first coverage area may overlap with the second coverage area.

[0290] In step 1320, network device 1301 may receive configuration information from serving cell 1302, wherein the configuration information is used to configure network device 1301 to determine whether to send a report indicating that a traffic event has occurred. This configuration information can be used by network device 1301 to determine whether to send a report indicating that a traffic event has occurred.

[0291] In some implementations, the configuration information may include at least one of the following: information for identifying the type of traffic event to be monitored by network device 1301; information indicating a threshold for the type of traffic event, wherein the threshold is used to compare with monitoring data to determine whether a traffic event has occurred (for network device 1301); information indicating the duration for which a traffic event occurs to trigger (network device 1301) to send a report; information indicating whether network device 1301 is specified to send a report when a traffic event has occurred; information indicating whether a network device group including network device 1301 is specified to send a report when a traffic event has occurred; or information indicating the reporting device within the network device group specified to send a report when a traffic event has occurred. In some implementations, the type of traffic event to be monitored by network device 1301 may be related to at least one of the following: the service throughput of network device 1301; the resource utilization of network device 1301; or the number of terminal devices served by network device 1301. "Specified" in this document refers to the following scenario: a given T-TRP within a T-TRP group is assigned the task / responsibility of reporting traffic events on behalf of the entire group. For example, T-TRP#1 is responsible for sending reports to NT-TRP if... If a traffic event is triggered, it will still be reported by T-TRP#1.

[0292] In some implementations where serving cell 1302 is the first NT-TRP, serving cell 1302 can send configuration information 1325 to a second NT-TRP 1303, which is different from the first NT-TRP. The second NT-TRP 1303 can be located on a first track where serving cell 1302 (the first NT-TRP) is located, or on a second track different from the first track. The first track and the second track can each provide coverage for network device 1301.

[0293] although Figure 13 Unless explicitly described, in some embodiments where serving cell 1302 is the first NT-TRP, serving cell 1302 can receive configuration information from a third NT-TRP different from the first NT-TRP (such as serving cell 1302). The first NT-TRP (such as serving cell 1302) and the third NT-TRP can be on the same or different tracks, each track providing coverage for network device 1301. The third NT-TRP can be the second NT-TRP 1303 described above, or the third NT-TRP can be different from the second NT-TRP 1303.

[0294] In some implementations, in step 1330, the serving cell 1302 can send a second control information message to the network device 1301 via a second control channel. In some embodiments, the second control channel may be the same as the control channel used in steps 1305 and 1301. In some implementations, the second control channel may be different from the control channel used in steps 1305 and 1310. The second control information message can be used to schedule the transmission of additional configuration information. This additional configuration information can be used (by the network device 1301) to determine whether to send a report indicating that a traffic event has occurred.

[0295] In some implementations, in step 1335, network device 1301 can monitor a second control channel carrying a second control information message and receive a second control information message from serving cell 1302 through the second control channel.

[0296] Steps 1330 and 1335 can be similar to steps 1305 and 1310 described above.

[0297] In some implementations, in step 1340, for example after monitoring the second control channel, network device 1301 may receive additional configuration information, which is used to determine whether to send a report indicating that a traffic event has occurred. Network device 1301 may receive this additional configuration information from serving cell 1302. In some implementations, the additional configuration information may include an update to the configuration information sent from serving cell 1302 to network device 1301 in step 1320.

[0298] In some implementations where serving cell 1302 is the first NT-TRP, serving cell 1302 may send additional configuration information (1345) to a second NT-TRP 1303, which is different from the first NT-TRP. In some implementations, this additional configuration information may include an update to the configuration information sent from serving cell 1302 to the second NT-TRP 1303 in step 1325. As described above, the second NT-TRP 1303 may be located on a first track where serving cell 1302 (the first NT-TRP) is located, or on a second track different from the first track. The first track and the second track may each provide coverage for network device 1301.

[0299] although Figure 13 Unless explicitly described, in some implementations where serving cell 1302 is the first NT-TRP, serving cell 1302 can receive additional configuration information from a third NT-TRP different from the first NT-TRP (such as serving cell 1302). As mentioned above, the first NT-TRP (such as serving cell 1302) and the third NT-TRP can be on the same or different tracks, each track providing coverage for network device 1301. The third NT-TRP can be the second NT-TRP 1303 described above, or the third NT-TRP can be different from the second NT-TRP 1303.

[0300] Steps 1340 and 1345 can be similar to steps 1320 and 1325 described above.

[0301] In step 1350, network device 1301 may determine, based on configuration information, whether one or more conditions indicating that a traffic event has occurred are met.

[0302] In steps 1360 and / or 1365, when one or more conditions indicating that a traffic event has occurred are met, network device 1301 may send a report indicating that a traffic event has occurred.

[0303] In some implementations, the report may include at least one of the following: information identifying network device 1301; information identifying a group of network devices including network device 1301; information indicating the type of service measured by network device 1301; information indicating the direction of the service measured by network device 1301; information indicating the traffic event data measured by network device 1301 according to configuration information before triggering the reporting of a traffic event; or information indicating the service carrier frequency measured and / or monitored by network device 1301. In some implementations, the type of service measured by network device 1301 may be at least one of the following: enhanced mobile broadband (eMBB) service, ultra-reliable low-latency communication (URLLC) service, massive machine-type communication (mMTC) service, global connectivity service, sensing-related service, or service associated with artificial intelligence (AI) or machine learning (ML) technologies applied to communication.

[0304] In some implementations, network device 1301 can send a 1360 report to serving cell 1302, and network device 1301 can receive configuration information from the serving cell in step 1320.

[0305] In some implementations where the serving cell 1302 is the first NT-TRP, network device 1301 can send a 1360 report to the serving cell 1302 (i.e., the first NT-TRP), or send a 1365 report to a second NT-TRP 1303 that is different from the first NT-TRP.

[0306] In some implementations where network device 1301 can send reports to serving cell 1302 or a second NT-TRP 1303 different from the first NT-TRP, serving cell 1302 and the second NT-TRP 1303 may be on the same track. In some implementations where network device 1301 can send reports to serving cell 1302 or a second NT-TRP 1303 different from the first NT-TRP, serving cell 1302 and the second NT-TRP 1303 may be on one or more different tracks, each track providing coverage for network device 1301.

[0307] In some implementations, traffic management can be performed as part of a network energy management strategy, where traffic management is based on available "traffic credits" for a given network device (e.g., a T-TRP) or a group of network devices (e.g., a T-TRP group). In some implementations, a traffic credit can be defined as a numerical value corresponding to the number of bits transmitted by the network device (e.g., a T-TRP) in the DL direction. Each traffic credit can correspond to a given energy consumption (e.g., in joules) or a given power consumption (e.g., in watts, where 1 watt equals 1 joule per second) of the network device (e.g., a T-TRP). Similarly, in some implementations, a traffic credit can be defined as a numerical value corresponding to the number of bits received by the network device (e.g., a T-TRP) in the UL direction. In the first example, a traffic credit could be defined as: the traffic credit corresponds to 1 billion bits of traffic transmitted over the air interface in the DL direction (e.g., by a terrestrial TRP). In the second example, a traffic credit can be defined as: the traffic credit corresponds to 1 billion bits of traffic transmitted over the air interface in the DL direction (e.g., by a terrestrial TRP group). In the third example, a traffic credit can be defined as: the traffic credit corresponds to bit traffic transmitted over the air interface in the DL direction, with an energy consumption of 1 million joules for this traffic (e.g., generated by a terrestrial TRP). In the fourth example, a traffic credit can be defined as: the traffic credit corresponds to bit traffic transmitted over the air interface in the DL direction, with an energy consumption of 1 million joules for this traffic (e.g., generated by a terrestrial TRP group). In the fifth example, a traffic credit can be defined as: the traffic credit corresponds to 1 billion bits of traffic transmitted over the air interface in the DL direction within an eMBB network slice (e.g., by a terrestrial TRP). In the sixth example, a traffic credit can be defined as: the traffic credit corresponds to 1 billion bits of traffic transmitted over the air interface in the DL direction within an mMTC network slice (e.g., by a terrestrial TRP). In the seventh example, a traffic credit can be defined as: the traffic credit corresponds to 1 billion bits of traffic transmitted over the air interface in the DL direction (e.g., by a terrestrial TRP) within a URLLC network slice. In the eighth example, a traffic credit can be defined as: the traffic credit corresponds to 1 billion bits of traffic transmitted over the air interface in the UL direction (e.g., by a terrestrial TRP). In the ninth example, a traffic credit can be defined as: the traffic credit corresponds to 1 billion bits of traffic transmitted over the air interface in the UL direction (e.g., by a group of terrestrial TRPs). In the tenth example, a traffic credit can be defined as: the traffic credit corresponds to 1 billion bits of traffic transmitted over the air interface in the DL and / or UL directions (e.g., by a terrestrial TRP). In the eleventh example, a traffic credit can be defined as: the traffic credit corresponds to 1 billion bits of traffic transmitted over the air interface in the DL and / or UL directions (e.g., by a group of terrestrial TRPs).For energy credits, other values ​​or definitions can be envisioned and considered. Other combinations of the examples above can be envisioned and considered. Flow credits can also be referred to as "flow quanta," "flow units," and / or other similar terms.

[0308] In some implementations, network devices such as terrestrial TRPs can possess "traffic credit accounts," through which they hold and / or store traffic credits. In one example, traffic credits can be associated with network slices of the following types: for example, enhanced Mobile Broadband (eMBB), ultra-reliable low-latency communications (URLLC), massive machine-type communications (mMTC), public safety, etc. In another example, traffic credit accounts can be associated with network slices of the following types: for example, eMBB, URLLC, mMTC, public safety. In yet another example, the traffic credit accounts of network devices (such as those of terrestrial TRPs) can be configured via higher-level signaling (such as RRC signaling).

[0309] In some implementations, the configuration information used for traffic event reporting can be an information element (IE) (an example of such an IE could be named "TrafficEventReportConfig"), which can be carried in higher-level signaling (such as RRC signaling). This configuration information can indicate one or more metrics that can be monitored and used to determine whether a traffic event has occurred based on the available traffic credits of a given network device (such as T-TRP) or a group of network devices (such as a T-TRP group). The following describes an example of an abstraction or template of such configuration information using ASN.1, referred to as the configuration information abstract syntax (3):

[0310]

[0311] Configuration Information Abstract Syntax (3)

[0312] Referring to the configuration information abstract syntax (3) shown above, the parameter “trafficEventType” can carry information to identify the type of traffic event to be monitored by the network device (such as terrestrial TRP) in order to determine whether a traffic-related event has occurred. In the configuration information abstract syntax (3), the possible values ​​of the parameter “trafficEventType” are “servedThroughput”, “resourceUtilization”, “numOfUes”, “trafficCreditsAboveThreshold”, “trafficCreditsExpired”, “trafficCreditsInsideGroupAboveThreshold”, and “trafficCreditsInsideGroupExpired”. "ServedThroughput" indicates the service throughput of a network device; "ResourceUtilization" indicates the resource utilization of a network device; "NumOfUes" indicates the number of terminal devices served by a network device; "TrafficCreditsAboveThreshold" indicates that the measured traffic credit usage has exceeded the network device's threshold; "TrafficCreditsExpired" indicates that the measured traffic credit usage has exceeded the maximum traffic credit usage; "TrafficCreditsInsideGroupAboveThreshold" indicates that the measured traffic credit usage has exceeded the threshold of a network device group (such as a terrestrial TRP group); and "TrafficCreditsInsideGroupExpired" indicates that the measured traffic credit usage has exceeded the maximum traffic credit usage of a network device group (such as a terrestrial TRP group).

[0313] In some implementations, the configuration information abstract syntax (3) shown above may include the parameter "trafficCreditThreshold". The parameter "trafficCreditThreshold" can carry a value used to set a threshold, which the network device can compare with the traffic credit value held by the network device (such as a single terrestrial TRP) or a group of network devices (such as a group of terrestrial TRPs). In the configuration information abstract syntax (3), the possible values ​​of "trafficCreditThreshold" can be integers between 10 and 1,000,000,000.

[0314] In some implementations, the configuration information abstract syntax (3) shown above may include the parameter “maxTrafficCredit”. The parameter “maxTrafficCredit” may carry information indicating the maximum traffic credit value configured for use by a network device (such as a terrestrial TRP) for wireless communication (such as sending and / or receiving bits over the air interface). In the configuration information abstract syntax (1), the possible values ​​of “maxTrafficCredit” can be integers between 10 and 1,000,000,000.

[0315] Some parameters included in the configuration information abstract syntax (3) are similar to those included in the configuration information abstract syntax (1) or configuration information abstract syntax (2). Specifically, the interpretation of “reportPerGroup” and “reportingTrpLogicalIdentity” in the configuration information abstract syntax (3) can be the same as or similar to the corresponding parameters in the configuration information abstract syntax (1) or configuration information abstract syntax (2).

[0316] It should be noted that the configuration information abstract syntax (3) described above is merely an example of a configuration information abstraction or configuration information template, and the configuration information used for energy consumption event reporting can be based on this. Other configuration information abstractions or configuration information templates may include one or more other parameters not described above, and / or one or more parameters shown in the configuration information abstract syntax (3) may not be included in other configuration information abstractions or templates. In addition, other configuration information abstractions or configuration information templates may include one or more parameters that are the same as those included in the configuration information abstract syntax (3), but their possible values ​​may differ from the possible values ​​shown above for the configuration information abstract syntax (3).

[0317] In some implementations, a report indicating that a traffic event has occurred can be sent to the serving cell based on the available traffic credits of a given network device (such as a T-TRP) or a network device in a given group of network devices, designated as the reporting device according to the configuration information received from the serving cell. In some implementations, this traffic event report can be an information element (IE) (an example of which could be named "TrafficEventReport"). The following uses ASN.1 to describe an example of an abstraction or template for a report (or traffic event report) based on available traffic credits, referred to as the Traffic Event Report Abstract Syntax (3):

[0318]

[0319] Abstract syntax for traffic event reporting (3)

[0320] In some implementations, the Traffic Event Reporting Abstract Syntax (3) or Traffic Event Reporting Abstract can include the parameter “remainingTrafficCredits”, which can carry information indicating the remaining traffic credits of a network device (such as a terrestrial TRP) or a group of network devices (such as a terrestrial TRP group), and may take the value of an integer between 0 and 10000000000000.

[0321] In some implementations, the Traffic Event Reporting Abstract Syntax (3) or Traffic Event Reporting Abstract can include the parameter “trafficTrafficCredits”, which can carry information indicating the energy credits used by network devices (such as terrestrial TRPs) or groups of network devices (such as terrestrial TRP groups), and may take the value of an integer between 0 and 10000000000000.

[0322] Other parameters included in the traffic event reporting abstract syntax (3) are similar to some parameters included in the traffic event reporting abstract syntax (1) or traffic event reporting abstract syntax (2). Specifically, the interpretation of “groupIdentity”, “trafficDirection”, and “trafficDirection” in the traffic event reporting abstract syntax (3) can be the same as or similar to the corresponding parameters in the traffic event reporting abstract syntax (1) or traffic event reporting abstract syntax (2).

[0323] In some implementations, traffic event reports sent by network devices to non-terrestrial network devices can also be sent to the core network for further processing to implement network-wide energy-saving strategies and other strategies related to achieving carbon neutrality goals.

[0324] In some implementations, terrestrial TRPs and other network devices can maintain an internal counter, such as "currentTrafficCredits," whose value is initially set to "maxTrafficCredit" and is decremented every unit of time (e.g., per second) based on the traffic credit value corresponding to the traffic consumed by the network device (e.g., the terrestrial TRP). In other implementations, terrestrial TRPs and other network devices can maintain an internal counter, such as "currentTrafficCredits," whose value is initially set to "maxTrafficCredit" and is decremented every unit of time (e.g., per second) based on the traffic credit value corresponding to the energy consumed by the network device group (e.g., the terrestrial TRP group) to which the network device (e.g., the terrestrial TRP) belongs.

[0325] This document also discloses examples of devices (such as ED or UE, T-TRP, NT-TRP, network devices, serving cells) used to perform the various methods described herein.

[0326] For example, a network device may include a memory for storing processor-executable instructions and a processor for executing the processor-executable instructions. When the processor executes the processor-executable instructions, it may cause the processor to perform the operations described herein. Figure 13 Method steps for one or more devices as described above. For example, the processor can cause the device to communicate over the air interface in an operating mode by implementing operations consistent with the operating mode, the operations including performing necessary measurements according to the configuration of the operating mode and generating content based on these measurements, preparing uplink transmissions and processing downlink transmissions (such as encoding, decoding, etc.), and configuring and / or instructing one or more RF chains and one or more antennas to transmit / receive.

[0327] It is important to note that the expression "at least one of A or B" used in this document is interchangeable with the expression "A and / or B". This expression refers to a list in which A or B or A and B can be selected. Similarly, the expression "at least one of A, B, or C" used in this document is interchangeable with "A and / or B and / or C" or "A, B, and / or C". This expression refers to a list in which the following can be selected: A or B or C, or A and B, or A and C, or B and C, or all of A, B, and C. The same principle applies to longer lists with the same format.

[0328] In this disclosure, the word "a" when used in conjunction with the word "comprising" in the claims and / or description may mean "one," but also has the same meaning as "one or more," "at least one," or "one or more," unless otherwise expressly stated. Similarly, the word "another" may mean at least a second or more, unless otherwise expressly stated.

[0329] In this disclosure, the terms "first" and "second," when used before the same term (such as ED or operational step), do not indicate the order or sequence of the terms. For example, unless otherwise expressly stated, "first ED" and "second ED" refer to two different EDs; similarly, unless otherwise expressly stated, "first step" and "second step" refer to two different operational steps, but do not imply that the first step must be performed before the second step. The actual order depends on the logic of the two steps.

[0330] The terms “coupling” or “connection” as used herein may have several different meanings depending on the context in which they are used. For example, depending on the specific context, the terms “coupling” or “connection” as used herein may mean that two elements or devices are directly connected to each other or connected to each other via mechanical elements through one or more intermediate elements or devices.

[0331] The terms “receive,” “detect,” and “decode” used in this document can have several different meanings depending on the context in which they are used. For example, unless otherwise stated, the term “receive” can indicate that information (such as DCI or MAC-CE, RRC signaling, or TB) has been successfully received by the receiving node, meaning that the receiving end correctly detected and decoded it. In this scenario, “receive” can encompass both “detect” and “decode,” or it can indicate both. For example, “receive paging” means that the paging was correctly decoded and successfully retrieved, while “received paging not received” means that the receiving end did not detect and / or decode the paging. For example, “not received paging” means that the receiving end attempted to detect and / or decode the paging but failed to retrieve it. The term “receive” can sometimes indicate that a signal has arrived at the receiving end, but does not necessarily mean that the information in the signal has been correctly detected and decoded. In this case, the receiving end needs to perform detection and decoding on the signal to retrieve the information carried in the signal. In this scenario, “receive,” “detect,” and “decode” can indicate different procedures by which the receiving end retrieves information.

[0332] It should be understood that one or more steps of the exemplary methods provided herein can be performed by corresponding units or modules. For example, a signal can be transmitted by a transmitting unit or transmitting module. A signal can be received by a receiving unit or receiving module. A signal can be processed by a processing unit or processing module. The corresponding units / modules can be hardware, software, or a combination thereof. For example, one or more of these units / modules can be integrated circuits such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs). It should be understood that if these modules are software, they can be retrieved by a processor, in whole or in part, individually or collectively, for processing, or in one or more instances as needed, and these modules themselves can include instructions for further deployment and instantiation.

[0333] While combinations of features are illustrated in the described embodiments, not all features need to be combined to achieve the advantages of the various embodiments of this disclosure. In other words, a system or method designed according to one embodiment of this disclosure does not necessarily include any of the features shown in the drawings or in all portions schematically illustrated in the drawings. Furthermore, selected features of one exemplary embodiment may be combined with selected features of other exemplary embodiments.

[0334] Although this disclosure has been described with reference to illustrative embodiments, this specification is not intended to be limiting. Those skilled in the art will clearly understand, upon referring to this document, various modifications and combinations of the illustrative embodiments and other embodiments of this disclosure. Therefore, the appended claims are intended to cover any such modifications or embodiments.

Claims

1. A network management method, characterized in that, include: The first network device receives configuration information from the second network device, wherein the configuration information is used to configure the first network device to determine whether to send a report indicating that a traffic event has occurred.

2. The method according to claim 1, characterized in that, Also includes: Based on the configuration information, determine whether one or more conditions indicating that the traffic event has occurred are met.

3. The method according to claim 2, characterized in that, Also includes: The report is sent when one or more of the conditions indicating that the traffic event has occurred are met.

4. The method according to any one of claims 1 to 3, characterized in that, The configuration information includes at least one of the following: Information used to identify the type of traffic events to be monitored by the first network device; Information indicating the type of the traffic event, wherein the threshold is used to compare with monitoring data to determine whether the traffic event has occurred; Information indicating the duration of the traffic event that triggered the sending of the report; Indicates whether to specify the first network device to send the report information when the traffic event has occurred; Indicates whether to specify information for a network device group including the first network device to send the report when the traffic event has occurred; or Information indicating the reporting device within the network device group designated to send the report when the traffic event has occurred.

5. The method according to claim 4, characterized in that, The type of the traffic event to be monitored is related to at least one of the following: The service throughput of the first network device; Resource utilization rate of the first network device; or The number of terminal devices served by the first network device.

6. The method according to any one of claims 1 to 5, characterized in that, The report includes at least one of the following: Identify information about the first network device; Identify information about a network device group that includes the first network device; Information indicating the type of service measured by the first network device; Information indicating the direction of the service as measured by the first network device; The information indicates the traffic event data measured by the first network device according to the configuration information before triggering the reporting of the traffic event; or Information indicating the service carrier frequency measured by the first network device.

7. The method according to claim 6, characterized in that, The type of the service is at least one of the following: enhanced mobile broadband (eMBB) service, ultra-reliable low-latency communication (URLLC) service, massive machine-type communication (mMTC) service, global connectivity service, sensing-related service, or service related to artificial intelligence (AI) or machine learning (ML) technologies applied to communication.

8. The method according to any one of claims 1 to 7, characterized in that, Also includes: Receive additional configuration information to determine whether to send the report.

9. The method according to any one of claims 1 to 8, characterized in that, Also includes: The first network device monitors a control channel carrying control information from the second network device, wherein the control information is used to schedule the transmission of the configuration information.

10. The method according to claim 9, characterized in that, The control channel is a common control channel shared with one or more other network devices in the network.

11. The method according to claim 10, characterized in that, The configuration information is carried on the System Information Block (SIB).

12. The method according to claim 10 or 11, characterized in that, The control information includes a Cyclic Redundancy Check (CRC) scrambled using the Radio Network Temporary Identifier (RNTI).

13. The method according to claim 9, characterized in that, The control channel is a control channel dedicated to the first network device.

14. The method according to claim 13, characterized in that, The configuration information is carried in the Radio Resource Control (RRC) message.

15. The method according to any one of claims 1 to 14, characterized in that, The first network device is the first ground transmission and reception point (T-TRP).

16. The method according to claim 15, characterized in that, The second network device is the second T-TRP.

17. The method according to claim 15, characterized in that, The second network device is the first non-terrestrial transmission receiving point NT-TRP.

18. The method according to claim 17, characterized in that, The first network device sends the report to the second network device or a second NT-TRP that is different from the first NT-TRP.

19. The method according to claim 18, characterized in that, The second network device and the second NT-TRP: Located on the same orbit; or Located on one or more different tracks, each track provides coverage for the first network device.

20. The method according to any one of claims 1 to 19, characterized in that, The first network device serves a first coverage area; and / or The second network device serves the second coverage area.

21. The method according to claim 20, characterized in that, At least one of the following must be satisfied: The first coverage area is smaller than the second coverage area; At least a portion of the first coverage area is located within the second coverage area; or The first coverage area overlaps with the second coverage area.

22. A network device, characterized in that, include: processor; A computer-readable medium storing computer-executable instructions, wherein, when executed, the computer-executable instructions cause the processor to perform the method according to any one of claims 1 to 21.

23. A network management method, characterized in that, include: The second network device sends configuration information to the first network device, wherein the configuration information is used by the first network device to determine whether to send a report indicating that a traffic event has occurred.

24. The method according to claim 23, characterized in that, Also includes: The report is received from the first network device.

25. The method according to claim 23 or 24, characterized in that, The configuration information includes at least one of the following: Information used to identify the type of traffic event to be monitored by the first network device; Information indicating a threshold for the type of the traffic event, wherein the threshold is used to compare with monitoring data so that the first network device can determine whether the traffic event has occurred; Information indicating the duration of the traffic event that triggered the first network device to send the report; Indicates whether to specify the first network device to send the report information when the traffic event has occurred; Indicates whether to specify information for a network device group including the first network device to send the report when the traffic event has occurred; or Information indicating the reporting device within the network device group designated to send the report when the traffic event has occurred.

26. The method according to claim 25, characterized in that, The type of the traffic event to be monitored by the first network device is related to at least one of the following: The service throughput of the first network device; Resource utilization rate of the first network device; or The number of terminal devices served by the first network device.

27. The method according to any one of claims 23 to 26, characterized in that, The report includes at least one of the following: Identify information about the first network device; Identify information about a network device group that includes the first network device; Information indicating the type of service measured by the first network device; Information indicating the direction of the service as measured by the first network device; The information indicates the traffic event data measured by the first network device according to the configuration information before triggering the reporting of the traffic event; or Information indicating the service carrier frequency detected by the first network device.

28. The method according to claim 27, characterized in that, The service type is at least one of the following: enhanced mobile broadband (eMBB) service, ultra-reliable low-latency communication (URLLC) service, massive machine-type communication (mMTC) service, global connectivity service, sensing-related service, or service related to artificial intelligence (AI) or machine learning (ML) technologies applied to communication.

29. The method according to any one of claims 23 to 28, characterized in that, Also includes: Additional configuration information is sent to the first network device, wherein the additional configuration information is used by the first network device to determine whether to send the report.

30. The method according to any one of claims 23 to 29, characterized in that, Control information is transmitted through a control channel, and the control information is used to schedule the transmission of the configuration information.

31. The method according to claim 30, characterized in that, The control channel is a common control channel shared with one or more other network devices in the network.

32. The method according to claim 31, characterized in that, The configuration information is carried on the System Information Block (SIB).

33. The method according to claim 31 or 32, characterized in that, The control information includes a Cyclic Redundancy Check (CRC) scrambled using the Radio Network Temporary Identifier (RNTI).

34. The method according to claim 30, characterized in that, The control channel is a control channel dedicated to the first network device.

35. The method according to claim 34, characterized in that, The configuration information is carried in the Radio Resource Control (RRC) message.

36. The method according to any one of claims 23 to 25, characterized in that, The first network device is the first ground transmission and reception point (T-TRP).

37. The method according to claim 36, characterized in that, The second network device is the second T-TRP.

38. The method according to claim 36, characterized in that, The second network device is the first non-terrestrial transmission receiving point NT-TRP.

39. The method according to claim 38, characterized in that, Also includes: The configuration information is sent to a second NT-TRP that is different from the first NT-TRP, wherein the second NT-TRP is located on the first track where the first NT-TRP is located, or on a second track that is different from the first track, and both the first track and the second track provide coverage for the first network device.

40. The method according to claim 38 or 39, characterized in that, Also includes: The configuration information is received from a third NT-TRP, which is different from the first NT-TRP, wherein the first NT-TRP and the third NT-TRP are on the same or different tracks, and each track provides coverage for the first network device.

41. The method according to any one of claims 23 to 40, characterized in that, At least one of the following must be satisfied: The first network device serves the first coverage area; or The second network device serves the second coverage area.

42. The method according to claim 41, characterized in that, At least one of the following must be satisfied: The first coverage area is smaller than the second coverage area; At least a portion of the first coverage area is located within the second coverage area; or The first coverage area overlaps with the second coverage area.

43. A network device, characterized in that, include: processor; A computer-readable medium storing computer-executable instructions, wherein, when executed, the computer-executable instructions cause the processor to perform the method according to any one of claims 23 to 42.

44. A non-transitory computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed by a processor of the device, enable the device to perform the method according to any one of claims 1 to 21 and 23 to 42.

Images