Dynamic MBMS control method, user equipment and telecommunication system

Abstract

A method for dynamic MBMS control is proposed for a network node in an MBSFN service area to provide MBMS services to one or more UEs. A telecommunication system and a UE implementing the method are also proposed. A plurality of indication messages are received from one or more UEs. Each indication message includes an indication of a service type and / or QoS information about one or more MBMS services. At least one control configuration is determined based on the desired one or more MBMS services. The at least one control configuration is sent to the UEs so that the UEs are configured to effectively receive the desired services.

Description

Technical Field

[0001] The present invention relates to a Multimedia Broadcast / Multicast Service (MBMS) system, and more particularly to a telecommunication system with improved service control for a Multimedia Broadcast Multicast Service Single Frequency Network (MBSFN) service area. Background Art

[0002] MBMS was developed by the 3rd Generation Partnership Project (3GPP) for 3G networks to support video broadcasting and streaming services. Later, 3GPP introduced evolved MBMS (eMBMS) for the Evolved Packet System (EPS).

[0003] In Rel-13 and Rel-14, the MBMS system has been updated to support new services such as public safety, consumer Internet of Things (CIoT), vehicle to everything (V2X), and machine type communication (MTC) functions. For example, group-based communication addressing MTC functions are specified in TS 22.368, and architectural enhancements to facilitate communication with packet data networks and applications (such as MTC applications) are specified in TS 23.682, where user services for UEs using group message delivery using MBMS are specified. Discussions have been ongoing between RAN#78 and RAN#80 on the evolution of 5G broadcast in the Radio Access Network (RAN), summarizing the MBMS technical attributes as “terrestrial broadcast (Further Evolved MBMS or FeMBMS, RP-181342)” and “NR Hybrid Mode Multicast / Broadcast, RP-180669”. The discussion led to a recommendation to leave the standardization of “NR Hybrid Mode Broadcast / Multicast” for further release, as other NR Rel-15 studies / work items have higher priority, and to continue the study of LTE Rel-16 terrestrial broadcast, which led to the recommendation to leave.

[0004] Because other NR Rel-15 studies / work items have higher priority, the standardization of "NR hybrid mode broadcast / multicast" was further released, and the study of LTE Rel-16 terrestrial broadcast was continued. Therefore, the LTE Rel-16 work item (WI) of enhanced EN-TV was approved in RAN#83, which aims to introduce a new PHY frame structure with new CPs and related designs to support enhanced EN-TV services (FeMBMS protocol list, R1-1613790).

[0005] The main attribute of "terrestrial broadcast" is broadcasting only over large and static transmission areas or DL-only, which can usually be achieved using High-Power High-Tower deployments. Broadcast / multicast feature support was not specified in the first two NR releases, Rel-15 and Rel-16. Nevertheless, for some important use cases, broadcast / multicast can provide substantial improvements, especially in terms of system efficiency and user experience.

[0006] Recently, a study project on architectural enhancements for 5G multicast broadcast services was approved in SA2 (SP-190625). Objective A of the SA2 study project is about enabling generic MBMS functionality on the 5G NR system (5GS), and use cases that have been identified to benefit from this functionality include (but are not limited to) public safety and mission critical, V2X applications, transparent IPv4 / IPv6 multicast delivery, IPTV, wireless software delivery, group communications, and IoT applications. Objective B of the SA2 study project is to support broadcast services (e.g., linear TV, live broadcast, smart TV, hosted and OTT content, radio services).

[0007] Approval of a new work item in RAN#86 with the goal of NR RAN support for multicast and broadcast services (RP-193163). The purpose of this Working Item Description (WID) is to provide support for Objective A in the RAN, in line with TR 23.757 (Study of architecture enhancements for 5G multicast broadcast services, Rel-17 NR). In particular, support for public safety and mission critical as design goals, as identified in the SA6 study for Mission Critical (MC) services enhanced with 5G multicast broadcast system (SP-190726) and captured in TR 23.774 and requirements identified in SA1 in TS22.261, clause 6.13.2. One of the main goals and objectives of the RP-193163 WID is to study support for dynamic control of broadcast / multicast transmission areas within a gNB-DU and the RAN requirements to achieve it.

[0008] However, there are still unresolved challenges and limitations regarding the subject of dynamic control of MBMS service areas. Summary of the invention

[0009] The embodiments are described in detail below with reference to the accompanying drawings.

[0010] A method for dynamic MBMS control is proposed for an MBSFN service area to provide MBMS services to one or more UEs. A plurality of indication messages are received from one or more user equipments (UEs). Each indication message includes an indication of a service (e.g., TMGI) or a service requirement (e.g., QoS information) for one or more MBMS services. At least one control configuration is determined based on a service type or QoS information required for the one or more MBMS services. The at least one control configuration is transmitted to the UEs so that the UEs can effectively receive the MBMS services.

[0011] In a further embodiment, after receiving multiple indication messages, UEs are grouped into one or more groups based on the required service type or QoS information of the required service in the indication message, so that UEs requiring the same service are grouped into the same group. One or more control configurations are determined based on user requirements or QoS requirements of the service, each corresponding to a group. The control configurations are sent to the UEs in each group respectively.

[0012] The control configuration includes at least one of the following parameters: multicast control channel (MCCH) configuration, MBMS control information configuration or MBMS scheduling configuration.

[0013] In an optional embodiment, the MBMS area control information includes scheduling information of the MBMS control channel corresponding to each group. The dynamic MBMS control method can be repeated periodically based on the scheduling information or when a change in service requirements is received from UEs.

[0014] The service requirements include at least one of the following parameters required for the corresponding service: a set of sessions, a temporary mobile group identity (TMGI), quality of service (QOS) requirements together with the sessions or TMGI, delay parameters and / or service reliability parameters, such as a maximum allowed packet loss rate.

[0015] The indication message may be an uplink control information (UCI) report including a special type of scheduling request (SR) or buffer status report (BSR) indicating the MBMS service type or service QoS information.

[0016] Alternatively, the indication message may be a medium access control element (MAC CE), including a service type or service QoS information indication in a MAC logical channel.

[0017] Embodiments are advantageous because MBMS area control information is grouped to reduce UE processing power without requiring knowledge of which MCCHs are configured by the RAN to carry the services of interest.

[0018] Another embodiment proposes a UE connectable to an MBSFN service area, receiving an MBMS service dynamically controlled by a network node. The UE includes at least a transmitter and a receiver. The transmitter sends an indication message to the network node. The receiver receives at least one control configuration of the UE. When the service requirement changes, the UE repeats the transmission of the network node.

[0019] As an embodiment, the UE may send an indication message via a media access control element (MAC CE); the indication message includes a service indication in a MAC logical channel. Because only information corresponding to the group needs to be received, the processing power of the UE is reduced.

[0020] In another embodiment, a telecommunication system operable in an MBSFN service area to provide an MBMS service with dynamic MBMS control is provided. The telecommunication system includes a plurality of UEs and at least one network node. The UEs send a plurality of indication messages, each indication message including a service requirement for one or more MBMS services. The network node receives the indication messages from the UEs, determines at least one control configuration based on the desired one or more MBMS services, and transmits the at least one control configuration to the UEs.

[0021] After receiving the multiple indication messages, the network node groups the UEs into one or more groups according to the required service type or the QoS information of the required service in the indication message, so that the UEs requiring the same service or the same service with the same QoS requirement are grouped in the same group. The network node determines one or more control configurations, each control configuration corresponds to a group, and sends the control configurations to the UEs in each group respectively.

[0022] In a further embodiment, the indication message may be an MBMS Counting Response RRC message, a Temporary Mobile Group Identity (TMGI) indication, or a Session Identity indication. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The present invention may be more fully understood by reading the following detailed description and examples with reference to the accompanying drawings, in which:

[0024] Figure 1 An embodiment of a telecommunications system 100 operating in an MBSFN area based on 5G NR is shown;

[0025] Figure 2 An embodiment of a handshake between UE 210 and network 220 is shown;

[0026] Figure 3 A flowchart showing a dynamic MBMS control method according to an embodiment of the present invention;

[0027] Figure 4An MBSFN area 400 according to an embodiment of the present application is shown;

[0028] Figure 5 Display the signal timing of the existing MCCH scheduling protocol;

[0029] Figure 6 Shows the signal timing according to the embodiment proposed to solve the problem;

[0030] Figure 7 shows the timing of signals according to another embodiment; and

[0031] Figure 8 A schematic diagram showing a UE 800 according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0032] The following description is the best mode of implementing the present invention. This description is intended to illustrate the general principles of the present invention and should not be construed as limiting. The scope of the present invention is best determined by reference to the appended claims.

[0033] The requirement for NR MBMS to support dynamic MBMS area configuration has appeared in 3GPP documents such as TR 38.91, WID RP-193163, and TS22.261. In RP-193163 (R17-WID, NR MBMS): It specifies the study of support for dynamic control of broadcast / multicast transmission areas within a gNB-DU and specifies what is required to enable it, if any [RAN2, RAN3]. In TR 38.913 clause 9.1 (5G MBMS service requirements): It states that the study of new RATs should support dynamic adjustment of multicast / broadcast areas based on, for example, user distribution or service requirements. TS 22.261 clause 6.13.2 specifies that the 5G system should be able to set or modify broadcast / multicast service areas within [1s].

[0034] One of the quickest possible ways to achieve a New Radio (NR) MBMS RAN is to consider enhancing the LTE MBMS RAN to meet NR MBMS requirements. However, particularly with regard to the current MBMS area control configuration, there are many challenges and limitations (e.g., in TS 36.300 and TS 36.330) that need to be carefully addressed to achieve NR MBMS. For example, MBSFN areas are static unless changed by Operation and Maintenance (O&M), so there is generally no dynamic change of area control information. The same control information is provided for the entire MBSFN area regardless of the different service requirements that users within the area may have. MBMS control channel information, such as the Multicast Control Channel (MCCH), is then statically configured, i.e., neither the time domain scheduling nor the lower layer configuration changes over time when the service requirements from the UEs change.

[0035] MBMS in NR is designed to support a variety of emerging services that require dynamic adjustment of MBMS regional control information. However, the current MBMS design has many limitations in achieving this requirement. This embodiment addresses these limitations by providing a method that allows dynamic adjustment of MBMS control information based on UEs service requirements. The main innovation of this method is that the method is designed with business needs as the goal, and achieves the adjustment of MBMS control information required by 3GPP in TR 38.913 and RP-1931, while no other proposals are currently considered by 3GPP as a solution.

[0036] In one embodiment, the user requirements mentioned in the application may be one of the various parameters listed below: a service ID or session ID corresponding to one or more services required by the UE, and QoS information related to the service ID or session ID (e.g., delay and packet, frame or bit error rate).

[0037] In a further embodiment, the MBMS area control information involved in the present application may be a configuration for scheduling MCCH or a configuration used together with a multicast control channel (eg, MCCH repetition period, modification period, MCCH offset).

[0038] MBMS in 5G NR is designed to support a wide range of 5G services with different QoS requirements (e.g., public safety, mission-critical, V2X, and IPTV applications). To achieve this, the 5G MBMS RAN is expected to dynamically adjust the broadcast / multicast service area configuration based on UEs support to provide MBMS services within a reasonable time.

[0039] One embodiment of the present application adjusts MBSFN area control information according to service requirements. In implementation, the MBSFN area is first defined as a group of cells within an MBSFN synchronization area, which collaborate to implement the transmission of MBMS services. An MBSFN area can cover multiple cells, and each cell can belong to up to 8 MBSFN areas. The MBSFN synchronization area is defined as a group of eNodeBs that perform MBSFN transmissions synchronously. All cells within the MBSFN synchronization area send the same waveform with an extended cyclic prefix (CP) to all UEs, as if it were a single transmission. The MBSFN area can support multiple physical multicast channels (PMCH) (for example, 15 PMCHs). Each PMCH corresponds to a multicast channel (MCH). Each MCH can multiplex multiple (for example, 29) multicast logical channels. Each MBSFN area can have a multicast control channel (MCCH). Therefore, one MCH can reuse one MCCH and multiple multicast traffic channels (MTCHs), and the remaining MCHs can reuse multiple MTCHs. In 5G NR, due to the introduction of the gNB split architecture in the 5G NR network, different MBSFN area scenarios are expected, so new elements such as gNB-Centralized Unit (gNB-CU) and gNB Distributed Unit (gNB-DU) are introduced.

[0040] Figure 1 An embodiment of a telecommunications system 100 based on 5G NR operating in an MBSFN area is shown, including a core network 110 interconnected to one or more gNB-CUs 120 using a control plane interface N2 and a user plane interface N3, the gNB-CU 120 is interconnected to the gNB-DU via an F1 interface, and to another gNB via an Xn (i.e., X2) logical interface. Three possible MBSFN scenarios are as follows Figure 1 shown.

[0041] 1) Intra-gNB-DU MBSFN scenario 150: In which all cells 170 involved in MBSFN are within one gNB-DU 130. The gNB-DU 130 MAC entity is responsible for performing scheduling and radio resource allocation. This scenario does not involve external interfaces and does not require synchronization protocols. Therefore, the expected latency is low.

[0042] 2) Inter-gNB-DU MBSFN scenario 160: For all cells 170 under the coverage of more than one gNB-DU 130, there is only one gNB-CU 120. In this case, the gNB-CU 120 is responsible for performing scheduling and radio resource allocation. The F1 interface is involved in this scenario, but the expected latency is still low and no synchronization protocol is required.

[0043] 3) Inter-CU MBSFN scenario 170: for the case where all cells 140 are distributed over several gNB-DUs 130 and these gNB-DUs 130 belong to two or more gNB-CUs 120. The anchor / master CU performs scheduling and radio resource allocation, involving both Xn and F1 interfaces, so the expected latency is medium and a synchronization protocol is required.

[0044] Figure 2 An embodiment of a handshake between UE 210 and network 220 is shown. Dynamic MBMS regional control is disclosed. The network 220 used in this embodiment actually refers to an upper layer node well known to 5G NR experts, such as a RAN node, a core network node, or a Figure 1 The gNB-CUs / gNB-DUs described in the scenario in FIG. 2 are responsible for performing scheduling and radio resource allocation. Therefore, network 220 is a broad term for ease of description and not for limiting the scope.

[0045] exist Figure 2 In the embodiment, first, one or more UEs 210 send an indication message 202 to the network 220, the indication message including a service requirement specific to a broadcast service. The network 220 processes all indication messages 202 from all UEs to determine a control configuration 204 which is then sent back to the UEs. The control configuration 204 includes optimized parameters, such as MBMS control information corresponding to all required broadcast services, so that the UEs 210 are configured accordingly to effectively receive the required services respectively. This embodiment is applicable to Figure 1 All three scenarios described in .

[0046] Figure 3A flowchart of a dynamic MBMS control method according to an embodiment of the present invention is shown. Figure 2 The embodiment starts at step 310. At step 320, when MBMS area control information adjustment is required, multiple UEs each send an indication message to the network.

[0047] As an embodiment, the indication message includes an indication of the UE service requirement indicated via uplink control information (UCI) (for example, by a special type of Scheduling Request (SR) or Buffer Status Report (BSR) indicating the MBMS service type) or through a Media Access Control Element (MAC CE) or through an MBMS counting response RRC message (MBMS counting response RRC message) (for example, indicated by a Temporary Mobile Group Identity (TMGI)).

[0048] In step 330, after receiving the indication message, the network divides the UEs into one or more groups based on the service requirements, so that UEs requiring the same service (or a group of services with the same QoS requirements) are divided into the same group. That is, within the MBSFN area, the UEs are divided into one or more groups (i.e., MBSFN service group areas), each group corresponding to a service or a group of services presented in the indication message.

[0049] In step 340, the network determines one or more control configurations, each of which is optimized for the required service. Specifically, the control configuration includes MBMS control information corresponding to each MBSFN service group area.

[0050] In step 350, the network then broadcasts the control configuration to the UEs so that the UEs are respectively configured to receive the required services. Specifically, the UEs decode the control configuration to obtain the scheduling information of the MBMS broadcasted in the service group area, thereby obtaining the optimized control configuration of the required service on time.

[0051] The above steps can be processed periodically to keep the network updated with the latest service requirement changes of the UEs. In implementation, the scheduling of control information is delivered to the UEs according to the service requirements of the UEs, so the UEs are scheduled to receive and decode only the required messages, thereby significantly reducing power consumption. In addition, the scheduling of the MBMS control channel can use the same period or interval as that used to schedule ordinary unicast transmission (i.e., subframes, time slots), thereby simplifying the MBMS and unicast scheduling and reception process.

[0052] Figure 4 An MBSFN area 400 according to an embodiment of the present application is shown. The MBSFN area 400 includes multiple UEs 402 under the coverage of the gNB-DU 420, and provides multiple broadcast services, such as S1 (e.g., group communication service), S2 (e.g., V2X service), and S3 (e.g., IPTV service).

[0053] Traditionally, control information such as MCCH configuration and notification is uniform for all UEs regardless of their service requirements, resulting in poor support for applications with different QoS requirements on the same 5G MBMS area (e.g., mission-critical and V2X have different latency requirements for IPTV and group communication applications). The embodiments provided herein address this problem.

[0054] exist Figure 4 In the embodiment, all UEs 402 will first be reported via UCI (eg, a new type indicating field on SR or BSR indicating MBMS service type) or via MAC Control Element (CE) or via TMGI indication (eg, using UE MBMS Count Response message).

[0055] Then, the gNB-DU 420 groups the UEs 402 into different groups A1, A2, and A3 within the MBSFN area 410 according to their services or service requirements. Groups A1, A2, and A3 are also referred to as MBSFN service group areas. If each UE requires multiple services, it can belong to multiple groups and receive multiple MBMS control information corresponding to each MBSFN service group area.

[0056] like Figure 4 As shown, the gNB-DU 420 groups the two UEs 402 into the same group A1 because the two UEs 402 are interested in the same service S1, and assigns MCCH configuration S1 to group A1. Similarly, MCCH configuration S2 is assigned to group A2, and MCCH configuration S3 is assigned to group A3.

[0057] In addition, the network will adjust the configuration allocation according to the changes in UEs service requirements (ie, redefine the MBSFN service group area according to service requirements).

[0058] According to the current design of MBMS in TS-36.331 and TS36.300, when a UE with MBMS capability enters an MBSFN area and requires MBMS service, the UE first obtains SystemInformationBlockType2 (SIB2) broadcast by the MBMS cell in the MBSFN area on the Broadcast Control CHannel (BCCH). After reading the content of SIB2, the UE obtains the MBMS subframe allocation information defined by the mbsfn-SubframeConfigList information element (IE) (i.e., the radio frames reserved for MBMS transmission on the PMCH and the radio frames reserved for unicast transmission on the PDSCH). After determining the subframes allocated to MBMS, if the UE has MBMS service requirements, it obtains SystemInformationBlockType13 (SIB13).

[0059] SIB13 includes at least the following information elements (IE): MBSFN-AreaInfoList IE, which contains information fields that lead to MBMS control information associated with one or more MBSFN areas; MBSFN-AreaID, which identifies the MBSFN area; non-MBSFNregionLength, which indicates the non-MBSFN symbol area in the MBSFN subframe; NotificationIndicator, which includes a PDCCH bit for notifying the UE that the MCCH applicable to the MBSFN area has changed; and MCCH-Config, which contains the MCCH configuration.

[0060] The MCCH configuration also includes: MCCH modification period (MCCH-ModificationPeriod); MCCH repetition period (MCCH-RepetitionPeriod); main channel offset (MCCH-Offset); a bitmap (i.e., sf-AllocInfo), which indicates that one or more subframes can carry MCCH scheduling and the modulation and coding (MCS) applicable to the subframe (i.e., singnallingMCS); MCCH-ModificationPeriod, which defines the period (or boundary, i.e., the radio frame with SFN mod MCCH-ModificationPeriod = 0) during which the context of MCCH may change; and MCCH-Offset, which together with MCCH-RepetitionPeriod indicates which MCCH the radio frame is scheduling (i.e., the radio frame satisfies the equation: SFN mod MCCH-RepetitionPeriod = MCCH-Offset).

[0061] The UE obtains the message MCCH-Message containing the MBSFN area configuration from the MCCH configuration in SIB13. MBMS-NotificationConfig contains the NotificationOffset IE, which together with the NotificationRepetitionCoeffIE indicates the radio frame for scheduling the MCCH change notification (i.e., the radio frame satisfies: SFNmod NotificationRepetitionCoeff = NotificationOffset). The actual change notification repetition period of all scheduled MCCHs is equal to the shortest value of MCCH-ModificationPeriod and NotificationRepetitionCoeff. MBMS-NotificationConfig IE also contains a NotificationSF-Index IE, which indicates the subframe used to transmit the MCCH change notification on the Physical Downlink Control CHannel (PDCCH) (i.e., for FDD: values ​​1, 2, 3, 4, 5 and 6 correspond to subframes #1, #2, #3, #6, #7 and #8, respectively, and for TDD, values ​​7, 8, 9 and 10 correspond to subframes #0, #4, #5 and #9, respectively).

[0062] A shortcoming is identified from the conventional protocol: there is no indication for UEs to communicate UE service requirements to the network for adjusting or updating the MBMS area control configuration (ie, adjusting the MBSFN area control information configuration given by the MBSFN-AreaInfoList and the MCCH configuration given by the MCCH-config IE).

[0063] In one proposed embodiment, UEs send indication messages about their service requirements, for example via uplink control information (UCI) (i.e., using a special type of scheduling request (SR) and / or buffer status report (BSR)), requesting one or more required MBMS services. Another possible embodiment of the indication may be through a MAC CE, which indicates the identity of the logical channel associated with the MBMS traffic corresponding to the required service, if the network uses the same logical channel for the services associated with the MBSFN service group area.

[0064] An alternative embodiment of the indication of the UEs service requirements may also be sent to the network via an RRC MBMS Counting Response. The RRC MBMS Counting Response is sent by the UE as a response to an RRC Counting Request message sent by the network, indicating the TMGI and / or logical channel identity of the MBMS traffic type to be counted.

[0065] As an optional embodiment shown in Table 1 below, a new information element namley is proposed in the network counting request message MBMSCountingRequest, CountingRequestInfo-NR is proposed to indicate the period of the network sending counting requests to UEs, and logicalChannelIdentity-nr indicates other counting related information introduced in NR, such as the logical channel identity of the service to be counted. The counting period in n CountingRequestInfo-NRs is given by the parameter of Counting-periodicity-nr, where a period of 0.5rf represents half a radio frame or 1rf represents one radio frame (that is, half a radio frame and 1 radio frame are taken as examples without excluding other values).

[0066] Table 1: MBMSCountingRequest

[0067]

[0068] Another shortcoming is identified from the conventional protocol. The control information about MCCH control information and notification configuration provided by MBSFN-AreaInfoList IE in SystemInformationBlockType13 is provided on a per MBSFN area basis, regardless of the UEs requirements within the MBMS area, whereas in NR MBMS, different service set QoS requirements are supported. Different UEs within an MBSFN area are likely to be interested in different services.

[0069] The proposed embodiment solves this problem through grouping. UEs belonging to an MBSFN area are grouped into one or more service group areas (i.e., MBSFN sub-areas) within the MBSFN area according to their service requirements, and MCCH control information is provided according to the MBSFN service group (i.e., each MBSFN service group corresponds to a separate MCCH configuration). As an implementation method, a new IE in the system information block, namely, MBSFN-AreaInfoList-NR, is defined in the NR to carry MBMS-related control information in the NR. A new IE mbsfn-SubAreaInfoList-NR is defined in the MBSFN-AreaInfoList-NR IE to indicate the MBMS control information associated with the list of MBSFN service group areas in the MBSFN area. In addition, a new IE MBSFN-SubAreaInfo-NR is defined to indicate the MBMS control configuration of each separate MBSFN service group area, as shown in Table 2.

[0070] Table 2: MBSFN-AreaInfoList-NR

[0071]

[0072] Figure 5 The signal timing of the existing MCCH scheduling protocol is shown. In one or more radio frames 510, multiple MCCH messages 502 are transmitted within a modification period 504 with a repetition period 520. A disadvantage is thus identified. The MBSFN-AreaInfoList-NR IE only provides one possible MCCH scheduling configuration option, where the MCCH content 502 is configured to have a modification period 504 between 10ms and 1024ms, while the repetition period 520 has a configurable period from 10ms to 2560ms. Due to the different QoS requirements of services (for example, some services are delay sensitive and others are not, and some services require a higher reliability level than other services), such a configuration is not sufficient to properly schedule all types of MBMS services in 5G NR.

[0073] Figure 6The signal timing diagram of the embodiment proposed to solve the problem is shown. The MCCH configuration can be defined on a frame basis. The MCCH content 602 (i.e., the MBSFN area configuration) is modified on a frame or partial frame basis (e.g., every 5 subframes). The modified MCCH is repeated according to a bitmap indicating the subframes / time slots / mini-time slots of each frame or partial frame, which can carry the MCCH schedule. The bitmap size defining the subframes / time slots / mini-time slots carrying the MCCH schedule is given in Table 3. In the table, the number of mini-slots per frame is determined assuming normal cyclic prefix and OFDM symbol occupancy, and the mini-slots are 2, 4, and 7, respectively. In the frame-based MCCH configuration, the network can use periodic MBMS counting RCC responses or UCI reports to periodically adjust or modify the MCCH configuration. This configuration is suitable for MBMS services with moderate latency requirements, such as IPTV. For example, in a frame or a portion of a frame 610, the modification periods 604 to 608 are then aligned with the frame or a portion of the frame 610. Five MCCH contents 602 may be repeated before the next modification, each occupying one repetition period 602 .

[0074] Table 3: Bitmap size for MCCH configuration based on frame (i.e. half radio frame)

[0075]

[0076] Figure 7 A signal timing diagram based on another embodiment is shown. A subframe-based MCCH configuration is proposed. In this type of configuration, the MCCH content 702 is modified on a subframe basis, and the repetition of the modified MCCH is performed on a slot-by-slot or mini-slot by mini-slot basis based on a bitmap indicating the MBMS slots or mini-slots of each subframe that can carry the MCCH schedule.

[0077] Similarly, MBMS NR may also consider a slot-based MCCH configuration, in which the MCCH content 702 is modified on a slot-by-slot basis, and the modified content is repeated on a mini-slot-by-mini-slot basis according to a bitmap indicating the mini-slots for each slot that can carry the MCCH schedule.

[0078] The sizes of the bitmaps defining the slots / mini-slots carrying the MCCH schedule are given in Table 4. In both subframe-based and slot-based MCCH configurations, periodic UEs UCI reports can be set to the network to adjust or modify the MCCH configuration, similar to normal unicast scheduling used in NR. Both types of scheduling are suitable for delay-sensitive MBMS services, such as V2X applications. For example, within a subframe or slot 710, the modification periods 704a~704e are then aligned with the subframe or slot 710. Three MCCH contents 702 can be repeated before the next modification, each occupying one repetition period 702.

[0079] Table 4: Example of bitmap size for MCCH configuration based on subframe

[0080]

[0081]

[0082] Another embodiment proposes a non-periodic MCCH configuration. In this type of configuration, we recommend modifying the MCCH content and repeating the modified MCCH based on the non-periodic report sent by the UE indicating the change in UEs service requirements (i.e., defined by the non-periodic parameters in the MCCH-ModificationPeriod-NR IE). This configuration does not require periodic resource requests from the UE, can save the overhead of saving the control plan, and is suitable for MBMS services that do not change frequently over time.

[0083] For instructions Figure 6 and Figure 7In order to configure the MCCH in accordance with the MCCH configuration options, a new IE, namely MCCH-Config-nr, is defined in the MBSFN-SubAreaInfo-NR IE for each MBSFN service group area indicated by mbsfn-SubAreaId-nr to indicate the MCCH configuration associated with that specific MBSFN service group area. In the MCCH-Config-nr, an IE MCCH-ModificationPeriod-NR is defined to indicate the MCCH modification period used. In the MCCH-ModificationPeriod-NR, the parameters indicate that the MCCH modification occurs on a frame-basis basis, and the values ​​indicate that the MCCH modification occurs in each radio frame on a subframe-basis basis. In addition, the MCCH repetition period is defined using the MCCH-RepetitionPeriod-NR IE, which contains parameters such as MCCH-RepetitionFrame, MCCH-RepetitionSubfrmae, and MCCH-RepetitionSlot, which define the repetition periods of the MCCH configuration based on frames, subframes, and time slots, respectively. The IE MCCH-AllocInfo-NR is defined to indicate the subframes (i.e. defined by AllocInfoFrame) or time slots (i.e. defined by AllocInfoSubFrame) or mini-time slots (i.e. defined by AllocInfoSlot) that can carry MCCH scheduling information. The length or size of the bitmap used to determine the subframes, time slots or mini-time slots that can carry MCCH scheduling is given by the parameters AllocPerFrameNRBitmap, AllocPerSubframeNRBitmap and AllocPerSlotNRBitmap for frame-based, subframe-based and time slot-based MCCH configuration, respectively. Further, a new IE, namely notificationIndicator-NR IE, is defined for each service group in the MBSFN area indicated by mbsfn-SubAreaId-nr to indicate which PDCCH bit is used to notify the UE of changes in the MCCH applicable to the MBSFN service group area.

[0084] Table 5: MBSFN-AreaInfoList-NR

[0085]

[0086]

[0087] Typically, the same MBMS notification configuration applies to all MBSFN areas, and MCCH changes on the PDCCH are indicated using the index of the subframe within the radio frame that may carry the MCCH change, assuming that only radio frame-based configuration is used in LTE. In NR, due to differences in UE requirements and the services broadcast by each MBSFN service group area, each MBSFN area may have a different notification configuration, or even each individual MBSFN service group area within an MBSFN area may have a different configuration from other areas.

[0088] An embodiment is proposed to provide MBMS notification configuration and MCCH change notification on PDCCH on a per MBSFN service group area basis. In this way, each individual MBSFN service group area within an MBSFN area can be configured with different notification configurations and different MCCH change notifications based on the MCCH configuration used for the MBMS services broadcast by the MBSFN service group area. To achieve this, we propose to define a new information element for MBMS notification in NR, namely MBMS-NotificationConfig-NR, which is defined in the system information block to carry MBMS notification information in NR. In the MBMS-NotificationConfig-NR IE, we further propose to define SubAreaNotifiConfiglist-NRIE for indicating MBMS notification information associated with a list of MBSFN service group areas associated with the MBSFN area. In addition, we also propose to define SubAreaNotifiConfig-NR IE for indicating the MBMS notification configuration of each individual MBSFN service group area. Additionally, we recommend indicating MCCH change notifications on PDCCH based on the type of MCCH configuration used (i.e., frame-based, subframe-based, and slot-based configurations); therefore, we recommend using notification-Index-NR to indicate the notification index used for MCCH change, where notification-Index-NR indicates the index of a subframe or slot or mini-slot.

[0089] Table 6: MBMS-NotificationConfig-NR

[0090]

[0091] This embodiment introduces a new mechanism for scheduling control information of multicast / broadcast areas in a 5G NR MBMS system, which has the following inventions on the existing MBMS design.

[0092] This embodiment provides scheduling of control information for UEs based on the service requirements of the UEs, which is one of the design goals of NR MBMS. Several impacts can be identified. The MBMS regional control information in this embodiment is periodically adjusted as user needs change. The scheduling in the MBMS control channel uses the same period or interval (i.e., subframe, time slot) as the unicast scheduling. This unified scheduling simplifies the reception process on the UE side, i.e., UEs can receive MBMS and unicast by monitoring only one scheduling period. This embodiment enables UEs to receive only the control configuration for the requested service, thereby reducing processing power. This embodiment is conducive to providing a variety of support options, including subframe, time slot and mini-time slot scheduling, which can be selected based on UE service requirements.

[0093] The main advantage of grouping is that it allows UEs to monitor only the control information or MCCH configuration for the services they are interested in receiving, which helps to reduce the UE processing power. According to the current design of MBMS in standards TS 36.331 clause 5.8.2, TS36.331-5.8.1.3 and TS-36.300-15.3.6, UEs must obtain / monitor the MCCH configuration of all services provided by the MBSFN area to ensure that it will monitor the MCCH configuration of the services it is interested in. The described embodiments enable the UE to monitor only the control information configuration (MCCH configuration) associated with the association group or the services it is interested in receiving (i.e., it does not need to know which MCCHs the RAN has configured to carry the services of interest). In other words, the NG-RAN only configures the MCCHs associated with the services they are interested in for UEs, and the UEs will only monitor these configured MCCHs, resulting in a reasonable reduction in processing power on the UE side.

[0094] Figure 8A schematic diagram of a UE 800 according to an embodiment of the present invention is shown. The UE 800 generally includes a transceiver 802, a display 804, a memory 806, a processor 808, and a Subscriber Identity Module (SIM) card 810. The transceiver 802 is also called a combination of a transmitter and a receiver, and functions for both signal transmission and reception, because the hardware structure of the transmitter and the receiver can be shared and integrated into one module. The embodiment of dynamic MBMS control is basically a software implementation, which is manifested as software or firmware stored in the memory 806 and executed by the processor 808. Therefore, the hardware structure of the UE 800 is not specifically limited, and can be a phone, a tablet, a computer, a video streaming device, a set-top box, or any communication device that supports subscribers. The embodiment of the UE 800 is described by the following summarized behavior, each UE in the MBSFN service area sends an indication message to the network via UCI, MAC CE and / or RRC. The indication message contains service requirement information for the required service respectively. The service requirement can specifically be the service type and / or QoS information of the required service. The indication message serves as the basis for the network to dynamically adjust the MCCH configuration.

[0095] As described above, the network grouped multiple UEs 800 into one or more groups based on service requirements and generated a control configuration for each group. Therefore, through broadcast, the UEs 800 in each group only receive a subset of the total control configuration associated with its group. Each UE 800 monitors and decodes the control configuration associated with the service broadcasted from the corresponding group so that they can receive the relevant MBMS service.

[0096] In summary, an embodiment of UE 800 can be connected to an MBSFN service area and receive MBMS services dynamically controlled by a network node. A transceiver 802 in the UE acts as a transmitter to send an indication message to a network node so that the network determines at least one control configuration based on one or more desired MBMS services. The transceiver 802 then acts as a receiver to receive at least one control configuration.

[0097] based on Figure 1 , an embodiment of a telecommunication system 100 implementing the described method for dynamic MBMS control can be summarized as follows. The known telecommunication system 100 can be operated in an MBSFN service area to provide an MBMS service with dynamic MBMS control, which includes at least one network node and a plurality of UEs. In this embodiment, the UEs ( Figure 1The network node (i.e., gNB-DU 130 or gNB-CU 120) receives the indication messages from the UEs, determines at least one control configuration based on the desired one or more MBMS services, and transmits the at least one control configuration to the UEs.

[0098] All relevant steps of the UE and telecommunication system processing have been described in the above-mentioned MBMS dynamic control method embodiments and Figures 2 to 7 The description is omitted here.

[0099] Although the present invention has been described by way of example and according to preferred embodiments, it should be understood that the present invention is not limited thereto. On the contrary, it is intended to cover various modifications and similar arrangements (as will be apparent to those skilled in the art). Therefore, the scope of the appended claims should be given the broadest interpretation to cover all such modifications and similar arrangements.

Claims

1. A dynamic MBMS control method, used by a network node in an MBSFN service area to provide MBMS services to one or more user equipments, comprising: Receiving a plurality of indication messages from one or more user equipments via uplink control information UCI; wherein each indication message comprises a service requirement for one or more MBMS services, wherein the indication message comprises a special type scheduling request SR or a buffer status report BSR indicating an MBMS service type and / or service QoS information; determining at least one control configuration based on the desired one or more MBMS services; and The at least one control configuration is transmitted to the user equipment.

2. The dynamic MBMS control method according to claim 1, further comprising: After receiving the multiple indication messages, group the user equipment into one or more groups according to the required service type or QoS information of the required service in the indication messages, so that user equipment requiring the same service has the same QoS requirement and is grouped into the same group; The determining step includes determining one or more control configurations, each control configuration corresponding to a group; The sending step includes sending the control configuration to user equipment in each group respectively.

3. The dynamic MBMS control method according to claim 2, wherein the control configuration comprises at least one of the following parameters: multicast control channel (MCCH) configuration, MBMS area control information or scheduling configuration. 4 . The dynamic MBMS control method according to claim 3 , wherein the MBMS area control information includes scheduling information of MBMS control channels corresponding to each group.

5. The dynamic MBMS control method according to claim 4, further comprising: The determining and transmitting steps are repeated based on the scheduling information or upon receiving a service requirement change from the user equipment.

6. The dynamic MBMS control method according to claim 1, wherein the service requirements include at least one of the following parameters required for the corresponding service: a group of sessions, a temporary mobile group identity (TMGI), a quality of service (QOS) together with the session or TMGI, a delay parameter including a maximum allowed packet or frame or bit error rate, and / or a reliability parameter.

7. The dynamic MBMS control method according to claim 1, wherein the receiving step comprises receiving the indication message via a medium access control element (MAC CE); wherein the indication message comprises a service indication in a MAC logical channel.

8. The dynamic MBMS control method according to claim 1, wherein the indication message comprises at least one of the following messages: an MBMS counting response RRC message, a temporary mobile group identity (TMGI) indication, or a session identity indication.

9. The dynamic MBMS control method according to claim 3, wherein the MBMS area control information is grouped to reduce user equipment processing power.

10. A user equipment, connectable to an MBSFN service area, receiving MBMS services dynamically controlled by a network node, comprising A transmitter sends an indication message to the network node; wherein: The indication message includes a service requirement for one or more MBMS services; and The network determines at least one control configuration based on one or more desired MBMS services; and a receiver, receiving the at least one control configuration to the user equipment, The user equipment sends an indication message via uplink control information UCI; The indication message includes a special type scheduling request SR or a buffer status report BSR indicating the MBMS service type and / or service QoS information.

11. The user equipment according to claim 10, wherein the user equipment receives a control configuration corresponding to a group of user equipments requiring the same service or QoS requirement.

12. The user equipment according to claim 11, wherein the control configuration comprises at least one of the following parameters: multicast control channel (MCCH) configuration, MBMS area control information or scheduling configuration.

13. The user equipment according to claim 12, wherein the MBMS area control information comprises scheduling information of the MBMS control channel corresponding to the group.

14. The user equipment of claim 13, wherein the user equipment repeats the transmission of the network node when service requirements change.

15. The user equipment according to claim 10, wherein the service requirements include at least one of the following parameters required for the corresponding service: a group of sessions, a temporary mobile group identity (TMGI), a quality of service (QOS) together with the session or TMGI, a delay parameter including a maximum allowed packet or frame or bit error rate, and / or a reliability parameter.

16. The user equipment according to claim 10, wherein the user equipment sends the indication message through a medium access control element (MACCE); and the indication message includes a service indication in a MAC logical channel.

17. The user equipment according to claim 10, wherein the indication message comprises at least one of the following messages: an MBMS counting response RRC message, a temporary mobile group identity (TMGI) indication, or a session identity indication.

18. The user equipment of claim 11, wherein processing power of the user equipment is reduced because only information corresponding to the group needs to be received.

19. A telecommunications system operable in an MBSFN service area to provide an MBMS service with dynamic MBMS control, comprising: A plurality of user equipments transmit a plurality of indication messages, each indication message including a service requirement for one or more MBMS services; as well as a network node, receiving an indication message from the user equipment, determining at least one control configuration based on one or more required MBMS services, and transmitting the at least one control configuration to the user equipment, The user equipment receives the indication message via uplink control information UCI; each of the indication messages includes a special type scheduling request SR or a buffer status report BSR indicating an MBMS service type and / or service QoS information.

20. The telecommunications system of claim 19, wherein: After receiving the multiple indication messages, the network node divides the user equipment into one or more groups according to the required service type or QoS information of the required service in the indication message, so that the user equipment requiring the same service has the same QoS requirement and is divided into the same group; The network node determines one or more control configurations, each control configuration corresponding to a group; The network node transmits the control configuration to the user equipment in each group respectively.

21. The telecommunications system of claim 20, wherein the control configuration comprises at least one of the following parameters: multicast control channel (MCCH) configuration, MBMS zone control information or scheduling configuration.

22. The telecommunication system of claim 21, wherein the MBMS area control information comprises scheduling information for each group of corresponding MBMS control channels.

23. The telecommunications system of claim 22, wherein the network node repeats the user equipment packet and control configuration transmission based on the scheduling information or upon receiving a service requirement change from the user equipment.

24. The telecommunication system of claim 19, wherein the service requirements comprise at least one of the following parameters required for the respective service: a group of sessions, a temporary mobile group identity (TMGI), a quality of service (QOS) together with the session or TMGI, a delay parameter including a maximum allowed packet or frame or bit error rate, and / or a reliability parameter.

25. The telecommunications system of claim 19, wherein the user equipment receives the indication message via a medium access control element (MAC CE); and the indication message comprises a service indication in a MAC logical channel.

26. The telecommunications system of claim 19, wherein the indication message comprises at least one of the following messages: an MBMS Counting Response RRC message, a Temporary Mobile Group Identity (TMGI) indication, or a Session Identity indication.

27. The telecommunications system of claim 20, wherein processing power of the user equipment is reduced because only information corresponding to the group needs to be received.

Images