Frequency domain resource allocation for multicast services

Abstract

Embodiments of this disclosure relate to frequency domain resource allocation for multicast services. One method includes: receiving, at a first device, a multicast service to be scheduled for a second device from a core network element; generating auxiliary information for the second device, the auxiliary information enabling the second device to identify frequency domain resources allocated for the multicast service within a bandwidth portion configured for the second device; and sending the auxiliary information to the second device. The method further includes: receiving the auxiliary information from the first device at the second device; and determining the frequency domain resources from downlink control information based on the auxiliary information. In this manner, significant flexibility in scheduling multicast services can be provided, and significant reduction in complexity can be offered to terminal devices.

Description

Technical Field

[0001] Embodiments of this disclosure generally relate to the telecommunications field, and more specifically to communication methods, apparatus, and computer-readable storage media for optimizing frequency domain resource allocation for multicast services. Background Technology

[0002] With the development of New Radio (NR) multicast technology, the 3rd Generation Partnership Project (3GPP) is currently defining mechanisms to support the delivery of multicast and / or broadcast services to multiple terminal devices. A key objective is to define a group scheduling mechanism that enables the scheduling of multicast and / or broadcast services using common data channel resources, while maintaining maximum commonality with the currently defined unicast scheduling and operation mechanisms.

[0003] Currently, enhancements to this group scheduling mechanism are primarily related to downlink data service scheduling and related radio resource optimization. Various solutions and reliability improvement techniques also exist. However, attention to control channel enhancements has been limited, particularly in signaling. Specifically, control signaling enhancements targeting frequency domain resource allocation information for a group of users have not been previously considered; this information can be interpreted differently by individual users or terminal devices within the group based on their unique bandwidth configurations. Summary of the Invention

[0004] Overall, the exemplary embodiments of this disclosure provide a solution for optimizing frequency domain resource allocation for multicast services.

[0005] In a first aspect, a first device is provided. The first 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 together with the at least one processor to cause the first device to: receive multicast services to be scheduled for a second device from core network elements; generate auxiliary information for the second device, the auxiliary information enabling the second device to identify frequency domain resources allocated for the multicast services within a bandwidth portion configured for the second device; and transmit the auxiliary information to the second device.

[0006] In a second aspect, a second device is provided. The second 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, together with the at least one processor, to enable the second device to: receive auxiliary information from a first device, the auxiliary information enabling the second device to identify frequency domain resources allocated for multicast services within a bandwidth portion configured for the second device; and determine frequency domain resources from downlink control information based on the auxiliary information, the downlink control information being received from the first device and including a field indicating the frequency domain source.

[0007] In a third aspect, a communication method is provided. The method includes: receiving, at a first device, a multicast service to be scheduled for a second device from a core network element; generating auxiliary information for the second device, the auxiliary information enabling the second device to identify frequency domain resources allocated for the multicast service within a bandwidth portion configured for the second device; and sending the auxiliary information to the second device.

[0008] In a fourth aspect, a communication method is provided. The method includes: receiving auxiliary information from a first device at a second device, the auxiliary information enabling the second device to identify frequency domain resources allocated for a multicast service within a bandwidth portion configured for the second device; and determining the frequency domain resources from downlink control information based on the auxiliary information, the downlink control information being received from the first device and including a field indicating the frequency domain resources.

[0009] In a fifth aspect, a communication apparatus is provided. The apparatus includes: components for receiving, at a first device, a multicast service to be scheduled for a second device from a core network element; components for generating auxiliary information for the second device, the auxiliary information enabling the second device to identify frequency domain resources allocated for the multicast service within a bandwidth portion configured for the second device; and components for transmitting the auxiliary information to the second device.

[0010] In a sixth aspect, a communication apparatus is provided. The apparatus includes: components for receiving auxiliary information from a first device at a second device, the auxiliary information enabling the second device to identify frequency domain resources allocated for multicast services within a bandwidth portion configured for the second device; and components for determining frequency domain resources from downlink control information based on the auxiliary information, the downlink control information being received from the first device and including a field indicating the frequency domain resources.

[0011] In a seventh aspect, a non-transitory computer-readable medium is provided. This non-transitory computer-readable medium includes program instructions for causing a device to execute the method according to the third aspect.

[0012] In an eighth aspect, a non-transitory computer-readable medium is provided. This non-transitory computer-readable medium includes program instructions for causing a device to execute the method according to the fourth aspect.

[0013] It should be understood that the summary portion is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0014] Some exemplary embodiments will now be described with reference to the accompanying drawings, in which:

[0015] Figure 1 An example communication network in which example embodiments of this disclosure may be implemented is shown;

[0016] Figure 2 A diagram showing an example bandwidth portion (BWP) configuration is provided;

[0017] Figure 3 A diagram illustrating a control signaling scenario considered for NR multicast is shown;

[0018] Figure 4 A diagram is shown illustrating a straight-forward BWP configuration for scheduling multicast services according to a conventional solution;

[0019] Figure 5A A diagram illustrating a flexible BWP configuration for scheduling multicast services, based on a conventional solution;

[0020] Figure 5B A diagram is shown illustrating another flexible BWP configuration for scheduling multicast services, based on a conventional solution.

[0021] Figure 6 A flowchart illustrating a communication process according to some embodiments of the present disclosure is shown;

[0022] Figure 7A A diagram illustrating an example determination of frequency domain resources for a multicast service of resource allocation (RA) type 0 according to some embodiments of the present disclosure is shown;

[0023] Figure 7B A diagram showing another example of frequency domain resources determined for a multicast service of resource allocation (RA) type 0 according to some embodiments of this disclosure is illustrated;

[0024] Figure 8A A diagram illustrating an example determination of frequency domain resources for a multicast service of RA type 1 according to some embodiments of the present disclosure is shown;

[0025] Figure 8B A diagram illustrating an example determination of frequency domain resources for a multicast service of RA type 1 according to some embodiments of the present disclosure is shown;

[0026] Figure 9 A flowchart illustrating a communication method implemented at a first device according to an exemplary embodiment of the present disclosure is shown;

[0027] Figure 10 A flowchart illustrating a communication method implemented at a second device according to an exemplary embodiment of the present disclosure is shown;

[0028] Figure 11 A flowchart illustrating a method for determining frequency domain resources for a multicast service according to an example embodiment of the present disclosure is shown;

[0029] Figure 12 A simplified block diagram of an apparatus suitable for implementing exemplary embodiments of the present disclosure is shown; and

[0030] Figure 13 A block diagram of an example computer-readable medium according to an example embodiment of the present disclosure is shown.

[0031] Throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements. Detailed Implementation

[0032] The principles of this disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are described merely for illustration and to help those skilled in the art understand and implement this disclosure, and do not imply any limitation on the scope of this disclosure. The disclosure described herein can be implemented in various other ways besides those described below.

[0033] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0034] In this disclosure, references to "an embodiment," "embodiment," and "example embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment must include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with an embodiment, those skilled in the art will understand that, whether explicitly described or not, combining it with other embodiments to affect such a feature, structure, or characteristic is within the knowledge of those skilled in the art.

[0035] It should be understood that although the terms “first” and “second”, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the exemplary embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0036] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. The singular forms “a,” “an,” and “the” used herein also include the plural forms unless the context clearly indicates otherwise. Further understanding is that the terms “comprises,” “comprising,” “has,” “having,” “includes,” and / or “including”, when used herein, specify the presence of the stated features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

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

[0038] (a) Pure hardware circuit implementation (such as implementation using only analog and / or digital circuit systems), and

[0039] (b) A combination of hardware circuitry and software, such as (if applicable):

[0040] (i) A combination of (multiple) analog and / or digital hardware circuits and software / firmware, and

[0041] (ii) Any part of a hardware processor(s) having software, including (multiple) digital signal processors(s), software, and (multiple) memories(s), working together to enable a device (such as a mobile phone or server) to perform various functions, and

[0042] (c) (Multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or a portion thereof, which require software (e.g., firmware) to operate, but may be absent when operation is not required.

[0043] The definition of "circuit system" applies to all uses of the term in this application, including in any claim. As another example, as used in this application, the term "circuit system" also covers only hardware circuitry or a processor (or processors) or a portion of hardware circuitry or a processor and its accompanying software and / or firmware. For example, if applicable to a particular claim element, the term "circuit system" also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0044] As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as fifth-generation (5G) systems, Long Term Evolution (LTE), LTE-A Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. Furthermore, communication between terminal devices and network devices in a communication network can be performed according to any suitable generation of communication protocol, including but not limited to first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, fifth-generation (5G) New Radio (NR) communication protocols, and / or any other currently known or to be developed in the future. Embodiments of this disclosure can be applied to various communication systems. Given the rapid development of communications, there will naturally be future types of communication technologies and systems that can embody this disclosure. The scope of this disclosure should not be limited to the systems described above.

[0045] As used herein, the term "network device" refers to a node in a communication network through which terminal devices access the network and receive services. A network device can refer to a base station (BS) or access point (AP), such as a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), an NR NB (also known as a gNB), a Remote Radio Unit (RRU), a Radio Header Terminal (RH), a Remote Radio Header Terminal (RRH), a relay, a low-power node (such as a femtosecond, picosecond), etc., depending on the terminology and technology applied. The RAN split architecture includes a gNB-CU (centralized unit, which hosts RRC, SDAP, and PDCP) that controls multiple gNB-DUs (distributed units, which host RLC, MAC, and PHY). A relay node may correspond to the DU portion of an IAB node.

[0046] The term "terminal device" 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). Terminal devices can include, but are not limited to, mobile phones, cellular phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices (such as digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEE), laptop in-vehicle devices (LME), USB dongles, smart devices, wireless customer premises equipment (CPE), Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Terminal equipment can also correspond to the mobile terminal (MT) portion of an integrated access and backhaul (IAB) node (also known as a relay node). In the following description, the terms "terminal equipment," "communication equipment," "terminal," "user equipment," and "UE" are used interchangeably.

[0047] As used herein, the term "multicast service" refers to a service delivered to a group of users interested in receiving the service, and also to data transmitted over the air and received by all users interested in receiving the service. In other words, the term "multicast service" as used herein can also cover multicast and broadcast services. In the following description, the terms "multicast service," "multicast service," "broadcast service," "broadcast service," and "multicast / broadcast service (MBS)" are used interchangeably.

[0048] In 4G, group scheduling mechanisms are implemented using semi-static or dynamic broadcast signaling of control information. This control information directs to semi-static and dynamic shared data channel resources used for Evolved Multicast Multimedia Service (eMBMS) and Single Cell Point-to-Multipoint (SC-PTM). For eMBMS and SC-PTM, the support for receive-only mode terminal devices imposes many constraints on system design, such as supporting devices not registered with the network and supporting idle mode devices. This has a significant impact on how to use physical channels (using the Physical Downlink Shared Channel (PDSCH) or Physical Multicast Channel (PMCH)) to send multicast data / service channel (MTCH) and multicast control channel (MCCH) information.

[0049] Here, the main focus of 5G NR is on RRC-Connected mode terminal devices, which differ significantly from previous generations and implements unique enhancements that help optimize the delivery of multicast and / or broadcast services. Multicast services refer to services delivered to a group of users interested in receiving them, while broadcast services refer to data transmitted over the air and received by all users interested in receiving them. The enhancements currently under discussion primarily relate to downlink data service scheduling and related radio resource optimization. Various suggestions also relate to reliability improvement techniques. However, attention to control channel enhancements is limited, particularly in signaling. While some methods can be described with reference to connected mode terminal devices in this paper, it should be understood that such methods can be similarly applied to other modes of terminal devices.

[0050] To date, in the context of shared data channel resources, considerations in 5G suggest using the currently defined BWP concept, where the terminal device is configured with a set of resources within the system bandwidth in which network devices will schedule multicast PDSCH resources, or utilize a specific bandwidth portion of the multicast broadcast service (MBS). In this case, it is anticipated that the Frequency Domain Resource Allocation (FDRA) field within the downlink control information (DCI) will require enhancement.

[0051] In view of this, embodiments of the present disclosure provide a solution for such enhancement. In this solution, auxiliary information is signaled from a first device providing the multicast service to a second device receiving the multicast service, enabling the second device to identify the group common frequency resource configured for the multicast service from the group common PDCCH message, whereby the BWP configuration is specific to the second device. In this way, significant flexibility in scheduling multicast services can be provided, and unicast and multicast services of terminal devices can be scheduled within the same time slot. Furthermore, significant complexity reduction can be provided for terminal devices. The principles and implementations of the present disclosure will now be described in detail with reference to the accompanying drawings. Although multicast services are referred to herein, it should be understood that multicast services can represent broadcast services, and the same principles and implementations can also be applied to broadcast services.

[0052] Figure 1 An example communication network 100 in which embodiments of the present disclosure may be implemented is shown. Figure 1 As shown, network 100 includes a first device 110 and a second device 120 served by the first device 110. Network 100 also includes a core network 130, and the core network 130 includes core network elements 131. It should be understood that, as Figure 1The number of first and second devices and the number of core network elements shown are for illustrative purposes only and are not limiting. Network 100 may include any suitable number of first and second devices and core network elements suitable for implementing embodiments of this disclosure. In some embodiments, first device 110 may be a network device and second device 120 may be a terminal device. In some embodiments, core network element 131 may be a server providing multicast services.

[0053] For illustrative purposes only, some embodiments will be described in the context that the first device 110 is a network device and the second device 120 is a terminal device, without imposing any limitation on the scope of this disclosure. It should be understood that in other embodiments, the first device 110 may be a terminal device and the second device 120 may be a network device. In other words, the principles and spirit of this disclosure can be applied to both uplink and downlink transmissions.

[0054] like Figure 1 As shown, the first device 110 and the second device 120 can communicate with each other, and the second device 120 can communicate with the core network element 131 via the first device 110. Communication within network 100 can conform to any suitable standard, including but not limited to LTE, LTE Evolution, LTE-A Advanced, Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), and Global System for Mobile Communications (GSM). Furthermore, communication can be performed according to any generation of communication protocols currently known or to be developed in the future. Examples of communication protocols include, but are not limited to, first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, and fifth-generation (5G) communication protocols.

[0055] In some scenarios, the first device 110 can receive multicast services scheduled for multiple second devices from core network element 131. For convenience, the following description uses the second device 120 as an example. The first device 110 can schedule frequency domain resources for multicast services and indicate the frequency domain resources to the second device 120. Therefore, the second device 120 can receive multicast services from the frequency domain resources. In some embodiments, the first device 110 can determine the frequency domain resources from a set of frequency resources (also referred to herein as common frequency resources) used for scheduling multicast services.

[0056] In some embodiments, the first device 110 may configure a BWP configuration for the second device 120. Typically, four BWPs may be configured in the uplink and downlink, each BWP indicating a set of frequency resources within the carrier bandwidth. Each BWP shares commonalities in the parameter configuration (numerology) used and a set of contiguous physical resource blocks (PRBs). In some embodiments, the second device 120 may have only one active BWP, where BWP-0 is considered the initial BWP. In some embodiments, the second device 120 may also be configured with a default BWP, which the second device 120 reverts to after the active BWP has been inactive for a specified period.

[0057] Figure 2 Figure 200 shows an example BWP configuration. Figure 2 In the example, three different terminal devices, UE-1, UE-2, and UE-3, are considered, and each terminal device is configured with four BWPs, namely BWP-0, BWP-1, BWP-2, and BWP-3. Figure 2 Each box in the diagram can be considered a PRB. Here, terminal device 120 can switch between different BWPs based on the service requirements scheduled for each individual terminal device, the overall cell load, and various other factors. BWP configurations, such as location in frequency / carrier bandwidth, subcarrier spacing, and inactivity timers, can be configured using higher-level signaling such as Radio Resource Control (RRC) signaling.

[0058] In some embodiments, the second device 120 may be required to switch the BWP based on at least one of the following configurations:

[0059] • Through PDCCH (i.e., Downlink Control Information (DCI)) signaling from the first device 110: a specific BWP can communicate via DCI format 0_1 ​​(UL authorized).

[0060] Activate with the bandwidth section indicator in DCI format 1_1 (DL schedule).

[0061] • By using bwp-InactivityTimer:ServingCellConfig.bwp-InactivityTimer configured by the first device 110.

[0062] • Through RRC signaling from the first device 110.

[0063] • When the second device 120 initiates a random access procedure, it does so through the MAC entity itself.

[0064] In some embodiments, the first device 110 may use a DCI (format 1_0 or 1_1) to schedule PDSCH resources. A key field within the DCI used for this purpose is the Frequency Domain Resource Allocation (FDRA) field, such as... Figure 3 As shown in 310 or 320, it notifies the second device 120 of the PDSCH PRB within certain time slots and includes information related to the second device 120. This information corresponds to resources within the active BWP of the second device 120.

[0065] In some embodiments, the first device 110 may also use DCI format 1_1 to request the second device 120 to switch the active BWP to another BWP in which resources are scheduled for the second device 120. As mentioned above, there are various other BWP switching methods that the first device 110 can use to switch the active BWP of the second device 120 to an appropriate BWP, for example, when an MBS PRB will be scheduled.

[0066] In some embodiments, the first device 110 may use a Group Radio Network Temporary Identity (G-RNTI) to deliver DCIs for multiple second devices to receive the same multicast service, the G-RNTI being configured using higher-layer signaling such as RRC signaling.

[0067] Because 5G systems offer tremendous flexibility, there are multiple options for using PDCCH to transmit control signaling for public frequency resources / MBS PDSCH, such as... Figure 3 As shown. Figure 3 Figure 300 illustrates a control signaling scenario considered for NR multicast. This can be accomplished using UE-specific signaling for PDCCH / DCI, which uses an existing format for downlink scheduling. If this option is used, no issues related to BWP and associated FDRA will arise.

[0068] However, as Figure 3 As shown, when using G-RNTI scrambled DCI (possibly using a modified format 1_x) for group common PDCCH signaling to schedule common frequency resources / MBS PDSCH, there are issues related to both BWP and FDRA configurations. This will combine... Figure 4 and Figures 5A to 5B Detailed explanation.

[0069] Figure 4 Figure 400 illustrates a direct BWP configuration for scheduling multicast services according to a conventional solution. Figure 4As shown, it is assumed that all terminal devices UE-1, UE-2, and UE-3 receiving multicast services are configured with the same BWP. These BWPs are dedicated to MBS services and have identical BWP IDs, as shown in Figure 410. In this case, as long as all terminal devices are able to switch to BWP-3 at the appropriate time when the MBS PDSCH is scheduled, there will be no problem with the BWP and FDRA configuration within the DCI.

[0070] However, considering the consensus within 3GPP regarding the simultaneous scheduling of unicast and multicast services within the same time slot, this solution is impractical. A direct solution would impose significant constraints on scheduling at network devices, and a symmetric BWP configuration is impractical due to its dependence on unrelated unicast services received by end devices. Configuring the same BWP ID for each end device, in addition to designing identical BWPs, introduces further limitations. Given that end devices can join and leave multicast groups at any time, such a solution involves significant complexity in configuring and reconfiguring MBS BWPs for multiple end devices using higher-level signaling such as RRC signaling. Another important factor to consider is that end devices can receive multiple multicast traffic streams, each potentially on different public MBS frequency resources (possibly configured on different BWPs). All these limitations render a direct solution impractical.

[0071] In some other traditional solutions, in order to schedule services in the most efficient way, it is necessary to consider the maximum flexibility of network devices in terms of UE-specific / dedicated BWP configuration. Figure 5A Figure 500A illustrates a flexible BWP configuration for scheduling multicast services according to a conventional solution. This example considers scenarios where MBS services are scheduled using shared resources within the same BWP ID, and where different groups of terminal devices are receiving different MBS services. Figure 5A As shown in Figure 510, terminal devices UE-1, UE-2, and UE-3 can be configured with the same MBS BWP (BWP-3) for the MBS service corresponding to G-RNTI#1. Terminal devices UE-2 and UE-3 can be configured with the same MBS BWP (BWP-2) for another MBS service corresponding to G-RNTI#2.

[0072] Figure 5B Figure 500B illustrates another flexible BWP configuration for scheduling multicast services, based on a conventional solution. This example considers scenarios where MBS services are scheduled using shared resources within the same or different BWP IDs, and where different groups of terminal devices are receiving different MBS services. Figure 5BAs shown, terminal devices UE-1, UE-2, and UE-3 can be configured with different MBS BWPs (BWP-2 for UE-1 and BWP-3 for UE-2 and UE-3) for the MBS service corresponding to G-RNTI#1, as shown in Figure 530. Terminal devices UE-2 and UE-3 can be configured with the same MBS BWP (BWP-2) for another MBS service corresponding to G-RNTI#2, as shown in Figure 540.

[0073] However, it remains necessary to investigate how to signal this information most efficiently, particularly information relating to public frequency resources used for multicast service delivery, so that terminal devices can receive multicast services they are interested in receiving. Here, it is assumed that the control resource set (CORESET) in which the PDCCH is scheduled is within the MBS BWP, and therefore within public frequency resources. Here, MBS BWP represents (a) the public frequency resources in which a particular multicast or broadcast service is scheduled; or (b) the bandwidth portion in which all multicast or broadcast services are scheduled for the terminal device. The main difference between options (a) and (b) is that the PDCCH resources used for scheduling multicast or broadcast services are located in a common location or are confined to public frequency resources for each individual multicast or broadcast service.

[0074] In view of the above, embodiments of this disclosure provide a mechanism for signaling auxiliary information (also referred to herein as additional parameters) from a first device 110 providing multicast services to a second device 120 receiving multicast services. This auxiliary information is used by the second device 120 to identify group common frequency resources / MBS PDSCH resources configured for scheduling multicast services from group common PDCCH messages, and the bandwidth configuration may be specific to the second device 120. This mechanism of this disclosure is illustrated with a high-level flowchart, such as... Figure 6 As shown.

[0075] Figure 6 A flowchart illustrating a communication process 600 according to some embodiments of the present disclosure is shown. For convenience, it will be combined with... Figure 1 Examples to describe Figure 6 .

[0076] like Figure 6 As shown, the first device 110 receives 610 multicast services to be scheduled for the second device 120 from core network element 131. After receiving the multicast services, the first device 110 generates 620 auxiliary information. The auxiliary information enables the second device 120 to identify the frequency domain resources allocated for the multicast services within the BWP configured for the second device 120.

[0077] In some embodiments, the auxiliary information may include the identifier (also referred to herein as BWP ID) of the BWP in which the frequency domain resources are scheduled. In some embodiments, the BWP may be the currently active BWP of the second device 120. In some embodiments, the BWP may be another BWP different from the active BWP. In this case, the second device 120 may switch from the active BWP to another BWP.

[0078] In some embodiments, the auxiliary information may include an offset (also referred to herein as Frequency Resource Offset (FRO)) indicating the starting position of a frequency domain resource within a BWP. In some embodiments, the auxiliary information may include parameters (also referred herein as BWP Size Adaptation Parameter (BWP)) for adapting the size of a BWP for multicast services relative to the size of a BWP configured for the second device 120. SA In some embodiments, FRO and BWP SA This can be an optional parameter for signaling to the second device 120, depending on the resource allocation (RA) type (type 0 or type 1) configured for the multicast service or the second device 120.

[0079] It should be understood that these are merely examples of auxiliary information, which may include other suitable information that enables the second device 120 to identify frequency domain resources allocated for multicast services within the BWP configured for the second device 120.

[0080] With the auxiliary information, by combining the optimal aspect of the BWP size dedicated to the second device 120 with the common frequency resources for multicast services, significant flexibility can be provided for scheduling MBS PDSCH for the first device 110. Furthermore, by implementing a flexible BWP configuration dedicated to the second device 120, the first device 110 can schedule unicast and multicast services of the second device 120 within the same time slot.

[0081] In some embodiments, auxiliary information can be associated with an identifier related to a multicast service. For example, the identifier could be a common group identifier such as the G-RNTI of the multicast service. In this case, a one-to-one mapping can exist between the G-RNTI and the auxiliary information. In other words, auxiliary information can be configured per multicast service and can be limited to individual multicast services in terms of its effectiveness. In this way, different auxiliary information can be provided for different multicast services, and the scheduling of frequency domain resources for multicast services can be implemented in a more flexible manner.

[0082] After generating the auxiliary information, the first device 110 sends the auxiliary information 630 to the second device 120. In some embodiments, the auxiliary information may be sent together with the G-RNTI configuration. In some embodiments, the first device 110 may send the auxiliary information via higher-level signaling such as RRC signaling. It should be understood that other suitable means for exchanging auxiliary information are also feasible.

[0083] In some embodiments, the first device 110 may generate a DCI 640 including a field indicating frequency domain resources (also referred to herein as an FDRA field). For example, the DCI may be format 1_0 and may include... Figure 3 The FDRA field 310 in the example. As another example, the DCI can be format 1_1 and can include... Figure 3 The FDRA field is 320. It should be understood that other suitable forms are also possible for DCI.

[0084] In some embodiments, the first device 110 may determine or select frequency domain resources from public frequency resources used for scheduling multicast services.

[0085] In some embodiments, the first device 110 may scramble the DCI using an identifier associated with the multicast service. For example, the first device 110 may perform Cyclic Redundancy Check (CRC) scrambling on the DCI using G-RNTI. The first device 110 may then send the scrambled DCI to the second device 120.

[0086] Therefore, the second device 120 receives auxiliary information from the first device 110, and also receives the DCI from the first device 110. In some embodiments, the second device 120 can receive a DCI scrambled using an identifier associated with a multicast service from the downlink control channel. For example, the second device 120 can receive a DCI scrambled using a G-RNTI corresponding to a multicast service from the PDCCH. The second device 120 can then determine the DCI by descrambling the scrambled DCI.

[0087] In some embodiments, the second device 120 may be based on the BWP in the auxiliary information. SA The size of the FDRA field in the 670DCI is determined. Then, the second device 120 can retrieve or decode the 680 field from the DCI based on the field size. This process can be called DCI size estimation. This is done to ensure that all second devices configured with different BWPs can be synchronized in terms of possible DCI sizes. In this way, simplified blind decoding can be achieved.

[0088] The second device 120 determines the 690 frequency domain resources from the FDRA field in the DCI based on auxiliary information. In some embodiments, the second device 120 can determine the corresponding auxiliary information corresponding to the G-RNTI. In this way, different auxiliary information can be provided to different multicast services, and the allocation of frequency domain resources for multicast services can be implemented in a more flexible manner.

[0089] By determining the FDRA field, the second device 120 can determine 691 the RA type configured for the second device 120. In some embodiments, the RA type may be type 0, wherein the FDRA field includes a bitmap. Figure 7A Figure 700A illustrates an example determination of frequency domain resources for a multicast service of resource allocation (RA) type 0 according to some embodiments of this disclosure. Figure 7B Figure 700B illustrates another example of frequency domain resources determined for multicast services of Resource Allocation (RA) Type 0 according to some embodiments of this disclosure. Figure 7A and Figure 7B As shown, the FDRA field 701 is of type RA 0 and is in bitmap form. In this example, a bitmap field "1" indicates that the corresponding PRB will be scheduled using data, and "0" indicates that the corresponding PRB will not be scheduled using data. Of course, in some embodiments, a bitmap field "1" can indicate that the corresponding PRB will not be scheduled using data, and "0" can indicate that the corresponding PRB will be scheduled using data.

[0090] In some embodiments, the RA type may be type 1, where the FDRA field includes index information of the starting resource block (RB) (also referred to herein as RB_Start) and the number of RBs (also referred to herein as Length). In some embodiments, the index information may be an index of the starting RB. In some embodiments, the index information may be a resource indicator value that the second device 120 can use to determine the starting RB. In this case, the index of the starting RB may be determined based on the resource indicator value. The index of the starting RB indicates the PRB from which data is to be scheduled, and the number of RBs indicates the size of the data transfer based on the size of the RB in which the data that the second device 120 is interested in receiving will be scheduled. Figure 8A Figure 800A illustrates an example determination of frequency domain resources for a Type 1 multicast service according to some embodiments of the present disclosure. Figure 8B Figure 800B illustrates an example determination of frequency domain resources for a multicast service of RA type 1 according to some embodiments of this disclosure. Figure 8A and Figure 8B As shown, the FDRA field is of type RA1 and consists of two parts: RB_Start 801 and length 802.

[0091] In some embodiments, if it is determined that the FDRA field includes a bitmap, i.e., the FDRA field is of RA type 0, then FRO can be used to calculate the relative position of the bitmap configuration in the FDRA field within the active BWP of the second device 120. SA It can have the same size as the FDRA field and indicate the size of the public frequency resources of the group public PDSCH.

[0092] In some embodiments, the second device 120 may extend the 692 FDRA field such that the size of the FDRA field is equal to the size of the BWP configured for the second device 120 by filling the beginning and end of the FDRA field with a bit indicating that no data has been scheduled (also referred to herein as the first bit). It is assumed that the first bit is "0". Of course, other suitable bits are also possible. In some embodiments, the second device 120 may fill the beginning of the FDRA field with a first number of first bits, where the first number = FRO. In this case, the second device 120 may fill the end of the FDRA field with a second number of first bits, where the second number = BWP - FRO - BWP. SA Size.

[0093] For ease of explanation, combined with Figure 7A and Figure 7B Describe some examples. In these examples, consider two different UEs, UE-1 and UE-2, receiving multicast services over common frequency resources. For UE-1, these common frequency resources are part of BWP-1, while for UE-2, they are part of BWP-2. The total size of BWP-1 and BWP-2 for UE-1 and UE-2 is different.

[0094] exist Figure 7A In the example, the size of BWP is 20, as shown in 710, FRO = 5 and BWP SA =8. The FDRA field obtained from DCI is represented by 711. The size of the FDRA field 711 = BWP SA =8. The beginning of FDRA field 711 is padded with "0" bits of size = FRO = 5, as shown in 712, and the end of FDRA field 712 is padded with bits of size = BWP - FRO - BWP. SA =20-5-8=7 "0" bit filling.

[0095] exist Figure 7B In the example, the size of BWP is 10, as shown in 720, FRO = 1 and BWP SA =8. The FDRA field obtained from DCI is represented by 721. The size of the FDRA field 721 = BWP SA=8. The beginning of the FDRA field 721 is padded with "0" bits of size = FRO = 1, as shown in 722, and the end of the FDRA field 721 is padded with bits of size = BWP - FRO - BWP. SA =10-1-8=1 "0" bit filling.

[0096] from Figure 7A and Figure 7B As can be seen, although the total sizes of BWP-1 and BWP-2 used for UE-1 and UE-2 are different, both UE-1 and UE-2 are able to successfully identify the appropriate PRB in which the group common MBS data is scheduled using auxiliary information. The bitmap configuration is common to both UE-1 and UE-2, and with the auxiliary information, both UE-1 and UE-2 are able to determine the PRB index in which the data is expected to be scheduled.

[0097] Based on the extended fields, the second device 120 can identify 693 frequency domain resources scheduled for multicast services within the BWP configured for the second device 120, such as... Figure 7A 713 and Figure 7B As shown in 723.

[0098] In some embodiments, if the FDRA field is determined to include index information of the starting RB and the number of RBs, i.e., the FDRA field is RA type 1, then the second device 120 can determine the 692' Resource Indicator Value (RIV) based on the index information, the number of RBs, and auxiliary information. In some embodiments, the second device 120 can obtain additional index information (also referred to herein as RB_Start_Actual) based on the index information of the starting RB and FRO. For example, RB_Start_Actual = FRO + RB_Start. In some embodiments, the index information in the group common DCI can always be 0 (i.e., RB_Start = 0). Here, the number of RBs ≤ BWP SA In this case, BWP SA It is not necessary to configure this in the auxiliary information. In some embodiments, if RB_Start + Length = the size of BWP, then BWP SA It can be omitted.

[0099] In some embodiments, the second device 120 may be based on additional index information, BWP SA The number of RBs determines the RIV. For example, assume the size of BWP is BWP. SA And since the index of the starting RB is RB_Start_Actual, the RIV can be determined by the following formulas (1) and (2):

[0100] if but

[0101]

[0102] otherwise

[0103]

[0104] Where L RRs Represents the number of RBs, RB start Indicates the index of the starting RB. Indicates the size of BWP. L RBs ≥1 and should not exceed and And RB start =RB_Start_Actual.

[0105] It should be understood that the above equation is merely an example, and other suitable methods can also be used to calculate the RIV. Based on the RIV, the second device 120 can determine the frequency domain resources scheduled for multicast services within the BWP configured for the second device 120.

[0106] For ease of explanation, combined with Figure 8A and Figure 8B Describe some examples. In these examples, consider two different UEs, UE-1 and UE-2, receiving multicast services over common frequency resources. For UE-1, these common frequency resources are part of BWP-1, while for UE-2, they are part of BWP-2. The total size of BWP-1 and BWP-2 for UE-1 and UE-2 is different.

[0107] exist Figure 8A In the example, the size of BWP is 20, as shown in 810, FRO = 5, as shown in 811, and BWP SA =8, as shown in 812. The public frequency resources (PRB index) determined for multicast services are represented by 813. In Figure 8B In the example, the size of BWP is 10, as shown in 820, FRO = 1, as shown in 821, and BWP SA =8, as shown in 822. The public frequency resources (PRB index) determined for multicast services are represented by 823.

[0108] from Figure 8A and Figure 8BAs can be seen, although the total sizes of BWP-1 and BWP-2 used for UE-1 and UE-2 are different, both UE-1 and UE-2 are able to successfully identify the appropriate PRB in which the group common MBS data is scheduled using auxiliary information. The bitmap configuration is common to both UE-1 and UE-2, and with the auxiliary information, both UE-1 and UE-2 are able to determine the PRB index in which the data is expected to be scheduled.

[0109] pass Figure 6 The process described herein allows the second device 120 to be configured with an active BWP that meets both MBS and unicast requirements, meaning that the second device 20 does not need to frequently switch BWPs. This process can also be applied to cross-BWP switching scenarios for scheduling multicast (and possibly unicast) services.

[0110] In summary, by combining the optimal aspects of the dedicated BWP size of the second device 120 with the public frequency resources of multicast services, Figure 6 The process described herein provides significant flexibility for scheduling multicast services (e.g., MBS PDSCH) for the first device 110. Furthermore, by enabling simpler blind decoding with predictable DCI sizes, this process provides significant complexity reduction for the second device 120, and simplifies and makes group scheduling for a large number of second devices straightforward. Moreover, the process is independent of the RA type used at the first device 110, further enhancing the scheduling flexibility of multicast service data within the PDSCH. Additionally, this process enables the first device 110 to schedule unicast and multicast services of the second device 120 within the same time slot by implementing a flexible BWP configuration specifically for the second device 120.

[0111] Corresponding to the above process, some exemplary embodiments of this disclosure will now be described in detail with reference to the accompanying drawings. However, those skilled in the art will readily understand that the detailed description of these drawings given herein is for illustrative purposes, as this disclosure can be extended beyond these limited embodiments.

[0112] Figure 9 A flowchart is shown of a communication method 900 implemented at a first device according to an example embodiment of the present disclosure. Method 900 can be implemented in... Figure 1 The first device shown is implemented at point 110. For ease of discussion, reference will be made to... Figure 1 Method 900 is described. It should be understood that method 900 may also include additional boxes not shown and / or omit some boxes shown, and the scope of this disclosure is not limited in this respect.

[0113] like Figure 9As shown, in block 910, first device 110 receives multicast services to be scheduled for second device 120 from core network elements. In block 920, first device 110 can generate auxiliary information for second device 120. This auxiliary information enables second device 120 to identify frequency domain resources allocated for the multicast service within a BWP configured for second device 120.

[0114] In some embodiments, the auxiliary information may include at least one of the following: an identifier of the BWP in which the frequency domain resource is scheduled; an offset indicating the starting position of the frequency domain resource within the BWP; or a parameter for adapting the size of the BWP for the multicast service to the size of the BWP configured for the second device 120. In some embodiments, the auxiliary information may be associated with an identifier associated with the multicast service. For example, the identifier is G-RNTI.

[0115] In block 930, the first device 110 may send auxiliary information to the second device 120. In some embodiments, the first device 110 may generate a DCI including a field indicating frequency domain resources selected from public frequency resources used for scheduling multicast services; scramble the DCI using an identifier associated with the multicast service; and send the scrambled DCI to the second device 120.

[0116] Figure 9 The operations in the method correspond to Figure 3 The operations described in the text are explained here, and therefore other details are omitted. Using... Figure 9 This method allows for more flexible scheduling of public frequency resources for multicast services. Furthermore, it enables the scheduling of unicast and multicast services within the same time slot.

[0117] Accordingly, embodiments of this disclosure also provide a communication method implemented at a second device. Figure 10 A flowchart illustrating a communication method 1000 implemented at a second device according to an example embodiment of the present disclosure is shown. Method 1000 can be implemented in... Figure 1 The second device shown is implemented at point 120. For ease of discussion, reference will be made to... Figure 1 Method 1000 is described. It should be understood that method 1000 may also include additional boxes not shown and / or omit some boxes shown, and the scope of this disclosure is not limited in this respect.

[0118] like Figure 10As shown in block 1010, the second device 120 receives auxiliary information from the first device 110. The auxiliary information enables the second device 120 to identify frequency domain resources allocated for the multicast service within a BWP configured for the second device 120. In some embodiments, the auxiliary information may include at least one of the following: an identifier of the BWP in which the frequency domain resources are scheduled; an offset indicating the starting position of the frequency domain resources within the BWP; or a parameter for adapting the size of the BWP for the multicast service relative to the size of the BWP configured for the second device 120. In some embodiments, the auxiliary information may be associated with an identifier associated with the multicast service. For example, the identifier is G-RNTI.

[0119] In block 1020, the second device 120 determines frequency domain resources from a DCI based on auxiliary information received from the first device 110 and including a field indicating the frequency domain resources. In some embodiments, the second device 120 may receive a DCI scrambled using an identifier associated with a multicast service from a downlink control channel; and determine the DCI by descrambling the scrambled DCI. The following will be combined with... Figure 11 A detailed example of frequency domain resource determination is provided.

[0120] Figure 11 A flowchart of a method 1100 for determining frequency domain resources for a multicast service according to an example embodiment of the present disclosure is shown. Method 1100 can be implemented in... Figure 1 The second device shown is implemented at point 120. For ease of discussion, reference will be made to... Figure 1 Method 1100 is described. It should be understood that method 1100 may also include additional boxes not shown and / or omit some boxes shown, and the scope of this disclosure is not limited in this respect.

[0121] like Figure 11 As shown, in box 1110, the second device 120 can determine the size of the field based on parameters. In box 1120, the second device 120 can retrieve the field from the DCI based on the field size. In this way, blind decoding of the DCI can be simplified.

[0122] In box 1130, the second device 120 can determine whether the field is RA type 0 or type 1. If the field is determined to be RA type 0, that is, the field includes a bitmap, the process proceeds to box 1140.

[0123] In block 1140, the second device 120 can extend the field by padding the beginning of the field with a first number of first bits and the end of the field with a second number of first bits, such that the size of the field is equal to the size of the BWP configured for the second device 120, the first number is equal to the offset, and the first bit indicates that no data is scheduled. In block 1150, the second device 120 can determine the frequency domain resources for the BWP of the second device based on the extended field.

[0124] If the field is determined to be RA type 1, i.e., the field includes the index information of the starting RB and the number of RBs, then the process proceeds to box 1160. In box 1160, the second device 120 can obtain additional index information based on the index information and offset. In box 1170, the second device 120 can determine the RIV based on the additional index information, parameters, and the number of RBs. In box 1180, the second device 120 can determine the frequency domain resources based on the RIV.

[0125] Figure 10 The operations in the method correspond to Figure 3 The operations described in the text are omitted here, and therefore other details are omitted. Using Figure 10 This method allows for flexible identification of public frequency resources for multicast services within a dedicated BWP in the second device 120. Furthermore, it enables simpler blind decoding with a predictable DCI size and significantly reduces complexity at the second device 120.

[0126] In some embodiments, an apparatus capable of performing method 900 (e.g., first device 110) may include components for performing corresponding steps of method 900. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module.

[0127] In some embodiments, the apparatus may include: components for receiving, at a first device, multicast services to be scheduled for a second device from core network elements; components for generating auxiliary information for the second device, the auxiliary information enabling the second device to identify frequency domain resources allocated for the multicast services within a bandwidth portion configured for the second device; and components for sending the auxiliary information to the second device.

[0128] In some embodiments, the auxiliary information may include at least one of the following: an identifier of the bandwidth portion in which the frequency domain resource is scheduled; an offset indicating the starting position of the frequency domain resource within the bandwidth portion; or a parameter for adapting the size of the bandwidth portion of the multicast service to the size of the bandwidth portion configured for the second device.

[0129] In some embodiments, auxiliary information may be associated with an identifier that is associated with a multicast service.

[0130] In some embodiments, the apparatus may further include: means for generating downlink control information including a field indicating frequency domain resources, the frequency domain resources being selected from public frequency resources for scheduling multicast services; means for scrambling the downlink control information using an identifier associated with the multicast service; and means for sending the scrambled downlink control information to a second device.

[0131] In some embodiments, an apparatus capable of performing method 1000 (e.g., second device 120) may include components for performing corresponding steps of method 1000. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module.

[0132] In some embodiments, the apparatus may include: a component for receiving auxiliary information from a first device, the auxiliary information enabling a second device to identify frequency domain resources allocated for multicast services within a bandwidth portion configured for the second device; and a component for determining frequency domain resources from downlink control information based on the auxiliary information, the downlink control information being received from the first device and including a field indicating the frequency domain resources.

[0133] In some embodiments, the auxiliary information may include at least one of the following: an identifier of the bandwidth portion in which the frequency domain resource is scheduled; an offset indicating the starting position of the frequency domain resource within the bandwidth portion; or a parameter for adapting the size of the bandwidth portion of the multicast service to the size of the bandwidth portion configured for the second device.

[0134] In some embodiments, auxiliary information may be associated with an identifier that is associated with a multicast service.

[0135] In some embodiments, the apparatus may further include: components for receiving downlink control information scrambled using an identifier associated with a multicast service from a downlink control channel; and components for determining the downlink control information by descrambling the scrambled downlink control information.

[0136] In some embodiments, the components for determining may include: components for determining the size of a field based on parameters; components for obtaining a field from downlink control information based on the size of the field; and components for determining frequency domain resources based on the field.

[0137] In some embodiments, the determining component may include: a component for extending the field by padding the beginning of the field with a first number of first bits and the end of the field with a second number of first bits, based on the determined field including a bitmap, such that the size of the field is equal to the size of the bandwidth portion configured for the second device, the first number being equal to an offset, and the first bit indicating that no data is scheduled; and a component for determining frequency domain resources for the bandwidth portion of the second device based on the extended field.

[0138] In some embodiments, the means for determining may include: a component for obtaining additional index information based on the index information and offset according to the determination field including the index information of the starting resource block and the number of resource blocks; a component for determining a resource indicator value based on the additional index information, parameters and the number of resource blocks; and a component for determining frequency domain resources based on the resource indicator value.

[0139] Figure 12 This is a simplified block diagram of a device 1200 suitable for implementing embodiments of the present disclosure. The device 1200 can be provided to implement a first device or a second device, for example, as... Figure 1 The first device 110 or the second device 120 are shown. As shown, device 1200 includes one or more processors 1210, one or more memories 1220 coupled to processor 1210, and one or more communication modules 1240 (such as transmitters and / or receivers) coupled to processor 1210.

[0140] The communication module 1240 is used for bidirectional communication. The communication module 1240 has at least one antenna to facilitate communication. The communication interface can represent any interface necessary for communication with other network elements.

[0141] Processor 1210 can be any type suitable for a local technology network, and by way of non-limiting example, can include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), and processor based on a multi-core processor architecture. Device 1200 can have multiple processors, such as application-specific integrated circuit chips that are time-dependent on a clock synchronized with the main processor.

[0142] Memory 1220 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 1224, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disc (CD), digital video disk (DVD), and other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 1222 and other volatile memories that do not persist during power outages.

[0143] Computer program 1230 includes computer-executable instructions that are executed by the associated processor 1210. Program 1230 may be stored in ROM 1224. Processor 1210 may perform any suitable actions and processes by loading program 1230 into RAM 1222.

[0144] The embodiments of this disclosure can be implemented by program 1230, enabling device 1200 to execute reference... Figures 1 to 11 Any process discussed in this disclosure. Embodiments of this disclosure may also be implemented by hardware or a combination of software and hardware.

[0145] In some embodiments, program 1230 may be tangibly contained in a computer-readable medium, which may be included in device 1200 (such as memory 1220) or other storage device accessible to device 1200. Device 1200 may load program 1230 from the computer-readable medium into RAM 1222 for execution. The computer-readable medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Figure 13 An example of a computer-readable medium 1300 in the form of a CD or DVD is shown. A program 1230 is stored on the computer-readable medium.

[0146] Generally, the various embodiments of this disclosure can be implemented using hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented using hardware, while others can be implemented using firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are illustrated and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, as non-limiting examples, the blocks, apparatuses, systems, techniques, or methods described herein can be implemented using hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0147] This disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in a program module, which execute in a device on a target real or virtual processor to perform the above-referenced... Figures 9 to 11Methods 900 to 1100 are described. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of a program module can be combined or split among program modules as needed. The machine-executable instructions of a program module can execute on a local or distributed device. In a distributed device, a program module can reside on both local and remote storage media.

[0148] Program code used to perform the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a stand-alone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0149] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

[0150] Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable media can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination of the foregoing. More specific examples of computer-readable storage media will include electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0151] Furthermore, although operations are described in a specific order, this should not be construed as requiring the operations to be performed in the specific order shown or sequentially, or to perform all of the shown operations to obtain the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features described in the context of a single embodiment may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0152] Although this disclosure has been described in language specific to structural features and / or methodological actions, it should be understood that this disclosure as defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms of implementing the claims.

Claims

1. A first device for communication, comprising: At least one processor; as well as At least one memory, including computer program code; The at least one memory and the computer program code are configured together with the at least one processor such that the first device: Receive multicast services scheduled for the second device from core network components; Generate auxiliary information for the second device, the auxiliary information enabling the second device to identify frequency domain resources allocated for the multicast service within a bandwidth portion configured for the second device; Send the auxiliary information to the second device; as well as Downlink control information is sent to the second device. The frequency domain resources will be determined by the second device from the downlink control information based on the auxiliary information. The downlink control information includes a field indicating the frequency domain resources. The field includes the index information of the starting resource block and the number of resource blocks. The auxiliary information includes at least parameters used to adapt the size of the bandwidth portion of the multicast service relative to the size of the bandwidth portion configured for the second device. The parameters are configured to be used by the second device, along with additional index information and the number of resource blocks, to determine a resource indicator value, thereby determining the frequency domain resource. The additional index information is obtained by the second device based on the index information included in the field and an offset indicating the starting position of the frequency domain resource within the bandwidth portion.

2. The first device according to claim 1, wherein the auxiliary information is associated with an identifier, and the identifier is associated with the multicast service.

3. The first device according to claim 1, wherein the first device is further configured to: Generate downlink control information, the downlink control information including a field indicating the frequency domain resources, the frequency domain resources being selected from public frequency resources used for scheduling the multicast service; The downlink control information is scrambled using an identifier associated with the multicast service; as well as The scrambled downlink control information is sent to the second device.

4. The first device according to claim 1, wherein the first device is a network device and the second device is a terminal device.

5. A second device for communication, comprising: At least one processor; as well as At least one memory, including computer program code; The at least one memory and the computer program code are configured together with the at least one processor such that the second device: The second device receives auxiliary information from the first device, which enables the second device to identify frequency domain resources allocated for multicast services within a bandwidth portion configured for the second device. as well as The frequency domain resource is determined from downlink control information based on the auxiliary information, the downlink control information being received from the first device and including a field indicating the frequency domain resource; The auxiliary information includes at least parameters for adapting the size of the bandwidth portion of the multicast service to a size configured for the second device; and The second device is configured to determine the frequency domain resources by: Based on the determination that the field includes index information of the starting resource block and the number of resource blocks, additional index information is obtained based on the index information included in the field and the offset indicating the starting position of the frequency domain resource within the bandwidth portion. Based on the additional index information, the parameters, and the number of resource blocks, the resource indicator value is determined; as well as The frequency domain resource is determined based on the resource indicator value.

6. The second device according to claim 5, wherein the auxiliary information is associated with an identifier, and the identifier is associated with the multicast service.

7. The second device according to claim 5, wherein the second device is further configured to: Receive downlink control information scrambled with an identifier associated with the multicast service from the downlink control channel; and The downlink control information is determined by descrambling the scrambled downlink control information.

8. The second device according to claim 5, wherein the first device is a network device and the second device is a terminal device.

9. A communication method, comprising: At the second device, auxiliary information is received from the first device, which enables the second device to identify frequency domain resources allocated for multicast services within a bandwidth portion configured for the second device. as well as The frequency domain resource is determined from downlink control information based on the auxiliary information, the downlink control information being received from the first device and including a field indicating the frequency domain resource; The auxiliary information includes at least parameters for adapting the size of the bandwidth portion of the multicast service to the size of the bandwidth portion configured for the second device. as well as The determination of the frequency domain resources includes: Based on the determination that the field includes index information of the starting resource block and the number of resource blocks, additional index information is obtained based on the index information included in the field and the offset indicating the starting position of the frequency domain resource within the bandwidth portion. Based on the additional index information, the parameters, and the number of resource blocks, the resource indicator value is determined; as well as The frequency domain resource is determined based on the resource indicator value.

10. The method of claim 9, wherein the auxiliary information is associated with an identifier, and the identifier is associated with the multicast service.

11. The method of claim 9, further comprising: Receive downlink control information scrambled with an identifier associated with the multicast service from the downlink control channel; as well as The downlink control information is determined by descrambling the scrambled downlink control information.

12. The method of claim 9, wherein the first device is a network device and the second device is a terminal device.

Images