Apparatus, method and computer program product

Abstract

An apparatus is provided that receives first QoS information for a performance-limited UE and second QoS information for a non-performance-limited UE, where the first and second QoS information relate to MBS broadcast or multicast sessions available at the performance-limited UE and the non-performance-limited UE, determining, based on the received first and second QoS information, whether a performance-limited UE and a non-performance-limited UE are able to receive the MBS broadcast or multicast session using a common frequency resource associated with the performance-limited UE, if it is determined that the performance-limited UE and the non-performance-limited UE are not able to be used for receiving the MBS broadcast or multicast session by both the performance-limited UE and the non-performance-limited UE, determining whether the performance-limited UE and the non-performance-limited UE are able to receive the MBS broadcast or multicast session. And if it is determined that common frequency resources associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, providing a first tunnel to the performance-limited UE for transmitting the MBS broadcast or multicast session and providing a second tunnel to the non-performance-limited UE for transmitting the MBS broadcast or multicast session to the performance-limited UE, and if it is determined that common frequency resources associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session. If so, a first tunnel is provided for transmitting the MBS broadcast or multicast session to the performance limited UE and transmitting the MBS broadcast or multicast session to the non-performance limited UE.

Description

Technical Field

[0001] The present invention generally relates to an apparatus, a method and a computer program product, particularly, but not exclusively, for use in a network apparatus (gNB) and a user equipment (UE) as part of a communication system. Background Art

[0002] A communication system enables communication between two or more entities (eg, communication devices, base stations, and / or other nodes) by providing carrier waves between the various entities involved in the communication path.

[0003] The communication system may be a wireless communication system. Examples of wireless communication systems include public land mobile networks (PLMNs) operating based on radio standards (e.g., radio standards provided by 3GPP), satellite-based communication systems, and different wireless local area networks (e.g., wireless local area networks (WLANs)). Wireless systems may be divided into cells and are often referred to as cellular systems or cellular networks.

[0004] The communication system and associated equipment are usually operated according to a given standard or specification, which states how different entities associated with the system are allowed to perform, how they are allowed to interact with each other, and how this should be achieved. The communication protocols and / or parameters that should be used for connections within the network are also defined by the standard or specification. As mentioned above, some examples of standards are radio standards provided by 3GPP, such as 2G, 3G, 4G and 5G. The communication system described herein is based on the 5G standard. However, the described embodiments are not limited to operating according to 5G and may also be applicable to future radio standards, such as 6G. Summary of the invention

[0005] According to aspects of the present invention, a device is provided. The device includes at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, together with the at least one processor, enable the device to: receive first QoS information for performance-constrained UEs and second QoS information for non-performance-constrained UEs, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both at least one of the performance-constrained UEs and at least one of the non-performance-constrained UEs; determine, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with at least one of the performance-constrained UEs can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; if it is determined that the common frequency resource associated with at least one of the performance-constrained UEs If the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, a first tunnel for the transmission of the MBS broadcast or multicast session is provided to at least one of the performance-limited UEs and a second tunnel for the transmission of the MBS broadcast or multicast session is provided to at least one of the non-performance-limited UEs; and if it is determined that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, the first tunnel for the transmission of the MBS broadcast or multicast session is provided to the performance-limited UE and the first tunnel for the transmission of the MBS broadcast or multicast session is provided to the non-performance-limited UE.

[0006] The apparatus is further configured to receive at least one of: second information, together with the first QoS information, indicating that the first QoS information is for performance-constrained UEs, and / or third information, together with the second QoS information, indicating that the second QoS information is for non-performance-constrained UEs, and wherein the determination is also based on the second information and the third information.

[0007] On the other hand, a device is provided, including at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the device to: receive first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE from a 5G core network, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE; determine, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; and return to the 5G core network at least one of the following: a single tunnel transport layer address (TNLA) for the transmission of the MBS broadcast or multicast session for both the performance-constrained UE and the non-performance-constrained UE, if it is determined that the common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session. a source that can be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, an independent tunnel TNLA, if it is determined that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session.

[0008] The first QoS information and the second QoS information received from the 5G core network 5GC may be associated with the same broadcast or multicast session identifier or temporary mobile group identifier TMGI.

[0009] The first QoS information and the second QoS information may be received from the 5GC in an NG application protocol broadcast or multicast establishment request or modification request message.

[0010] The first QoS information may be received from the 5GC associated with a first broadcast or multicast session identifier or TMGI 1 and the second QoS information may be received from the 5GC associated with a second broadcast or multicast session identifier or TMGI 2.

[0011] The first QoS information may be received in a first NG application protocol broadcast or multicast establishment or modification request message containing the first broadcast or multicast session identifier TMGI 1 and the second QoS information may be received in a second NG application protocol broadcast or multicast establishment or modification request message containing the second broadcast or multicast session identifier TMGI 2.

[0012] The apparatus may be comprised within a radio access node, such as a gNB.

[0013] In particular, the apparatus may be comprised in a Central Unit Control Plane (CU CP) entity of a radio access node.

[0014] Determining (whether the common frequency resources of the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session) may include sending first QoS information for the performance-constrained UE and second QoS information for the non-performance-constrained UE to a distributed unit (DU) of the wireless access node, wherein the first QoS information and the second QoS information relate to the MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE, and receiving at least one of the following from the DU: a single DU tunnel TNLA, if it is determined that the common frequency resources associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session, an independent DU tunnel TNLA, if it is determined that the common frequency resources associated with the performance-constrained UE cannot used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, and / or an indicator indicating that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session.

[0015] In another aspect, an apparatus is provided, comprising at least one processor and at least one memory comprising computer program code, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to: receive, at the distributed unit DU of a radio access node, first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE from a central unit control plane CU CP of the radio access node, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE, and determine, at the DU, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE for receiving the MBS broadcast or multicast session based on the received first QoS information and the second QoS information; and send a message to the CU The CP returns at least one of the following: a single tunnel transport layer address (TNLA) for the transmission of the MBS broadcast or multicast session for both the performance-constrained UE and the non-performance-constrained UE, if it is determined that the common frequency resources associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session, an independent tunnel TNLA, if it is determined that the common frequency resources associated with the performance-constrained UE cannot be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session, indicating that the common frequency resources associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session. An indicator for the MBS reception broadcast or multicast session by both the performance-constrained UE and the non-performance-constrained UE, if it is determined that the common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE for receiving the MBS broadcast or multicast session, and / or an indicator indicating that the common frequency resource associated with the performance-constrained UE cannot be used by both the performance-constrained UE and the non-performance-constrained UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-constrained UE cannot be used by both the performance-constrained UE and the non-performance-constrained UE for receiving the MBS broadcast or multicast session.

[0016] The first QoS information and the second QoS information received from the CU CP may be associated with the same broadcast or multicast session identifier or TMGI.

[0017] The first QoS information and the second QoS information may be received from the CU CP in an F1 application protocol broadcast or multicast setup request or modification request message. The first QoS information may be received from the CU CP associated with a first broadcast or multicast session identifier or TMGI 1 and the second QoS information may be received from the CU CP associated with a second broadcast or multicast session identifier or TMGI 2.

[0018] The first QoS information may be received in a first F1 application protocol broadcast or multicast setup or modification request message including the first broadcast or multicast session identifier TMGI 1 and the second QoS information may be received in a second F1 application protocol broadcast or multicast setup or modification request message including the second broadcast or multicast session identifier TMGI 2.

[0019] On the other hand, an apparatus is provided, comprising: a component for receiving first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE; a component for determining, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; and a component for determining, if it is determined that the common frequency resource associated with the performance-constrained UE cannot be used by both the performance-constrained UE and the non-performance-constrained UE, If both performance-limited UEs are used to receive the MBS broadcast or multicast session, a first tunnel for the transmission of the MBS broadcast or multicast session is provided to the performance-limited UE and a second tunnel for the transmission of the MBS broadcast or multicast session is provided to the non-performance-limited UE; and if it is determined that the common frequency resources associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, the first tunnel for the transmission of the MBS broadcast or multicast session is provided to the performance-limited UE and the first tunnel for the transmission of the MBS broadcast or multicast session is provided to the non-performance-limited UE.

[0020] The apparatus may be a radio access node such as a gNB, or a component thereof such as a distributed unit (DU).

[0021] On the other hand, a method is provided. The method includes: receiving first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE; determining, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; if it is determined that the common frequency resource associated with the performance-constrained UE cannot be used by both the performance-constrained UE and the non-performance-constrained UE, If the common frequency resource associated with the performance-limited UE is used by the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, then the first tunnel for the transmission of the MBS broadcast or multicast session is provided to the performance-limited UE and the second tunnel for the transmission of the MBS broadcast or multicast session is provided to the non-performance-limited UE; and if it is determined that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, then the first tunnel for the transmission of the MBS broadcast or multicast session is provided to the performance-limited UE and the first tunnel for the transmission of the MBS broadcast or multicast session is provided to the non-performance-limited UE.

[0022] On the other hand, a method is provided. The method includes: receiving first QoS information for performance-constrained UEs and second QoS information for non-performance-constrained UEs from a 5G core, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE; determining whether the common frequency resources associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session based on the received first QoS information and the second QoS information; and returning at least one of the following to the 5GC: a single tunnel transport layer address (TNLA) for the transmission of the MBS broadcast or multicast session for both the performance-constrained UE and the non-performance-constrained UE, if it is determined that the common frequency resources associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session, Independent tunnel TNLA, if it is determined that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE for the MBS reception broadcast or multicast session, if it is determined that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session.

[0023] In another aspect, a method is provided. The method comprises: at the distributed unit DU of the radio access node, receiving first QoS information for performance-constrained UEs and second QoS information for non-performance-constrained UEs from a central unit control plane CU CP of the radio access node, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE, at the DU, determining whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session based on the received first QoS information and the second QoS information; and returning at least one of the following to the CU: a single tunnel transport layer address (TNLA) for the transmission of the MBS broadcast or multicast session for both the performance-constrained UE and the non-performance-constrained UE, if it is determined that the common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session, independently Tunnel TNLA, if it is determined that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE for the MBS reception broadcast or multicast session, if it is determined that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session.

[0024] Another aspect provides a computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when executed by a device, cause the device to execute Figures 9 to 11 The method shown in .

[0025] Another aspect provides a computer program product, the computer program product comprising program instructions, when the program is executed by a device, the program instructions cause the device to execute Figures 9 to 11 The method shown in .

[0026] In this way, the radio access node can efficiently and dynamically decide which common frequency resources are needed for a broadcast or multicast session based on changing cell conditions and the QoS requirements of the session.A broadcast or multicast session does not need to always be transmitted twice over the air. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 shows a simplified schematic diagram of a 5G network;

[0028] Figure 2 A simplified schematic diagram of a user equipment suitable for performing an embodiment of the present invention is shown;

[0029] Figure 3 block diagrams schematically illustrating some examples of non-volatile storage media;

[0030] Figure 4 shows a block diagram of a 5G network including a schematic illustration of a gNodeB suitable for performing embodiments of the present invention;

[0031] Figure 5 shows a signal flow or message flow diagram according to an embodiment;

[0032] Figure 6 shows a message flow diagram according to an embodiment;

[0033] Figure 7 shows a message flow diagram according to an embodiment;

[0034] Figure 8 shows a message flow diagram according to an embodiment;

[0035] Fig. 9 A flow chart of a method according to an embodiment is shown;

[0036] Fig.10 A flowchart showing a method according to an embodiment; and

[0037] Fig.11 A flow chart of a method according to an embodiment is shown. DETAILED DESCRIPTION

[0038] The following examples are exemplary. Although this specification may refer to "one", "one" or "some" embodiments in several positions of the text, this does not necessarily mean that each reference refers to the same embodiment, or that a particular feature is only applicable to a single embodiment. The individual features of different embodiments may also be combined to provide other embodiments. For the purposes of this disclosure, phrases "at least one of A or B", "at least one of A and B", "A and / or B" refer to (A), (B), or (A and B). For the purposes of this disclosure, phrases "A or B" and "A and / or B" refer to (A), (B), or (A and B). For the purposes of this disclosure, phrases "A, B and / or C" refer to (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C).

[0039] It should be understood that although the terms "first" and "second" etc. may be used to describe various elements in this article, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element.

[0040] 3GPP Rel-17 MBSWI is specified for broadcast or multicast reception by a user equipment (UE), which may be in an idle / inactive / connected RRC state (e.g., RRC_IDLE, RRC_INACTIVE, RRC_CONNECTED).

[0041] It should be noted that for the sake of brevity, a broadcast or multicast session or service will often be referred to as a broadcast session or session. However, the described embodiments may be applicable to both broadcast and multicast sessions or services.

[0042] System Information Block 20 (SIB20) is a message containing information for UEs to receive Multicast Control Channel (MCCH) data, including the repetition period and the configured transmit / receive window for the MCCH. The MCCH data includes control information required for the UE to understand the broadcast or multicast session / service provided in the cell and scheduling information for receiving broadcast data. This information is periodically transmitted by the gNB (gNodeB) with a configurable repetition period and within the configured transmission window.

[0043] MCCH provides basic information about the Multicast Traffic Channel (MTCH), which is a data channel that provides broadcast services. This information includes search space, discontinuous reception (DRX) information, etc. The UE uses this information to receive the relevant MTCH. Each Temporary Mobile Group Identity (TMGI) is an identifier for a specific broadcast service and is mapped to a specific MTCH.

[0044] To receive MCCH data, the UE reads and decodes the SIB20 message to learn the configuration / scheduling details of the MCCH. The UE then reads the MCCH data to learn the services provided in the cell and their scheduling information. However, for UEs in the RRC_CONNECTED state, the SIB reading is ignored and the search space configuration is provided to the UE to receive the MCCH within the PDCCH-ConfigCommon. When in the RRC_INACTIVE state, the UE obtains information from the SIB20 block, such as the MCCH repetition scheduling configuration, window duration, and start time slot. The content of the MCCH and the repetition window of the MCCH do not change within the modification period.

[0045] The Rel-17 specification describes the UE behavior for RRC_INACTIVE / RRC_IDLE based on the configuration of CORESET#0, the initial bandwidth part (BWP) and the common frequency resources (CFR) for receiving broadcast services. CORESET#0 is where the UE can receive only control resources CFR, and CFR is where the UE can receive control and data broadcasts.

[0046] In Rel-17, a UE receiving a broadcast service in the RRC_IDLE / INACTIVE state can use the following steps to receive the relevant configuration:

[0047] In addition to the details of the CFR configuration, SIB20 also includes details on how to receive MCCH (period and offset) within a given modification period. The UE first reads SIB20 to obtain this information.

[0048] The UE then reads the MCCH sent via the CFR. By reading the MCCH, the UE can learn which services are provided in the current cell and the necessary configuration for how to receive these services.

[0049] • Finally, the UE can receive the broadcast data.

[0050] Note that MCCH and data will be sent in the same CFR.

[0051] Reduced Capability (RedCap) devices have a bandwidth (BW) limitation. This means that RedCap UEs cannot receive a BW greater than a certain maximum BW they support (e.g., 20 MHz). If the initial bandwidth part (BWP) of the system is greater than such a limitation, the RedCap UE utilizes the initial BWP configured solely by the system information block SIB 1.

[0052] In Rel-17, 3GPP concluded that RedCap UEs can receive broadcast data if the CFR BW is appropriately configured for RedCap UEs; in other words, if the CFR BW is less than or equal to the BW supported by the RedCap UE. No specific MBS enhancements are made for these UEs.

[0053] In Rel-18, some companies proposed to introduce a new lower BWCFR for BW limited UEs (such as RedCap UEs). However, the technical issues including UE behavior are not specified. Even if the operation is defined in Rel-18, it will be a baseline understanding and enhancements are expected in Rel-19. Companies prefer a baseline solution that does not impact normal (non-performance limited or non-RedCap) UEs.

[0054] In RAN2#121, an agreement has been reached to introduce a separate broadcast common frequency resource (CFR) that can be used when the configured bandwidth of the default CFR in SIB20 exceeds the bandwidth limit or bandwidth capability of the RedCap UE. This proposal was made in R2-2300797.

[0055] If two separate CFRs are introduced, one CFR is for RedCap UEs and the other CFR is for normal UEs. A new separate MBS CFR for RedCap UEs (separate from the traditional wideband MBS CFR for non-RedCap UEs) will be used to receive MBS broadcast control and data.

[0056] The first option is that the traditional or wideband CFR (for non-bandwidth limited or non-RedCap UEs) and the narrowband CFR for RedCap UEs are separate or partially overlapping.

[0057] The wideband or non-RedCap CFR can be separate from the RedCap CFR, or it may partially overlap. In this case, "partially overlapping" means that they can have some common parts; for example, CORESET#0, which is common to and overlaps with the wideband (non-RedCap) and RedCap CFR. If the two CFRs partially overlap, it essentially means that there will be two separate MCCHs corresponding to the two CFR areas, because CORESET#0 only contains control signaling resources. In this scenario, normal (non-RedCap) UEs will read the wideband CFR for broadcast control and data, while RedCap UEs will read the RedCap CFR. With this configuration, the following scenarios may occur:

[0058] The first option is that non-RedCap UEs and RedCap UEs receive common broadcast services in their respective CFRs. For common broadcast services for both non-RedCap UEs and RedCap UEs, two separate control and data flows are transmitted in two different CFRs. RedCap UEs receive control and data in the RedCap CFR, while non-RedCap UEs receive control and data in the broadband non-RedCap CFR.

[0059] However, this option would require transmitting the same data / control information twice over the air.As mentioned above, the baseline operation will be defined in Rel-18 and this first option is a possible outcome of that operation since the aim is not to change normal UE (non-performance limited / non-RedCap) behavior.

[0060] The second option is that both non-RedCap UEs and RedCap UEs receive only part of the public broadcast service in the RedCap CFR. This can also manifest as a non-RedCap UE reading two MCCHs in a scenario where only part of the public broadcast service data is sent by the gNB in ​​the RedCap CFR area. Therefore, the non-RedCap UE will now have to read both the RedCap and non-RedCap MCCHs to determine the configuration for retrieving broadcast data in the RedCap CFR area. However, with this approach, the non-RedCap UE will always need to monitor two different MCCHs, resulting in more power consumption at the UE. It is important to note that unless the RedCap CFR is restricted to be used only by RedCap UEs, Rel-18 non-RedCap and Rel-18 RedCap UEs should be able to read the RedCap CFR. However, Rel-17 UEs (which are either non-RedCap or RedCap UEs) will not be able to read the RedCap CFR introduced in Rel-18. This means that once any Rel-17 UE joins a broadcast session, the broadcast data must now be transmitted within the conventional Rel-17 CFR described in the previous section.

[0061] It is clear from the above options that reading two MCCHs transmitted in Rel-18 Normal CFR and Rel-18 RedCap CFR is not an optimal strategy from a normal Rel-18 UE perspective.The main purpose of the embodiments described herein is to optimize the operation of Rel-18 Normal UEs in the presence of Rel-18 RedCap CFR.

[0062] Another scenario is where the legacy or wideband (non-performance limited or non-RedCap) CFR and the RedCap or narrowband CFR overlap. In this case, the two CFR areas overlap, so we can send a single MCCH in the common RedCap CFR and wideband CFR overlap area. The gNB schedules the control signaling information to be sent in the overlapping CFR area that can be received by both RedCap UEs and normal UEs. The disadvantage of this option is that the MCCH for non-RedCap UEs must be sent in the smaller CFR area of ​​the RedCap UE. This can be detrimental for non-RedCap UEs, which may have enhanced CFR requirements for the MCCH. In this case, it is a challenge to determine how the gNB understands that the same transport group identifier (TMGI) for the broadcast service is applicable for use with two different receivers. In this case, the two receivers are the non-RedCap UE and the RedCap UE.

[0063] Therefore, the broadcast operation when both Non-RedCap CFR and RedCap CFR are configured is not optimal in terms of resource usage for scheduling services or power consumption or efficient broadcast reception by Non-RedCap UEs.

[0064] A solution has been agreed which will be enhanced in Rel-19. However, the solution is suboptimal. In the agreed solution, the broadcast or multicast service is handled in such a way that the broadcast or multicast service is transmitted in separate CFRs, i.e. in the Rel-17 non-RedCap CFR and in the Rel-18 RedCap CFR. For example, if a broadcast service targets two types of UEs, it will be transmitted twice over the air. There are two problems with this solution.

[0065] The first problem is that the baseline solution for broadcast or multicast reception of RedCap UEs in Rel-18 is inefficient because if the service is intended for both normal UEs and RedCap UEs, the same service needs to be transmitted over the air once in each CFR. Furthermore, which services will be provided where the CFR is left to the radio access node (gNB) to implement / configure. It is not at all clear how the gNB can efficiently and dynamically decide which CFR to use. This dynamism and efficiency is needed because the gNB should be able to adapt to changes in, for example, cell load. The gNB needs to determine which CFR to use for data transmission. Once the gNB realizes that there are two different recipients for the same service, the gNB will have to choose between the options proposed above (transmitting the broadcast service in a non-RedCap CFR and a non-RedCap CFR, or sending the service only in a RedCap CFR to both RedCap and non-RedCap UEs). In addition to the disadvantages of the options described above, it has not been well defined so far how the gNB chooses between the two options.

[0066] The second problem with the baseline solution for broadcast reception of RedCap UEs in Rel-18 is that the selection of which CFR to use for a particular service is left to the gNB implementation. It is unclear how the gNB can efficiently and dynamically decide which CFR to use based on changing cell conditions and the QoS requirements of the service.

[0067] Therefore, gNB currently lacks the means to solve the above problems.

[0068] Figure 1 A system 100 according to an exemplary aspect is schematically shown and in which the embodiments described herein may operate. The system 100 is part of a mobile communication network and comprises a mobile device 130-1 which may be a terminal device or a user equipment (UE) or an Internet of Things (IoT) device.

[0069] The term "terminal device" or "UE" refers to any terminal device capable of wireless communication. By way of example and not limitation, a terminal device may also be referred to as a communication device, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS) or access terminal (AT). The terminal device may include, but is not limited to, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet computer, a wearable terminal device, a personal digital assistant (PDA), a portable computer, a desktop computer, an image capture terminal device such as a digital camera, a game terminal device, a music storage and playback device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop embedded device (LEE), a laptop mounted device (LME), a USB dongle, a smart device, a wireless customer premises equipment (CPE), an Internet of Things (IOT) device, a watch or other wearable, a head mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain environment), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

[0070] For the purpose of discussion, Figure 1 The portion of the network described by system 100 will be referred to as a 3GPP 5G network. However, this network can be any type of communication network, such as a 3G or 4G network, or it can be a 6G or other future network. In addition, the portion of the 5G network shown by system 100 can interact with another network of a different generation (e.g., a 4G or LTE network, or a 6G or other future network).

[0071] The system 100 further includes gNBs 120-1 and 120-2 with corresponding cells 130-1 and 130-2. The gNBs 120-1, 120-2 are part of a mobile communication network, which may include additional gNBs with corresponding cells.

[0072] The embodiments described herein may be implemented in any mobile communication network or radio system, such as a mobile communication network or radio system including at least one of the following radio access technologies (RATs): Worldwide Interoperability for Microwave Access (WiMAX), Global System for Mobile Communications (GSM, 2G), GSM EDGE Radio Access Network (GERAN), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS, 3G) based on basic Wideband Code Division Multiple Access (W-CDMA), High Speed ​​Packet Access (HSPA), Long Term Evolution (LTE), Advanced LTE and Enhanced LTE (eLTE). The term 'eLTE' here means LTE evolution connected to a 5G core. LTE is also known as Evolved UMTS Terrestrial Radio Access (EUTRA) or Evolved UMTS Terrestrial Radio Access Network (EUTRAN). The term "resource" may refer to a radio resource, such as a physical resource block (PRB), a radio frame, a subframe, a time slot, a subband, a frequency region, a subcarrier, a beam, etc. The term "transmit" and / or "receive" may refer to wireless transmission and / or reception on a radio resource via a wireless propagation channel.

[0073] However, the embodiments are not limited to the systems / RATs given as examples, but those skilled in the art may apply the solution to other communication systems / networks that provide the necessary attributes. Some examples of suitable communication networks include 5G networks and / or 6G networks. The 3GPP solution for 5G is called New Radio (NR). 6G is envisioned as a further development of 5G. NR has been envisioned to use multiple-input multiple-output (MIMO) multi-antenna transmission technology, deploy more base stations or nodes (the so-called small cell concept) than the current network of LTE, including macro sites, which operate in conjunction with smaller local access nodes and may also adopt multiple radio technologies for better coverage and enhanced data rates. 5G will likely consist of more than one radio access technology / radio access network (RAT / RAN), each optimized for certain use cases and / or spectrum. 5G mobile communications may have a wider range of use cases and related applications, including video streaming, augmented reality, different data sharing methods, and various forms of machine-type applications, including vehicle safety, different sensors, and real-time control. 5G is expected to have multiple radio interfaces, namely sub-6 GHz, cmWave and mmWave, and be integrated with existing legacy radio access technologies, such as LTE.

[0074] The current architecture in LTE networks is distributed in the radio and centralized in the core network. Network slicing allows the creation of multiple virtual networks on top of a common shared physical infrastructure. The virtual networks are then customized to meet the specific needs of applications, services, devices, customers or operators.

[0075] The signals of gNBs 120-1, 120-2 may be observed by a mobile device or user equipment (UE). UEs 140-1, 140-2 are served by gNB 120-1 within cell 130-1. Figure 1 Other UEs served by the network shown in FIG. 4 , which may be, for example, UE / IoT devices, mobile phones or autonomous vehicles.

[0076] gNBs 120-1 and 120-2 are connected to each other via an Xn interface and to the core network 150 via an NG interface.

[0077] Multiple different broadcast and / or multicast services (MBS) may be provided by gNB 120-1 in cell 130-1 via a multicast traffic channel (MTCH), which is a data channel that provides multicast / broadcast services.

[0078] The gNB 120-1 provides information about a multicast service channel (MTCH) by, for example, periodically transmitting a multicast control channel (MCCH) message containing MTCH information (e.g., service configuration information) for a UE (e.g., UE 140-1) within the cell 130-1 to receive the MTCH. The MTCH information may include control information required for the UE 140-1 to understand the multicast / broadcast service provided in the cell and scheduling information for receiving multicast / broadcast data.

[0079] The MCCH message is sent by gNB 120-1 periodically with a configured repetition period and within a configured transmission window.

[0080] gNB 120-1 provides information about MCCH by sending a SIB20 message. SIB20 contains information (e.g., fallback configuration information) for mobile devices to receive MCCH data, including a repetition period and a configured transmission / reception window for MCCH.

[0081] UE 140-1 may be in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED state.

[0082] If UE 140-1 is in RRC_IDLE or RRC_INACTIVE state, in order to receive MBS, UE 140-1 receives SIB20 message sent by gNB 120-1. UE 140-1 then decodes SIB20 message and thereby determines MCCH configuration / scheduling details (e.g. service configuration set information). UE 140-1 then receives MCCH message sent by gNB 120-1 to understand which MBS are provided in cell 140-1 and their scheduling information. UE 140-1 is then able to receive the desired MBS on the corresponding MTCH.

[0083] Now we will see Figure 2 Describing in more detail an example of UE 140-1, which may be any wireless communication device, Figure 2 A schematic partial cross-sectional view of a communication device 140-1 is shown. An appropriate UE or mobile communication device may be provided by any device capable of sending and receiving radio signals. Non-limiting examples include a mobile station (MS) or mobile device (such as a mobile phone or so-called 'smart phone'), a computer with a wireless interface card or other wireless interface facilities (e.g., a USB adapter), a personal digital assistant (PDA) or tablet computer with wireless communication capabilities, or any combination of these, etc. A mobile communication device may provide, for example, data communications for carrying communications such as voice, e-mail (email), text messages, multimedia, etc. Therefore, many services may be provided and provided to users via their communication devices. Non-limiting examples of these services include two-way or multi-way calls, data communications or multimedia services, or simply access to a data communication network system (such as the Internet). Broadcast or multicast data may also be provided to users. Non-limiting examples of content include downloads, television and radio programs, videos, advertisements, different reminders, and other information.

[0084] UE 140-1 may be, for example, a mobile device (i.e., a device that is not fixed to a particular location), or it may be a stationary device. A wireless device may or may not require human interaction for communication. As described herein, the term UE or "user" is used to refer to any type of wireless communication device.

[0085] In this discussion, UE 140-1 is an unrestricted UE or non-RedCap UE capable of reading broadband or legacy CFR, and UE 140-2 is a restricted UE or RedCap UE of the type described above capable of reading only RedCap CFR. However, for all intents and purposes, the structure of RedCap UE 140-2 is the same as that of the conventional UE. Figure 2 The same as UE 140-1 shown in FIG.

[0086] Throughout this document, non-RedCap UE, non-performance-limited UE, regular UE and legacy UE refer to the same type of UE. It is expected that such UE is a non-performance-limited UE. Similarly, RedCap UE and performance-limited UE refer to the same type of UE.

[0087] UE 140-1 may receive signals via appropriate receiving means over air interface or radio interface 201, and may send signals via appropriate means for sending radio signals. Figure 2 In the wireless device, a transceiver arrangement is schematically represented by a block 202. The transceiver arrangement 202 may be provided, for example, by a radio component and an associated antenna arrangement. The antenna arrangement may be arranged internally or externally to the wireless device.

[0088] The UE 140-1 is typically equipped with at least one data processing entity 203, at least one memory 204 and possibly other components 205 for use in the software and hardware assisted execution of tasks designed to perform these tasks, including control of access to and communication with access systems and other communication devices. Data processing, storage and other related control devices may be provided on appropriate circuit boards and / or in chipsets. This feature is indicated by reference numeral 206. The user may control the operation of the wireless device through a suitable user interface such as a keypad 207, voice commands, a touch-sensitive screen or touchpad, a combination thereof, etc. A display 208, a speaker and a microphone may also be provided. In addition, the wireless communication device may include appropriate (wired or wireless) connectors to connect to other devices and / or for connecting external accessories (e.g., hands-free devices) thereto.

[0089] Figure 2 The components of UE 140-1 shown in FIG. 1 and / or its associated circuitry may also be referred to as “means for receiving,” “means for sending,” “means for determining,” etc.

[0090] Figure 3 Schematic representations of non-volatile storage media 300a (e.g., computer diskettes (CD) or digital versatile disks (DVD)) and 300b (e.g., computer diskettes (CD) or digital versatile disks (DVD)) are shown. A Universal Serial Bus (USB) memory stick storing instructions and / or parameters 304 that, when executed by a processor, allow the processor to perform Figure 5 and / or Figure 6 and / or Figure 7 and / or Figure 8 and / or Fig. 9 and / or Fig.10 The method and / or one or more of the steps of a method otherwise described previously.

[0091] As provided herein, various aspects are described in the detailed description of the embodiments and the claims. In general, some examples may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device, but examples are not limited thereto. Although different examples may be illustrated and described as block diagrams, flow charts, or using some other graphical representations, it is well understood that, as non-limiting examples, these boxes, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware or controllers or other computing devices, or some combination thereof.

[0092] The examples may be implemented by computer software stored in a memory and executable by at least one data processor of the entity involved, or by hardware, or by a combination of software and hardware. Further in this regard, it should be noted that any process (e.g. Figure 5 and / or Figure 6 and / or Figure 7 , and / or Figure 8 and / or Fig. 9 and / or Fig.10 , and / or previously described in other ways) may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on physical media such as memory chips or memory blocks implemented within a processor, magnetic media (such as hard disk or floppy disks), and optical media (such as, for example, DVDs and data variants thereof, CDs, etc.).

[0093] The memory may be of any type suitable for the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. The data processor may be of any type suitable for the local technical environment and may include, as non-limiting examples, one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit, a gate-level circuit, and a processor based on a multi-core processor architecture.

[0094] Additionally or alternatively, some examples may be implemented using circuits. The circuits may be configured to perform one or more functions and / or method steps described previously. The circuits may be arranged in a base station and / or in a communication device and / or in a core network entity.

[0095] As used in this application, the term "circuitry" may refer to one or more or all of the following:

[0096] (a) hardware-only circuit implementation (e.g., implementation in analog and / or digital circuits only);

[0097] (b) a combination of hardware circuitry and software, such as:

[0098] (i) Combination of analog and / or digital hardware circuits and software / firmware

[0099] (ii) and any portion of a hardware processor with software (including a digital signal processor, software, and memory working together to enable a device such as a mobile phone or server to perform various functions); and

[0100] (c) A hardware circuit and / or processor, such as a microprocessor or portion of a microprocessor, that requires software (e.g., firmware) for operation, but the software may not be present when not needed for operation.

[0101] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or its) accompanying software and / or firmware. The term "circuit" also covers, for example, an integrated device.

[0102] The foregoing description has provided by way of non-limiting examples a complete and informative description of some embodiments. However, various modifications and adaptations will become apparent to those skilled in the relevant arts in view of the foregoing description when read in conjunction with the accompanying drawings and claims. However, all such and similar modifications of the teachings will still fall within the scope of the claims.

[0103] However, in the above, different examples are described using a radio access architecture based on Advanced Long Term Evolution (Advanced LTE, LTE-A) or New Radio (NR, 5G) as an example of an access architecture to which the described technology can be applied, without limiting the examples to such architectures. By appropriately adjusting the parameters and procedures, the examples can also be applied to other kinds of communication networks with appropriate means. Some examples of other options for suitable systems are Universal Mobile Telecommunications System (UMTS) Radio Access Network (UTRAN), Wireless Local Area Network (WLAN or WiFi), Worldwide Interoperability for Microwave Access (WiMAX), Personal Communications Service (PCS), Wideband Code Division Multiple Access (WCDMA), systems using Ultra-Wideband (UWB) technology, sensor networks, mobile ad hoc networks (MANETs), and Internet Protocol Multimedia Subsystem (IMS), or any combination thereof.

[0104] Figure 4An example of a simplified system architecture is shown showing only some elements and functional entities which are all logical units, the implementation of which may differ from what is shown. Figure 4 The connections shown in are logical connections; the actual physical connections may be different. It is obvious to those skilled in the art that the system typically includes other components besides Figure 4 Other functions and structures than those shown in .

[0105] However, the examples are not limited to the systems given as examples, but a person skilled in the art may apply the solution to other communication systems having the necessary characteristics.

[0106] Figure 4 The example of FIG. 1 shows a portion of an exemplary radio access network. For example, the radio access network may also support side link communications as described in more detail below.

[0107] Figure 4 UE 140-1 and 140-2 are shown. UE 140-1, 140-2 are configured to be wirelessly connected to gNB 120-1 on one or more communication channels. gNB 120-1 is also connected to core network 150. For the purposes of discussion, node 120-1 is a gNB serving UE 140-1, 140-2 in a cell. However, node 120-1 may also be an LTE eNB or even a non-3GPP access node. The physical link from UE to gNB is called uplink or reverse link, and the physical link from gNB to UE is called downlink or forward link. It should be understood that gNBs or their functions may be implemented using any node, host, server, or access point entity suitable for such purpose.

[0108] like Figure 1As shown, the communication system typically includes the above gNBs, in which case the gNBs may also be configured to communicate with each other via wired or wireless links designed for purposes such as Xn interfaces. These links can be used for signaling purposes. gNB 120-1 is a computing device configured to control the radio resources of the communication system coupled thereto. gNB 120-1 may also be referred to as a base station, an access point, or any other type of interface device including a relay station capable of operating in a wireless environment. gNB 120-1 includes or is coupled to a transceiver. From the transceiver of the gNB, a connection is provided to an antenna unit that establishes a bidirectional radio link to the device. The antenna unit may include multiple antennas or antenna elements. gNB 120-1 is also connected to a 5G core network 150 (CN or next generation core NGC). Depending on the technology deployed, the gNB is connected to the Serving and Packet Data Network Gateway (S-GW+P-GW) or User Plane Function (UPF) for routing and forwarding user data packets and for providing connectivity of the device to one or more external packet data networks, and to the Mobility Management Entity (MME) or Access Mobility Management Function (AMF) for controlling access and mobility of devices (UE).

[0109] Examples of UE devices 140-1, 140-2 are subscriber units, user devices, user equipment (UE), user terminals, terminal devices, mobile stations, mobile devices, and the like.

[0110] UE devices generally refer to mobile or static devices (e.g., portable or non-portable computing devices), including wireless mobile communication devices that operate with or without a Universal Subscriber Identity Module (USIM), including but not limited to the following types of devices: mobile phones, smart phones, personal digital assistants (PDAs), handsets, devices using wireless modems (alarm or measurement devices, etc.), laptop and / or touch screen computers, tablet computers, game consoles, notebooks, and multimedia devices. It should be understood that the device can also be an almost only uplink device, an example of which is a camera or video camera that loads images or video clips to the network. The device can also be a device with the ability to operate in an Internet of Things (IoT) network, which is a scenario in which objects are provided with the ability to transmit data on the network without, for example, human-to-human or human-to-computer interaction. For smart grids and connected vehicles. The device can also utilize the cloud. In some applications, the device may include a user-portable device with a radio component (such as a watch, headphones, or glasses), and the calculation is performed in the cloud.

[0111] UE 140-1, 140-2 illustrate a type of device to which resources on the air interface are allocated and assigned, and thus any features described herein with a device may be implemented with a corresponding device (such as a relay node). An example of such a relay node is a layer 3 relay (self-backhaul relay) toward a base station. The device (or, in some examples, a layer 3 relay node) is configured to perform one or more user equipment functions.

[0112] The various techniques described in this article can also be applied to cyber-physical systems (CPS) (systems of computing elements that coordinate the control of physical entities). CPS can enable the implementation and development of a large number of interconnected information and communication technologies, ICT, devices (sensors, actuators, processors microcontrollers, etc.) embedded in physical objects at different locations. Mobile cyber-physical systems, where the physical systems discussed have inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robots and electronic devices transported by people or animals.

[0113] Additionally, although the apparatus has been depicted as a single entity, different units, processors and / or memory units may be implemented. Figure 4 Not all are shown).

[0114] 5G allows the use of multiple-input-multiple-output (MIMO) antennas, more base stations or nodes than LTE (the so-called small cell concept), including macro sites that operate in conjunction with smaller stations and adopt various radio technologies depending on service needs, usage and / or available spectrum. 5G mobile communications support a wide range of use cases and related applications, including video streaming, augmented reality, different ways of sharing data and various forms of machine-type applications (such as (massive) machine-type communications (mMTC), including vehicle safety, different sensors and real-time control). 5G is expected to have multiple radio interfaces, for example, below 6 GHz or above 24 GHz, cmWave and mmWave, and can also be integrated with existing traditional radio access technologies (e.g., LTE). At least in the early stages, integration with LTE can be implemented as a system in which macro coverage is provided by LTE and 5G wireless interface access comes from small cells by aggregation to LTE. In other words, 5G plans to support inter-RAT operability (e.g., LTE-5G) and inter-RI operability (inter-radio interface operability, e.g., below 6GHz - cmWave, 6 or above 24GHz - cmWave, and mmWave). One of the concepts considered for use in 5G networks is network slicing, in which multiple independent and dedicated virtual subnetworks (network instances) can be created within the same infrastructure to run services with different requirements for latency, reliability, throughput, and mobility.

[0115] LTE network architecture is completely distributed in the radio and completely concentrated in the core network. Low-latency applications and services in 5G need to bring content close to the radio, which leads to local interruptions and multi-access edge computing (MEC). 5G enables analysis and knowledge generation to occur at the data source. The method requires the use of resources that may not be continuously connected to the network, such as laptops, smart phones, tablet computers and sensors. MEC provides a distributed computing environment for application and service hosting. It also has the ability to store and process content near cellular subscribers to obtain faster response times. Edge computing covers a wide range of technologies, such as wireless sensor networks, mobile data collection, mobile signature analysis, collaborative distributed peer-to-peer self-organizing networking and processing, which can also be classified as local cloud / fog computing and grid / grid computing, dew computing, mobile edge computing, cloud gathering, distributed data storage and retrieval, autonomous self-healing networks, remote cloud services, augmented and virtual reality, data caching, Internet of Things (large-scale connectivity and / or latency critical), critical communications (autonomous vehicles, traffic safety, real-time analysis, time-critical control, medical applications).

[0116] The communication system via gNB 120-1 may also be able to communicate with other networks 160, such as a public switched telephone network, or a VoIP network, or the Internet, or a private network, or utilize services provided by them. The communication network may also be able to support the use of cloud services, for example, at least a portion of the core network operations may be performed as a cloud service. When performed away from the core network, this may also be referred to as edge computing. The communication system may also include a central control entity, etc., which provides facilities for networks of different operators to collaborate, for example in spectrum sharing.

[0117] Edge computing technology can be introduced into the radio access network (RAN) using network function virtualization (NFV) and software defined network (SDN). The use of edge cloud technology can mean that the access node operation is at least partially performed in a server, host or node that is operatively coupled to a remote radio head or base station including a radio part. Node operations may also be distributed between multiple servers, nodes or hosts. The application of cloud RAN architecture enables the execution of RAN real-time functions at or near the remote antenna site (in a distributed unit, DU 121 of gNB 120-1), and the execution of centralized functions (also including functions involving the core network 150) in a centralized manner (in the centralized unit CU 122 of gNB 120-1). DU 121 and CU are connected via the F1 interface. CU 122 is connected to the 5G core network (5GC) 150 via the NG interface. CU 122 can be split into a user plane CU-UP and a control plane CU-CP. However, in some cases, this split does not exist in CU 122. The centralized unit control plane CU CP 123 of CU 122 provides control data for broadcast services. CU CP 123 is connected to 5GC 150 using the NG-C interface. It should also be understood that the allocation of labor between core network operations and base station operations may be different from that of the 5G standard in the future or even non-existent. Some other technological advances that may be used are big data and all-IP, which can change the way networks are being constructed and managed. 5G (or new radio, NR) networks are designed to support multiple layers, where edge computing servers can be placed between the core and the base station or Node B (gNB). An example of edge computing is MEC, which is defined by the European Telecommunications Standards Institute. It should be understood that MEC (and other edge computing protocols) can also be applied in 4G networks.

[0118] 5G can also make use of satellite communications to enhance or complement the coverage of 5G services, for example by providing backhaul. Possible use cases are providing service continuity for machine-to-machine (M2M) or Internet of Things (IoT) devices or for passengers on board vehicles, mobile broadband (MBB), or ensuring service availability for critical communications and future rail / maritime / aeronautical communications. Satellite communications can make use of geostationary earth orbit (GEO) satellite systems, but can also make use of low earth orbit (LEO) satellite systems, in particular mega-constellations (systems where hundreds of (nano) satellites are deployed). Each satellite in a mega-constellation can cover several satellite-enabled network entities creating terrestrial cells. Cells on the ground can be created by relay nodes on the ground or by gNBs located on the ground or in satellites.

[0119] Figure 4The system shown in is only an example of a part of a radio access system, and in practice, the system may include multiple gNBs, UE 140-1, 140-2 may have access to multiple radio cells, and the system may also include other devices, such as physical layer relay nodes or other network elements. At least one of the gNBs may be a Home (e / g) Node B. In addition, in a geographical area of ​​the wireless communication system, multiple different kinds of radio cells as well as multiple radio cells may be provided. The radio cells may be macro cells (or umbrella cells), which are large cells (typically having a diameter of up to tens of kilometers) or smaller cells (such as micro, femto or pico cells). Figure 4 The gNB 120-1 may provide any type of these cells. A cellular radio system may be implemented as a multi-layer network including several types of cells.

[0120] Figure 4 The components and / or related circuits of the gNB 120-1 shown in the figure may also be referred to as "components for sending...", "components for receiving...", "components for determining...", "components for providing...", etc.

[0121] For the scenario where RedCap UE and normal UE operate together, the embodiments described herein help the source DU 121 decide whether it can use at least one RedCap CFR to receive broadcast / multicast sessions for normal UE (e.g., UE 140-1) and for RedCap UE (e.g., UE 140-2), or whether it requires two separate CFRs, one for each type of UE. To facilitate this, there are signaling enhancements on the NG and F1 interfaces. The signaling enhancements are explained in the following embodiments.

[0122] In one embodiment, there are two broadcast session establishment requests from the core network (5G core (5GC)) 150 to the gNB 120-1, that is, each type of UE (normal UE 140-1 and RedCap UE 140-2) has a broadcast session establishment request. 5GC 150 can create two TMGIs (session identifiers) TMGI 1 and TMGI 2, and send different QoS standards for the two types of UEs 140-1, 140-2.

[0123] On the NG interface, 5GC 150 sends an indication to the control plane (CP) of the central unit (CU-CP) 123 of gNB 120-1 via NGAP whether TMGI 2 is used for an MBS broadcast session for RedCap UEs, and the QoS associated with the session. In addition, 5GC 150 sends to gNB 120-1 (specifically, to CU 122 of gNB 120-1) a link to the normal (non-RedCap) TMGI 1 for the same broadcast session associated with it, indicating that normal TMGI 1 is also available for the same broadcast service, but for a different UE type. 5GC 150 may also send a link for the normal MBS broadcast session TMGI 1 to the RedCap MBS broadcast session TMGI 2 associated with it, indicating that TMGI 1 is also available for RedCap UEs in the MBS service session.

[0124] If CU 122 is split into CU UP and CU CP, gNB-CU CP 123 receives two different F1-U transport addresses from gNB-DU 121, or receives an indication from DU 121 that RedCap CFR cannot be used for TMGI 1 (for normal UE) and TMGI 2 (for RedCap UE), gNB 120-1 sends back two different NG-U transport addresses to 5GC 150 to achieve two different deliveries on NG-U. If CU 122 is not split, gNB 102-1 will send these to 5GC 150.

[0125] If CU CP 123 receives only one F1-U tunnel endpoint from DU 121, or receives an indication from DU 121 that RedCap CFR can be used for both TMGI 1 (for non-RedCap UE) and TMGI 2 (for RedCap UE), gNB 120-1 sends back only one NG-U tunnel endpoint to 5GC 150 to enable only one delivery over NG-U.

[0126] Another embodiment relates to aspects of the F1 interface. CU CP 123 sends an F1AP broadcast setup request to DU 121, the F1AP broadcast setup request including an indication of whether TMGI 2 is used for an MBS broadcast session for RedCap UEs, and the QoS (MRB QoS and / or QoS flow QoS) associated with the session of TMGI 2. CU CP 123 may also send a link from a non-RedCapMBS broadcast session TMGI 1 to a RedCap MBS broadcast session TMGI 2 associated therewith, and the QoS (MRB QoS and / or QoS flow QoS) associated with the session of the RedCap TMGI.

[0127] If DU 121 considers the received QoS parameters and decides that RedCap CFR cannot be used for TMGI 1 (for normal UE) and TMGI 2 (for RedCap UE), DU 121 sends back two different F1-U transport addresses to CU CP 123 to achieve two different deliveries on F1-U.

[0128] On the contrary, if DU 121 decides that RedCapCFR can be used for TMGI 1 (for normal UEs) and TMGI 2 (for RedCap UEs) considering the received QoS parameters, DU 121 sends back the F1-U transport address already used for TMGI 1 and / or a new indicator pointing to the F1-U transport address used by shared TMGI 1.

[0129] In a further implementation of this embodiment, for both non-RedCap and RedCap UEs, only one broadcast session establishment request is sent from the core network (5G Core (5GC) 150) to the gNB 120-1. In the broadcast session establishment request message, the 5GC 150 may send two different QoS parameter sets, corresponding to the delivery to the non-RedCap UE 140-1 and the delivery to the RedCap UE 140-2, respectively.

[0130] In a further embodiment, relating to aspects of the NG interface, the 5GC 150 sends two sets of QoS requirements for the same TMGI in an MBS broadcast session request via the CU CP 123 of the gNB 120-1. One set of QoS requirements is sent for non-RedCap UEs (e.g., UE 140-1), and new QoS requirements are sent for RedCap UEs (e.g., UE 140-2). If the CU CP 123 receives two different F1-U transport addresses from DU 121 and / or an indication from DU 121 that the redcap CFR cannot be used to match the requirements of the two sets of QoS parameters, the gNB 120-1 sends two different NG-U transport addresses back to the 5GC 150 to achieve two different deliveries over NG-U. If CU CP 123 receives only one F1-U transport address from DU 121, and optionally receives an indication from DU 121 that redcap CFR can be used to match two sets of QoS parameters, gNB 120-1 sends only one NG-U transport address back to 5GC 150 to enable only one delivery over NG-U.

[0131] Another embodiment relates to aspects of the F1 interface. CU CP 123 sends two sets of QoS parameters (MRB QoS and / or QoS Flow QoS) associated with sessions of the same TMGI to DU 121 in an F1AP broadcast setup request. If DU 121 determines that RedCap CFR cannot be used to match the requirements of the two sets of received QoS parameters (for non-RedCap UE and for RedCap UE) in consideration of the received QoS parameters, DU 121 sends back two different F1-U transport addresses to CU CP 123 to achieve two different deliveries on F1-U.

[0132] Conversely, if DU 121 considers the received QoS parameters and decides that RedCap CFR can be used to match both sets of received QoS parameters (for non-RedCap UE and RedCap UE), DU 121 sends back one F1-U transport address and optionally a new indicator pointing to the sharing of the F1-U transport address.

[0133] A further embodiment relates to aspects of the gNB-DU. In this embodiment, the DU 121 of the gNB 120-1 decides whether the same generic CFR can be used for a RedCap UE (e.g., UE 140-2) and a non-RedCap UE (e.g., UE 140-1) based on the quality of service (QoS) requirements of the RedCap UE and the quality of service (QoS) requirements of the non-RedCap UE.

[0134] Now we will see Figures 5 to 8 Various embodiments are described with reference to the signal flow diagrams shown in FIG.

[0135] Figure 5 An embodiment proceeding through steps 5-1 - 5-7 is shown.

[0136] Step 5-1: 5GC 150 sends an NG broadcast establishment request, which includes TMGI 2 and related QoS parameters, and may also include a RedCap indication indicating that the broadcast session corresponds to a RedCap UE. Similarly, CU CP 123 sends an F1AP broadcast establishment request including TMGI2, associated QoS parameters, and may also include a RedCap indication indicating that the broadcast session corresponds to a RedCap UE.

[0137] Step 5-2: 5GC 150 sends an NG broadcast establishment request message to the non-RedCap UE, which includes TMGI 1 and associated QoS parameters (MBS QoS parameters for MBS QoS flow). The message also includes an indication that the same service can be used by RedCap UEs with link TMGI 2 and / or a RedCap indication.

[0138] Step 5-3: Similarly, CU CP 123 sends an F1AP broadcast setup request message, which includes TMGI 1, associated QoS parameters (MBS QoS parameters for MBS QoS flow), and also includes an indication that the same service is available for UEs with RedCap of the link to TMGI 2 and / or a RedCap indicator.

[0139] Step 5-4: DU 121 considers the received QoS parameters and decides that RedCap CFR cannot be used for TMGI 1 and TMGI2.

[0140] Step 5-5: DU 121 generates SIB20 and MCCH for TMGI 1 in normal CFR (non-RedCap CFR), which are destined for non-RedCap UEs, and generates SIB20 and RedCap MCCH for TMGI 2 in RedCap CFR, which are destined for RedCap UEs.

[0141] Step 5-6: DU 121 sends back an F1AP Broadcast Setup Response for TMGI 1, where the F1-U transport address is different from the F1-U transport address for TMGI 2 for separate delivery.

[0142] Step 5-7: RedCap UE 140-2 receives MCCH through RedCap CFR, and non-RedCap UE 140-1 receives MCCH through non-RedCap CFR.

[0143] Figure 6 The implementation is shown as being performed in steps 6-1 to 6-7 of the signal flow diagram.

[0144] Step 6-1: 5GC 150 sends an NG broadcast establishment request, which includes TMGI 2, associated QoS parameters, and may include a RedCap indication indicating that the broadcast session corresponds to a RedCap UE. Similarly, CUCP 123 sends an F1AP broadcast establishment request including TMGI 1, associated QoS parameters, and may include a RedCap indication indicating that the broadcast session corresponds to a RedCap UE.

[0145] Step 6-2: 5GC 150 sends an NG Broadcast Setup Request message, which includes TMGI 1, associated QoS parameters for normal UEs (MBS QoS parameters for MBS QoS flow), and includes an indication that the same service is available for RedCap UEs with links to TMGI 2 and / or a RedCap indicator.

[0146] Step 6-3: CU CP 123 sends an F1AP broadcast establishment request message, which includes TMGI 1, associated QoS parameters (MRB QoS and flow QoS), and recently includes an indication that the RedCap UE with link TMGI 2 can use the same service and / or a RedCap indication.

[0147] Step 6-4: DU 121 considers the received QoS parameters and decides that RedCap CFR can be used for TMGI 1 and TMGI 2.

[0148] Step 6-5: DU 121 generates MCCH and / or SIBx common to TMGI 2 and TMGI 1 in RedCap CFR, which are destined for RedCap UE 140-2 and non-RedCap UE 140-1.

[0149] Step 6-6: DU 121 sends an F1AP Broadcast Setup Response for TMGI 2 to CU CP 123, which newly includes the F1-U transport address already used for TMGI 1 and / or a new indicator pointing to the F1-U address used by the shared TMGI 1.

[0150] Step 6-7: Both the RedCap UE 140-2 and the non-RedCap UE 140-1 receive the common MCCH of TMGI 1 and TMGI 2 in the RedCap CFR for broadcast data reception from the DU 121.

[0151] Figure 7 An embodiment performed by steps 7-1 to 7-7 of the signal flow diagram is shown.

[0152] Step 7-1: 5GC 150 determines that there is a single MBS session (single TMGI) for both non-RedCap UE 140-1 and RedCap UE 140-2.

[0153] Step 7-2: 5GC 150 sends a NG Broadcast Setup Request, requesting a single TMGI, denoted as TMGI-1. However, this single TMGI-1 contains two sets of associated QoS parameters, one set for a normal UE marked as normal QoS (e.g., UE 140-1), and the other set for an alternative / RedCap UE (e.g., UE 140-2) marked as RedCap / Alternative QoS.

[0154] Step 7-3: Similarly, the CU CP 123 sends an F1AP broadcast setup request message including TMGI 1, associated QoS parameters for two QoS sets, and QoS flows (Non-RedCap QoS and RedCap QoS).

[0155] Step 7-4: DU 121 considers the QoS parameters received from CU-CP 123, considers their QoS requirements, and decides that RedCap CFR cannot be used for both normal UEs and RedCap UEs.

[0156] Step 7-5: For the same common TMGI-1, DU 121 generates SIB20 and MCCH for non-RedCap UEs in non-RedCap CFR, and generates SIB20 and RedCap MCCH for RedCap UEs in RedCap CFR.

[0157] Step 7-6: DU 121 sends back an F1AP Broadcast Setup Response for the common TMGI 1 through two separate F1-U tunnels using two different F1-U addresses for normal and RedCapCFR for split delivery.

[0158] Step 7-7: The RedCap UE 140-2 receives the MCCH through the RedCap CFR, and the Non-RedCap UE 140-1 receives the MCCH through the Non-RedCap CFR.

[0159] Figure 8 An implementation performed by steps 8-1 to 8-7 of the signal flow diagram is shown.

[0160] Step 8-1: 5GC 150 determines that there is a single MBS service session (single TMGI) for both non-RedCap UE 140-1 and RedCap UE 140-2.

[0161] Step 8-2: 5GC 150 sends a NG broadcast setup request for a single TMGI (labeled as TMGI-1). However, this single TMGI-1 contains two sets of associated QoS parameters, one set for non-RedCap (normal) UE 140-1 labeled as normal QoS, and the other set for alternative / RedCap UE 140-2 labeled as RedCap / alternative QoS.

[0162] Step 8-3: Similarly, the CU CP 123 sends an F1AP broadcast setup request message including TMGI 1, associated QoS parameters for two QoS sets, and QoS flows (Non-RedCap QoS and RedCap QoS).

[0163] Step 8-4: DU 121 considers the QoS parameters received from CU CP 123 and decides that RedCap CFR can be used for both Non-RedCap UE 140-1 and RedCap UE 140-2 considering their QoS requirements.

[0164] Step 8-5: For the same common TMGI-1, DU 121 generates SIB20 and Normal MCCH and SIB20 and RedCap MCCH in RedCap CFR for Normal UE 140-1 and RedCap UE 140-2, respectively.

[0165] Step 8-6: DU 121 sends back an F1AP Broadcast Setup Response for the public TMGI.

[0166] Step 8-7: RedCap UE 140-2 receives MCCH in RedCap CFR, and non-RedCap UE 140-1 also receives normal MCCH in RedCap CFR.

[0167] Fig. 9 A flow chart depicting a method according to an embodiment is shown. The method may be performed by gNB 120-1 or a similar device or component of gNB 120-1. For simplicity, the method performed by gNB 120-1 will be described here.

[0168] In step 9-1, gNB 120-1 receives first QoS information of performance-constrained (RedCap) UE 140-2 and second QoS information of non-performance-constrained (non-RedCap) UE 140-1. Both the first and second QoS information relate to an MBS broadcast or multicast session available on RedCap UE 140-2 and non-RedCap UE 140-1.

[0169] gNB 120-1 may receive a broadcast session establishment request from core network 150, the request including broadcast session details, which are TMGI and its corresponding QoS information. TMGI includes MBMS service identifier, mobile country code and mobile network code.

[0170] In addition to QoS information, gNB 120-1 may also receive other information from core network 150.

[0171] In step 9-2, the gNB 120-1 determines whether the CFR associated with the RedCap UE 140-2 can be used for receiving the MBS broadcast or multicast session by the RedCap UE 140-2 and the non-RedCap UE 140-1 based on the received first and second QoS information;

[0172] In step 9-3, if it is determined that the common frequency resources associated with the RedCap UE 140-2 cannot be used by both the RedCap UE 140-2 and the non-RedCap UE 140-1 to receive the MBS broadcast or multicast session, the gNB 120-1 provides a first tunnel for sending the MBS broadcast or multicast session to the RedCap UE 140-2 and a second tunnel for sending the MBS broadcast or multicast session to the non-RedCap UE 140-1.

[0173] In step 9-4, if the gNB 120-1 has determined that the CFR associated with the RedCap UE 140-2 can be used to receive the MBS broadcast or multicast session by both the RedCap UE 140-2 and the non-RedCap UE 140-1, the gNB only provides one transport tunnel for sending the MBS broadcast or multicast session to the RedCap UE 140-2 and for sending the MBS broadcast or multicast session to the non-RedCap UE 140-1.

[0174] Fig.10 A flow chart representing a method according to an embodiment is shown, which may be performed by CU 122 of gNB 120-1 or similar device or CU CP 123 of gNB 120-1. For simplicity, the method will be described as being performed by CU CP 123.

[0175] In step 10-1, CU CP 123 receives first QoS information for RedCap UE 140-2 and second QoS information for non-RedCap UE 140-1 from 5GC 150. The first and second QoS information relate to an MBS broadcast or multicast session available for both performance-limited UE 140-2 and non-performance-limited UE 140-1;

[0176] In step 10-2, the CU CP 123 determines whether the CFR associated with the performance-limited UE 140-2 can be used to receive the MBS broadcast or multicast session through the performance-limited UE 140-2 and the non-performance-limited UE 140-1 based on the received first and second QoS information.

[0177] In step 10-3, the CU CP 123 provides at least one of the following back to the 5G Core 150:

[0178] If it is determined that the common frequency resources associated with the performance limited UE 140-2 can be used by both the performance limited UE 140-2 and the non-performance limited UE 140-1 to receive the MBS broadcast or multicast session, sending the MBS broadcast or multicast session to a single tunnel transport layer address (TNLA) of both the performance limited UE 140-2 and the non-performance limited UE 140-1,

[0179] If it is determined that the CFR associated with the performance-constrained UE 140-2 cannot be used by both the performance-constrained UE 140-2 and the non-performance-constrained UE 140-1 to receive the MBS broadcast or multicast session, then a separate tunnel TNLA,

[0180] If it is determined that the CFR associated with the performance-limited UE 140-2 is usable for receiving the MBS broadcast or multicast session by both the performance-limited UE 140-2 and the non-performance-limited UE 140-1, an indicator indicating that the CFR associated with the performance-limited UE 140-2 is usable for receiving the MBS broadcast or multicast session by both the performance-limited UE 140-2 and the non-performance-limited UE 140-1, and / or

[0181] If it is determined by CU CP 123 that the common frequency resources associated with performance limited UE 140-2 cannot be used for receiving MBS broadcast or multicast session by both performance limited UE 140-2 and non-performance limited UE 140-1, an indicator indicating that the common frequency resources associated with performance limited UE 140-2 cannot be used for receiving MBS broadcast or multicast session by both performance limited UE 140-2 and non-performance limited UE 140-1 is provided.

[0182] Fig.11 A flow chart representing a method according to an embodiment is shown, which may be performed by DU 121 or a similar device of gNB 120-1. For simplicity, the method will be described as being performed by DU 121.

[0183] In step 11-1, DU 121 of gNB 120-1 receives first QoS information for performance-limited UE 140-2 and second QoS information for non-performance-limited UE 140-1 from central unit control plane CU CP 123 of gNB 120-1. The first and second QoS information relate to MBS broadcast or multicast sessions that can be used for both performance-limited UE 140-2 and non-performance-limited UE 140-1.

[0184] At step 11-2, based on the received first and second QoS information, DU 121 determines whether the CFR associated with performance-limited UE 140-2 can be used by both performance-limited UE 140-2 and non-performance-limited UE 140-1 to receive the MBS broadcast or multicast session.

[0185] In step 11-3, DU 121 provides at least one of the following to the CU CP:

[0186] a single tunnel transport layer address (TNLA) for sending the MBS broadcast or multicast session to both the performance-constrained UE 140-2 and the non-performance-constrained UE 140-1 if the DU 121 determines that the CFR associated with the performance-constrained UE 140-2 can be used by both the performance-constrained UE 140-2 and the non-performance-constrained UE 140-1 to receive the MBS broadcast or multicast session,

[0187] If DU 121 determines that the CFR associated with performance-constrained UE 140-2 cannot be used by both performance-constrained UE 140-2 and non-performance-constrained UE 140-1 to receive the MBS broadcast or multicast session, then a separate tunnel TNLA is used.

[0188] If the DU 121 determines that the CFR associated with the performance-limited UE 140-2 is usable for receiving the MBS broadcast or multicast session by both the performance-limited UE 140-2 and the non-performance-limited UE 140-1, an indicator indicating that the CFR associated with the performance-limited UE 140-2 is usable for receiving the MBS broadcast or multicast session by both the performance-limited UE 140-2 and the non-performance-limited UE 140-1, and / or

[0189] If DU 121 determines that the CFR associated with performance limited UE 140-2 cannot be used by both performance limited UE 140-2 and non-performance limited UE 140-1 to receive the MBS broadcast or multicast session, an indicator indicating that the CFR associated with performance limited UE 140-2 cannot be used by both performance limited UE 140-2 and non-performance limited UE 140-1 to receive the MBS broadcast or multicast session.

[0190] After the network at gNB 120-1 receives the first MBS session broadcast request for RedCap UE 140-2 along with the corresponding TMGI and QoS details, the core network 150 determines that the same MBS service is also for non-RedCap UE 140-1.

[0191] The core network 150 sends another broadcast session establishment request, this time with its own TMGI and QoS details, to the non-RedCap UE 140-1, along with the link for the TMGI and associated QoS of the RedCap UE.

[0192] When the network or gNB 120-1 examines the broadcast session establishment request for non-RedCap UE 140-1, which contains the link for TMGI and QoS for RedCap UE 140-2, it then only checks whether the same common frequency resources can be used for both RedCap and non-RedCap UEs. It is not a default that gNB 120-1 will check this because it is receiving two different TMGI establishment requests.

[0193] The 5G core network function is configured with information about specific broadcast services for both RedCap and non-RedCap UEs, and provides QoS information based on this configuration.

[0194] The present disclosure presents the following example embodiments.

[0195] Example 1. An apparatus, comprising at least one processor and at least one memory comprising computer program code, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to: receive first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE, wherein the first QoS information and the second QoS information relate to a broadcast or multicast session that can be used for both at least one of the performance-constrained UEs and at least one of the non-performance-constrained UEs; determine, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with at least one of the performance-constrained UEs can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the broadcast or multicast session; and if it is determined that the common frequency resource associated with at least one of the performance-constrained UEs can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the broadcast or multicast session; If the common frequency resources associated with one of the performance-limited UEs cannot be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, a first tunnel for the transmission of the broadcast or multicast session is provided to at least one of the performance-limited UEs and a second tunnel for the transmission of the broadcast or multicast session is provided to at least one of the non-performance-limited UEs; and if it is determined that the common frequency resources associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the broadcast or multicast session, the first tunnel for the transmission of the broadcast or multicast session is provided to the performance-limited UE and the first tunnel for the transmission of the broadcast or multicast session is provided to the non-performance-limited UE.

[0196] Example 2. An apparatus according to Example 1, wherein the apparatus is further configured to receive at least one of: second information, together with the first QoS information, indicating that the first QoS information is for performance-constrained UEs, and / or third information, together with the second QoS information, indicating that the second QoS information is for non-performance-constrained UEs, and wherein the determination is also based on the second information and the third information.

[0197] Example 3. An apparatus comprising at least one processor and at least one memory comprising computer program code, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to: receive first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE from a 5G core network function, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE; determine, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; and return to the 5G core network function at least one of the following: a single tunnel transport layer address (TNLA) for the transmission of the broadcast or multicast session for both the performance-constrained UE and the non-performance-constrained UE, if it is determined that the common frequency resource associated with the performance-constrained UE The frequency resource can be used by both the performance-limited UE and the non-performance-limited UE for receiving the broadcast or multicast session, the independent tunnel TNLA, if it is determined that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE for receiving the broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE for receiving the broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session.

[0198] Example 4. An apparatus according to Example 2, wherein the first QoS information and the second QoS information received from the 5G core network function 5GCNF are associated with the same broadcast or multicast session identifier or temporary mobile group identifier TMGI.

[0199] Example 5. The apparatus of Example 2 or 3, wherein the first QoS information and the second QoS information are received from the 5GC in an NG application protocol broadcast or multicast setup request or modification request message.

[0200] Example 6. An apparatus according to Example 2, wherein the first QoS information is received from the 5GC associated with a first broadcast or multicast session identifier or TMGI 1 and the second QoS information is received from the 5GC associated with a second broadcast or multicast session identifier or TMGI 2.

[0201] Example 7. The apparatus of Example 5, wherein the first QoS information is received in a first NG application protocol broadcast or multicast setup or modification request message including the first broadcast or multicast session identifier TMGI 1 and the second QoS information is received in a second NG application protocol broadcast or multicast setup or modification request message including the second broadcast or multicast session identifier TMGI 2.

[0202] Example 8. The apparatus of Example 5, wherein the determining is further performed based on an indication received from the 5GC, the indication indicating that the first broadcast or multicast session identifier or TMGI 1 and the second broadcast or multicast session identifier or TMGI 1 both relate to the same MBS broadcast or multicast session.

[0203] Example 9. The apparatus of any of Examples 2 to 7, wherein the apparatus is included within a radio access node.

[0204] Example 10. The apparatus of Example 8, wherein the apparatus is comprised in a Central Unit Control Plane (CU CP) entity of a radio access node.

[0205] Example 11. The apparatus of Example 9, wherein the determining comprises: sending first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE to a distributed unit (DU) of the wireless access node, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE, and receiving at least one of the following from the DU: a single DU tunnel TNLA, if it is determined that the common frequency resources associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session, an independent DU tunnel TNLA, if it is determined that the common frequency resources associated with the performance-constrained UE cannot be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session E is used by both to receive the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session.

[0206] Example 12. An apparatus comprising at least one processor and at least one memory comprising computer program code, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to: receive, at the distributed unit DU of a radio access node, first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE from a central unit CU of the radio access node, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE, and at the DU, determine, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; and return to the CU at least one of the following: a single tunnel transport layer address (TNLA) for the transmission of the MBS broadcast or multicast session for both the performance-constrained UE and the non-performance-constrained UE, if it is determined that the common frequency resource associated with the performance-constrained UE is usable by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session. The common frequency resource associated with the UE can be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, and the independent tunnel TNLA, if it is determined that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE for receiving the MBS broadcast or multicast session.

[0207] Example 13. The apparatus of Example 11, wherein the first QoS information and the second QoS information received from the CU are associated with the same broadcast or multicast session identifier or TMGI.

[0208] Example 14. The apparatus of Example 11 or 12, wherein the first QoS information and the second QoS information are received from the CU in an F1 application protocol broadcast or multicast setup request or modification request message.

[0209] Example 15. The apparatus of Example 11, wherein the first QoS information is received from the CU associated with a first broadcast or multicast session identifier or TMGI 1 and the second QoS information is received from the CU associated with a second broadcast or multicast session identifier or TMGI 2.

[0210] Example 16. The apparatus of Example 14, wherein the first QoS information is received in a first F1 application protocol broadcast or multicast setup or modification request message including the first broadcast or multicast session identifier TMGI 1 and the second QoS information is received in a second F1 application protocol broadcast or multicast setup or modification request message including the second broadcast or multicast session identifier TMGI 2.

[0211] Example 17. The apparatus of Example 14, wherein the determining is further performed based on an indication received from the CU, the indication indicating that both the first broadcast or multicast session identifier or TMGI 1 and the second broadcast or multicast session identifier or TMGI 1 relate to the same MBS broadcast or multicast session.

[0212] Example 18. An apparatus comprising: a component for receiving first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE; a component for determining, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; and a component for determining, if it is determined that the common frequency resource associated with the performance-constrained UE cannot be used by both the performance-constrained UE and the non-performance-constrained UE, The present invention relates to a method for transmitting the MBS broadcast or multicast session to a UE having performance-limited frequency and providing a first tunnel for the transmission of the MBS broadcast or multicast session to the performance-limited UE and a second tunnel for the transmission of the MBS broadcast or multicast session to the non-performance-limited UE if both the performance-limited UE and the non-performance-limited UE are used to receive the MBS broadcast or multicast session; and a method for transmitting the first tunnel for the transmission of the MBS broadcast or multicast session to the performance-limited UE and providing the first tunnel for the transmission of the MBS broadcast or multicast session to the non-performance-limited UE if it is determined that the common frequency resources associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session.

[0213] Example 19. The apparatus of Example 17, wherein the apparatus is a distributed unit DU of a radio access node.

[0214] Example 20. A method, comprising: receiving first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE; determining, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; and if it is determined that the common frequency resource associated with the performance-constrained UE cannot be used by both the performance-constrained UE and the non-performance-constrained UE, If both the performance-limited UE and the non-performance-limited UE are used to receive the MBS broadcast or multicast session, a first tunnel for the transmission of the MBS broadcast or multicast session is provided to the performance-limited UE and a second tunnel for the transmission of the MBS broadcast or multicast session is provided to the non-performance-limited UE; and if it is determined that the common frequency resources associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, the first tunnel for the transmission of the MBS broadcast or multicast session is provided to the performance-limited UE and the first tunnel for the transmission of the MBS broadcast or multicast session is provided to the non-performance-limited UE.

[0215] Example 21. A method, comprising: receiving first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE from a 5G core, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE; determining, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; and returning to the 5GC at least one of the following: a single tunnel transport layer address (TNLA) for the transmission of the MBS broadcast or multicast session for both the performance-constrained UE and the non-performance-constrained UE, if it is determined that the common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session , independent tunnel TNLA, if it is determined that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE for the MBS reception broadcast or multicast session, if it is determined that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session.

[0216] Example 22. A method, comprising: receiving, at the distributed unit DU of a radio access node, first QoS information for a performance-constrained UE and second QoS information for a non-performance-constrained UE from a central unit control plane CU CP of the radio access node, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-constrained UE and the non-performance-constrained UE, at the DU, determining, based on the received first QoS information and the second QoS information, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; and returning to the CU at least one of the following: a single tunnel transport layer address (TNLA) for the transmission of the MBS broadcast or multicast session for both the performance-constrained UE and the non-performance-constrained UE, if it is determined that the common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session, independently Tunnel TNLA, if it is determined that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE for the MBS reception broadcast or multicast session, if it is determined that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session. Example 23. A computer program product, embodied on a distribution medium readable by a computer and comprising program instructions, when the program is executed by an apparatus, causes the apparatus to perform the method according to Examples 20 to 22.

[0217] Example 24. A computer program product comprises program instructions, which, when executed by an apparatus, cause the apparatus to perform the method according to examples 20 to 22.

[0218] Although the invention has been described above with reference to specific embodiments, it is not limited to these embodiments and those skilled in the art will undoubtedly suggest further alternatives which are within the scope of the invention as claimed.

[0219] Features of each embodiment may also be combined with features from other embodiments and are not limited to those described here.

Claims

1. An apparatus comprising at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to: receiving first QoS information for performance-limited UEs and second QoS information for non-performance-limited UEs, wherein the first QoS information and the second QoS information relate to a broadcast or multicast session that may be used for both at least one of the performance-limited UEs and at least one of the non-performance-limited UEs; determining, based on the received first QoS information and the received second QoS information, whether a common frequency resource associated with at least one of the performance-constrained UEs can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the broadcast or multicast session; If it is determined that the common frequency resources associated with at least one of the performance-limited UEs cannot be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, providing a first tunnel for the transmission of the broadcast or multicast session to at least one of the performance-limited UEs and providing a second tunnel for the transmission of the broadcast or multicast session to at least one of the non-performance-limited UEs; as well as If it is determined that the common frequency resources associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE to receive the broadcast or multicast session, the first tunnel for the transmission of the broadcast or multicast session is provided to the performance limited UE and the first tunnel for the transmission of the broadcast or multicast session is provided to the non-performance limited UE.

2. The apparatus of claim 1, wherein the apparatus is further configured to receive at least one of: second information, together with the first QoS information, indicating that the first QoS information is for performance-constrained UEs, and / or The third information, together with the second QoS information, indicates that the second QoS information is for non-capability-constrained UEs, And wherein the determining is also based on the second information and the third information.

3. An apparatus comprising at least one processor and at least one memory comprising computer program code, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to: receiving, from a 5G core network function, first QoS information for a performance-limited UE and second QoS information for a non-performance-limited UE, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that may be used for both the performance-limited UE and the non-performance-limited UE; determining, based on the received first QoS information and the received second QoS information, whether a common frequency resource associated with the performance-constrained UE can be used by both the performance-constrained UE and the non-performance-constrained UE to receive the MBS broadcast or multicast session; as well as Return at least one of the following to the 5G core network function: a single tunnel transport layer address (TNLA) for the transmission of the broadcast or multicast session for both the performance limited UE and the non-performance limited UE, if it is determined that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE to receive the broadcast or multicast session, A separate tunnel TNLA, if it is determined that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE to receive the broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE for receiving the broadcast or multicast session, if it is determined that the common frequency resource associated with the performance limited UE can be used by both the performance limited UE and the non-performance limited UE for receiving the broadcast or multicast session, An indicator indicating that the common frequency resources associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE to receive the MBS broadcast or multicast session, if it is determined that the common frequency resources associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE to receive the MBS broadcast or multicast session.

4. The apparatus according to claim 2, wherein the first QoS information and the second QoS information received from the 5G core network function 5GCNF are associated with the same broadcast or multicast session identifier or temporary mobile group identifier TMGI.

5. An apparatus according to claim 2 or 3, wherein the first QoS information and the second QoS information are received from the 5GC in an NG application protocol broadcast or multicast establishment request or modification request message.

6. An apparatus according to claim 2, wherein the first QoS information is received from the 5GC associated with a first broadcast or multicast session identifier or TMGI 1 and the second QoS information is received from the 5GC associated with a second broadcast or multicast session identifier or TMGI 2.

7. The apparatus of claim 5, wherein the first QoS information is received in a first NG application protocol broadcast or multicast establishment or modification request message containing the first broadcast or multicast session identifier TMGI 1 and the second QoS information is received in a second NG application protocol broadcast or multicast establishment or modification request message containing the second broadcast or multicast session identifier TMGI 2.

8. The apparatus of claim 5, wherein the determining is further performed based on an indication received from the 5GC, The indication indicates that both the first broadcast or multicast session identifier or TMGI 1 and the second broadcast or multicast session identifier or TMGI 1 relate to the same MBS broadcast or multicast session.

9. The apparatus according to any one of claims 2 to 7, wherein the apparatus is comprised within a radio access node.

10. The apparatus of claim 9, wherein the determining comprises: sending first QoS information for a performance-limited UE and second QoS information for a non-performance-limited UE to a distributed unit (DU) of the radio access node, wherein the first QoS information and the second QoS information relate to an MBS broadcast or multicast session that can be used for both the performance-limited UE and the non-performance-limited UE, and At least one of the following is received from the DU: a single DU tunnel TNLA, if it is determined that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, A standalone DU tunnel TNLA, if it is determined that the common frequency resource associated with the performance-limited UE cannot be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, an indicator indicating that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, if it is determined that the common frequency resource associated with the performance-limited UE can be used by both the performance-limited UE and the non-performance-limited UE to receive the MBS broadcast or multicast session, An indicator indicating that the common frequency resources associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session, if it is determined that the common frequency resources associated with the performance limited UE cannot be used by both the performance limited UE and the non-performance limited UE for receiving the MBS broadcast or multicast session.

Images