Method and apparatus for group message modification and cancellation

Abstract

An embodiment of the present disclosure provides a method and apparatus for group message modification and cancellation. The method performed by a publishing node includes receiving a group message request from an application node. When the group message request is for modifying a group message delivery and includes a group message payload, the method further includes converting the group message payload into a file. The method further includes sending the file to a second broadcast-multicast node.

Description

Technical Field

[0001] Non-limiting and exemplary embodiments of the present disclosure generally relate to the field of communication technologies, and more particularly, to methods and apparatuses for group message modification and cancellation.

Background Art

[0002] This section introduces aspects that may facilitate a better understanding of the present disclosure. Accordingly, the description in this section should be read in this perspective and should not be understood as an admission of what is in the prior art or what is not in the prior art.

[0003] 3GPP TS23.247 V.17.2.0, the entire disclosure of which is incorporated herein by reference, describes architecture extensions for 5G (fifth generation) multicast broadcast services. 3GPP TS23.682 V.17.2.0, the entire disclosure of which is incorporated herein by reference, describes group message delivery procedures. 3GPP TS23.246 V.16.1.0, the entire disclosure of which is incorporated herein by reference, describes multimedia broadcast / multicast service (MBMS) architecture and functional descriptions.

[0004] FIG. 1A shows an example of a delivery method, which is the same as FIG. 4.1-1 of 3GPP TS23.247 V17.2.0.

[0005] Multicast and broadcast services (MBS) are point-to-multipoint services in which data is transmitted from a single source entity to multiple receivers, either to all users in a broadcast service area or to users in a multicast group. The corresponding types of MBS sessions are broadcast sessions and multicast sessions.

[0006] The MBS architecture enables the distribution of MBS data from the 5GS (5G System) entry point to one or more NG-RAN (Next Generation Radio Access Network) nodes and then to the UE (User Equipment) in accordance with the 5th generation (5G) system architecture principles defined in 3GPP TS23.501 V17.1.1, the entire disclosure of which is incorporated herein by reference. The MBS architecture provides for efficient use of RAN (Radio Access Network) resources and CN (Core Network) resources with an emphasis on radio interface efficiency, and efficient transport for various multicast and broadcast services.

[0007] MBS also provides functions such as local MBS services, permission for multicast MBS, and QoS (Quality of Service) differentiation. MBS traffic is delivered from a single data source (e.g., an application service provider) to multiple UEs. Depending on many factors, there are several delivery methods that can be used to deliver MBS traffic in the 5GS (5G System).

[0008] There are two possible delivery methods for transmitting MBS data between the 5GC (5G Core Network) and the NG-RAN (Next Generation RAN).

[0009] The first delivery method is the 5GC individual MBS traffic delivery method. This method is applicable only for multicast MBS sessions. The 5GC receives a single copy of the MBS data packets and distributes separate copies of those MBS data packets to individual UEs via a PDU session per UE. Thus, for each such UE, one PDU session is required to be associated with the multicast session.

[0010] The second delivery method is the 5GC shared MBS traffic delivery method. This method is applicable for both broadcast MBS sessions and multicast MBS sessions. The 5GC receives a single copy of the MBS data packets and distributes a single copy of those MBS packets to the NG-RAN nodes, which then distribute the packets to one or more UEs.

[0011] The 5GC shared MBS traffic delivery method is required in all MBS deployments. The 5GC individual MBS traffic delivery method is required to enable mobility when there is an NG-RAN deployment with non-homogeneous support for MBS.

[0012] In a multicast session, a single copy of the MBS data packets received by the CN (core network) can be distributed for one or more UEs via the 5GC individual MBS traffic delivery method and for other UEs via the 5GC shared MBS traffic delivery method.

[0013] Between the NG-RAN and the UE, two delivery methods are available for the transmission of MBS data packets over the radio interface.

[0014] The first delivery method is the point-to-point (PTP) delivery method where the NG-RAN distributes a separate copy of the MBS data packets over the radio interface to one or more individual UEs.

[0015] The second delivery method is the point-to-multipoint (PTM) delivery method where the NG-RAN distributes a single copy of the MBS data packets over the radio interface to multiple UEs.

[0016] The NG-RAN may use a combination of PTP / PTM to deliver MBS data packets to the UEs.

[0017] As shown in Figure 1A, the 5GC shared MBS traffic distribution method (using PTP or PTM distribution) and the 5GC individual MBS traffic distribution method can be used simultaneously for a multicast MBS session.

[0018] In MBS broadcast communication, only the 5GC shared MBS traffic distribution method using PTM distribution is applicable.

[0019] In MBS multicast communication, when the NG-RAN node supports MBS, the network shall use the 5GC shared MBS traffic distribution method for MBS data transmission.

[0020] In MBS multicast communication, switching between the 5GC shared MBS traffic distribution method and the 5GC individual MBS traffic distribution method is supported. UE mobility is supported both between RAN nodes that support MBS and between a RAN node that supports MBS and a RAN node that does not support MBS.

[0021] In MBS multicast communication, it is assumed that switching between the PTP distribution method and the PTM distribution method for 5GC shared MBS traffic distribution is supported. The NG-RAN is the decision point for switching between the PTP distribution method and the PTM distribution method.

[0022] The term temporary mobile group identification information (TMGI) is defined in 3GPP TS23.003 V17.2.0, the entire disclosure of which is incorporated herein by reference, and is used to identify a broadcast MBS session or a multicast MBS session.

Summary of the Invention

[0023] The summary of the present invention is provided to introduce, in a simplified form, a selection of concepts that will be further described below in the mode for carrying out the invention. The summary of the present invention does not identify the main features or essential features of the claimed subject matter, nor is it used to limit the scope of the claimed subject matter.

[0024] There are several problems with existing group message modification and cancellation solutions. According to 3GPP TS23.682 V17.2.0, it is expected that the Service Capability Server (SCS) / Application Server (AS) will send a modify group message request to the Service Capability Exposure Function (SCEF), and the SCEF will be able to modify or cancel the group message delivery to the UE using MBMS. When modifying the group message delivery, after the SCEF calls the Modify MBMS Bearer procedure for the BM-SC to replace the previous group message with a new group message. The Modify MBMS Bearer procedure can only be used to update the MBMS service area and the Allocation and Retention Priority (ARP), not the content delivered within the MBMS session. Also, since the xMB interface provided by the BM-SC does not directly support group messages, the SCEF cannot use the Update Session Properties BM-SC to replace the group message with a new group message.

[0025] In section 8.8.1 of 3GPP 23.246 v16.1.0, the MBMS session update procedure is specified as follows: "The BM-SC uses this procedure to update the service area or QoS (ARP) for an ongoing MBMS broadcast service session."

[0026] In section 5.1.2.4 of 3GPP TS23.468 V17.0.0, the entire disclosure of which is incorporated herein by reference, the MBMS bearer modification procedure is specified as follows: "The MBMS bearer modification procedure is used by the GCS AS to cause a modification of the priority and preemption values for an MBMS bearer, an MBMS broadcast area, or both."

[0027] According to section 5.4.4 of 3GPP TS26.348 V16.3.0, the entire disclosure of which is incorporated herein by reference, "session property update" may be used to update session properties including a file list. However, in section 5.5.2 of 3GPP TS23.682 V17.2.0, there is no description of how group messages can be delivered by using session property update.

[0028] When canceling group message delivery, if the SCEF simply invokes a Terminate Session to the Broadcast Multicast Service Center (BM-SC), the MBMS session can be successfully terminated, but the UE is not aware of the cancellation of the group message.

[0029] In 3GPP TR23.700-47 V0.2.0, the entire disclosure of which is incorporated herein by reference, group message modification on top of MBS requires further consideration.

[0030] To overcome or mitigate at least one of the above-described problems or other problems, embodiments of the present disclosure propose an improved solution for group message modification and cancellation.

[0031] In a first aspect of the present disclosure, a method executed by a public node is provided. The method includes receiving a group message request from an application node.

[0032] In one embodiment, the group message request is for a modification of group message delivery, and when including a group message payload, the method may further include converting the group message payload into a file.

[0033] In one embodiment, the method may further include sending the file to a second broadcast multicast node.

[0034] In one embodiment, when the group message request is for cancellation of group message delivery, the method may further include sending a first instruction for cancellation of file delivery to a third broadcast multicast node.

[0035] In one embodiment, when the group message request is for cancellation of group message delivery, the method may further include sending an HTTP DELETE to a second broadcast multicast node to cancel file delivery.

[0036] In one embodiment, the determined file metadata may be used as file metadata information.

[0037] In one embodiment, the determined file metadata may include a file uniform resource locator (URL) and / or a file uniform resource identifier (URI).

[0038] In one embodiment, the ingest mode or object acquisition method may be set to pull.

[0039] In one embodiment, the ingest mode or object acquisition method may be set to push.

[0040] In one embodiment, when the capture mode or object acquisition method is set to pull, sending a file to a second broadcast multicast node is to send a second instruction for updating the file to a third broadcast multicast node, and the third broadcast multicast node sends a third instruction based on the second instruction to the second broadcast multicast node, which may include sending a second instruction for updating the file, receiving a request to fetch the file from the second broadcast multicast node, and sending a response including the file to the second broadcast multicast node.

[0041] In one embodiment, the second instruction may be a property or parameter with a refresh or update value within the session parameters for notifying the second broadcast multicast node regarding the refresh of the file.

[0042] In one embodiment, when the capture mode or object acquisition method is set to push, sending a file to a second broadcast multicast node may include pushing the file to the second broadcast multicast node.

[0043] In one embodiment, the file may be included in a file list.

[0044] In one embodiment, the first instruction may be a property or parameter with a cancel value for notifying the second broadcast multicast node regarding the cancellation of file distribution.

[0045] In one embodiment, the public node may include at least one of a network exposure function (NEF), or a combined NEF and service capability exposure function (SCEF).

[0046] In one embodiment, the second broadcast multicast node may include a multicast / broadcast service transport function (MBSTF).

[0047] In one embodiment, the third broadcast multicast node may include a multicast / broadcast service function (MBSF).

[0048] In one embodiment, a group message request may include a group message modification request having a requested action set to modify or cancel.

[0049] In one embodiment, a group message request may include a group message modification request or a group message cancellation request.

[0050] In a second aspect of the present disclosure, a method executed by a second broadcast multicast node is provided. The method may include receiving a file from a public node, or receiving an HTTP deletion for canceling file distribution from a public node, or receiving a first indication of cancellation of file distribution from a third broadcast multicast node. The file may be converted from a group message payload, and the group message payload may be included in a group message request instructing modification or cancellation of group message distribution from an application node to a public node.

[0051] In one embodiment, the method may further include receiving the file, encoding the file when group message distribution has not started, and using the file to replace the original file. The file will be distributed after group message distribution has started.

[0052] In one embodiment, the method may further include receiving a file, encoding the file when group message delivery starts, stopping ongoing group message delivery, and starting delivery of the file, or starting delivery of the file after an ongoing group message has been delivered.

[0053] In one embodiment, the method may further include receiving a first instruction or an HTTP deletion, stopping file delivery when group message delivery starts, and / or notifying a multicast / broadcast service (MBS) client regarding cancellation of file delivery.

[0054] In one embodiment, the method may further include receiving a first instruction or an HTTP deletion, canceling file delivery when group message delivery has not started, and / or notifying a multicast / broadcast service (MBS) client regarding cancellation of file delivery.

[0055] In one embodiment, the cancellation may be delivered to at least one MBS client within or outside the bandwidth of the MBS session.

[0056] In one embodiment, the determined file metadata may be used as metadata information of the file.

[0057] In one embodiment, the determined file metadata may include a file uniform resource locator (URL) and / or a file uniform resource identifier (URI).

[0058] In one embodiment, when the capture mode or object acquisition method is set to pull, receiving a file from the public node may include receiving a third instruction based on a second instruction for updating the file from a third broadcast multicast node, sending a request to the public node to fetch the file, and receiving the file from the public node.

[0059] In one embodiment, the second instruction may be a property or parameter with a refresh or update value for notifying the second broadcast multicast node regarding the refresh of the file.

[0060] In one embodiment, when the capture mode or object acquisition method is set to push, receiving a file from the public node may include receiving a file pushed by the public node.

[0061] In one embodiment, the file may be included in a file list.

[0062] In one embodiment, the first instruction may be a property or parameter with a cancel value for notifying the second broadcast multicast node regarding the cancellation of file distribution.

[0063] In one embodiment, the public node may include a NEF, or a combined NEF and SCEF.

[0064] In one embodiment, the second broadcast multicast node may include an MBSTF.

[0065] In one embodiment, the third broadcast multicast node may include an MBSF.

[0066] In one embodiment, the group message request may include a group message modification request with a requested action set to modify or cancel.

[0067] In one embodiment, the group message request may include a group message modification request or a group message cancellation request.

[0068] In a third aspect of the present disclosure, a method performed by a third broadcast multicast node is provided. The method may include receiving, from a public node, a second instruction for file update or a first instruction for cancellation of file distribution. The file may be converted from a group message payload, which may be included in a group message request instructing modification or cancellation of group message distribution from an application node to a public node. The method may further include sending the second instruction or the first instruction to a second broadcast multicast node.

[0069] In one embodiment, the method may further include, when the first instruction is received, notifying a multicast / broadcast service (MBS) client regarding cancellation of file distribution.

[0070] In one embodiment, the cancellation may be distributed to at least one MBS client within the bandwidth of the MBS session or outside the bandwidth of the MBS session.

[0071] In one embodiment, the first instruction may be a property or parameter having a cancellation value for notifying a second broadcast multicast node regarding cancellation of file distribution.

[0072] In one embodiment, the second instruction may be a property or parameter having a refresh or update value within a session parameter for notifying a second broadcast multicast node regarding refresh of the file.

[0073] In one embodiment, the public node may include a NEF, or a combined NEF and SCEF.

[0074] In one embodiment, the second broadcast multicast node may include an MBSTF.

[0075] In one embodiment, the third broadcast multicast node may include an MBSF.

[0076] In one embodiment, the group message request may include a group message modification request having a requested action set to modify or cancel.

[0077] In one embodiment, the group message request may include a group message modification request or a group message cancellation request.

[0078] In a fourth aspect of the present disclosure, a method executed by a user equipment is provided. The method may include receiving a message from a second broadcast multicast node or a third broadcast multicast node. The message includes a cancellation of file distribution.

[0079] In one embodiment, the cancellation may be received within the bandwidth of a multicast / broadcast service (MBS) session or outside the bandwidth of the MBS session.

[0080] In one embodiment, the user equipment may include an MBS client.

[0081] In one embodiment, the second broadcast multicast node may include an MBSTF.

[0082] In one embodiment, the third broadcast multicast node may include an MBSF.

[0083] In another aspect of the present disclosure, a public node is provided. The present public node includes a processor and a memory coupled to the processor. The memory contains instructions executable by the processor. The public node is operable to receive a group message request from an application node.

[0084] In one embodiment, when the group message request is for a modification of group message delivery and includes a group message payload, the public node is further operable to convert the group message payload into a file. The public node is further operable to send the file to a second broadcast multicast node.

[0085] In one embodiment, when the group message request is for cancellation of group message delivery, the public node is further operable to send a first instruction for cancellation of file delivery to a third broadcast multicast node.

[0086] In one embodiment, when the group message request is for cancellation of group message delivery, the public node is further operable to send an HTTP delete to a second broadcast multicast node to cancel file delivery.

[0087] In another aspect of the present disclosure, a second broadcast multicast node is provided. The second broadcast multicast node includes a processor and a memory coupled to the processor. The memory includes instructions executable by the processor. The second broadcast multicast node is operable to receive a file from a public node, or receive an HTTP deletion to cancel a file distribution from the public node, or receive a first instruction to cancel a file distribution from a third broadcast multicast node. The file can be converted from a group message payload, and the group message payload can be included in a group message request that instructs modification or cancellation of a group message distribution from an application node to a public node.

[0088] In another aspect of the present disclosure, a third broadcast multicast node is provided. The third broadcast multicast node includes a processor and a memory coupled to the processor. The memory includes instructions executable by the processor. The third broadcast multicast node is operable to receive a second instruction for updating a file or a first instruction to cancel a file distribution from a public node. The file is converted from a group message payload, and the group message payload is included in a group message request that instructs modification or cancellation of a group message distribution from an application node to a public node. The third broadcast multicast node is further operable to send the second instruction or the first instruction to a second broadcast multicast node.

[0089] In another aspect of the present disclosure, a user device is provided. The user device includes a processor and a memory coupled to the processor. The memory includes instructions executable by the processor. The user device is operable to receive a message from a second broadcast multicast node or a third broadcast multicast node. The message may include a cancellation of file distribution.

[0090] In another aspect of the present disclosure, a public node is provided. The public node includes a first receiving module configured to receive a group message request from an application node.

[0091] In one embodiment, when the group message request is for a modification of group message delivery and includes a group message payload, the public node further includes a conversion module configured to convert the group message payload into a file. The public node further includes a first sending module configured to send the file to a second broadcast multicast node.

[0092] In one embodiment, when the group message request is for a cancellation of group message delivery, the public node may further include a third sending module configured to send a first instruction for cancellation of file distribution to a third broadcast multicast node. The public node may further include a fourth sending module configured to send an HTTP deletion to the second broadcast multicast node to cancel file distribution.

[0093] In another aspect of the present disclosure, a second broadcast multicast node is provided. The second broadcast multicast node is configured to perform receiving a file from a public node, or receiving an HTTP deletion for canceling file distribution from the public node, or receiving a first instruction for canceling file distribution from a third broadcast multicast node. The file can be converted from a group message payload, and the group message payload can be included in a group message request instructing modification or cancellation of group message distribution from an application node to the public node.

[0094] In one embodiment, when receiving a file and when group message distribution has not started, the second broadcast multicast node may further include a first encoding module configured to encode the file and a first usage module configured to use the file to replace the original file. The file will be distributed after the group message distribution starts.

[0095] In one embodiment, when receiving a file and when group message distribution has started, the second broadcast multicast node further includes a second encoding module configured to encode the file, a first stop module configured to stop the ongoing group message distribution, and a first start module configured to start distributing the file or start distributing the file after the ongoing group message has been distributed.

[0096] In one embodiment, when receiving a first instruction or an HTTP deletion and when group message delivery starts, this second broadcast multicast node further includes a third stop module configured to stop file delivery and / or a first notification module configured to notify a multicast / broadcast service (MBS) client regarding cancellation of file delivery.

[0097] In one embodiment, when receiving a first instruction or an HTTP deletion and when group message delivery has not started, this second broadcast multicast node further includes a cancellation module configured to cancel file delivery and / or a second notification module configured to notify a multicast / broadcast service (MBS) client regarding cancellation of file delivery.

[0098] In another aspect of the present disclosure, a third broadcast multicast node is provided. This third broadcast multicast node includes a receiving module configured to receive a second instruction for file update or a first instruction for cancellation of file delivery from a public node. The file is converted from a group message payload, and the group message payload is included in a group message request that instructs modification or cancellation of group message delivery from an application node to a public node. This third broadcast multicast node further includes a sending module configured to send the second instruction or the first instruction to the second broadcast multicast node.

[0099] In another aspect of the present disclosure, a user device is provided. This user device includes a receiving module configured to receive a message from a second broadcast multicast node or a third broadcast multicast node. The message includes cancellation of file delivery.

[0100] In another aspect of the present disclosure, there is provided a computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform any of the methods according to the first, second, third, and fourth aspects of the present disclosure.

[0101] In another aspect of the present disclosure, there is provided a computer program product including instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods according to the first, second, third, and fourth aspects of the present disclosure.

[0102] In another aspect of the present disclosure, there is provided a communication system including a host computer. The host computer includes a processing circuit configured to provide user data and a communication interface configured to forward the user data to a cellular network for transmission to a terminal device. The cellular network includes network devices (such as a radio access network node, a public node, a second broadcast multicast node, or a third broadcast multicast node) and / or terminal devices (such as the terminal device described above).

[0103] In an embodiment of the present disclosure, the system further includes a terminal device. The terminal device is configured to communicate with the network device.

[0104] In an embodiment of the present disclosure, the processing circuit of the host computer is configured to execute a host application, thereby providing user data, and the terminal device includes a processing circuit configured to execute a client application associated with the host application.

[0105] In another aspect of the present disclosure, a communication system including a host computer and a network device is provided. The host computer includes a communication interface configured to receive user data generated from a transmission from a terminal device. The transmission is from the terminal device to the network device. The network device is a wireless access network node, a public node, a second broadcast multicast node, or a third broadcast multicast node, and / or the terminal device is the terminal device described above.

[0106] In an embodiment of the present disclosure, the processing circuit of the host computer is configured to execute a host application. The terminal device is configured to execute a client application associated with the host application, thereby providing user data to be received by the host computer.

[0107] In another aspect of the present disclosure, a method implemented in a communication system that may include a host computer, a network device, and a terminal device is provided. The method may include providing user data at the host computer. Optionally, the method may include initiating, at the host computer, a transmission to convey the user data to the terminal device via a cellular network comprising the network device.

[0108] In another aspect of the present disclosure, a communication system including a host computer is provided. The host computer may comprise a processing circuit configured to provide user data and a communication interface configured to forward the user data to a cellular network for transmission to a terminal device. The cellular network may comprise a network device having a wireless interface and a processing circuit.

[0109] In another aspect of the present disclosure, a method implemented in a communication system that may include a host computer, a network device, and a terminal device is provided. The method may include providing user data at the host computer. Optionally, the method may include initiating, at the host computer, a transmission to convey the user data to the terminal device via a cellular network comprising the network device. The terminal device may execute any step of the method according to the fourth aspect of the present disclosure.

[0110] In another aspect of the present disclosure, a communication system including a host computer is provided. The host computer may comprise a processing circuit configured to provide user data and a communication interface configured to forward the user data to a cellular network for transmission to the terminal device. The terminal device may comprise a wireless interface and a processing circuit. The processing circuit of the terminal device may be configured to execute any step of the method according to the fourth aspect of the present disclosure.

[0111] In another aspect of the present disclosure, a method implemented in a communication system that may include a host computer, a network device, and a terminal device is provided. The method may include receiving, at the host computer, user data transmitted from the terminal device to the network device, wherein the terminal device may execute any step of the method according to the fourth aspect of the present disclosure.

[0112] In another aspect of the present disclosure, a communication system including a host computer is provided. The host computer may comprise a communication interface configured to receive user data resulting from a transmission from the terminal device to the network device. The terminal device may comprise a wireless interface and a processing circuit. The processing circuit of the terminal device may be configured to execute any step of the method according to the fourth aspect of the present disclosure.

[0113] In another aspect of the present disclosure, a method implemented in a communication system that may include a host computer, a network device, and a terminal device is provided. The method may include receiving, at the host computer, user data generated from a transmission received by the network device from the terminal device.

[0114] In another aspect of the present disclosure, a communication system that may include a host computer is provided. The host computer may include a communication interface configured to receive user data generated from a transmission from the terminal device to the network device. The network device may include a wireless interface and a processing circuit.

[0115] By applying the proposed solution according to the embodiments of the present disclosure, many advantages can be achieved. For example, some embodiments herein may enable group message modification and group message cancellation on MBMS, MBS, and MBS interworking with MBMS. Some embodiments herein may remedy the drawbacks in the current group message modification via MBMS (it is not feasible to replace the group message using session property updates to the BM-SC). Some embodiments herein may improve the limitations regarding the current group message cancellation via MBMS (SCEF session termination to the BM-SC, however, the UE is not aware of the cancellation of the group message). The embodiments herein are not limited to the above-described features and advantages. Those skilled in the art will recognize additional features and advantages upon reading the following detailed description.

[0116] The above and other aspects, features, and advantages of various embodiments of the present disclosure will become more fully apparent from the following modes for carrying out the invention, with reference to the accompanying drawings, in which like reference numerals or letters are used for designating like elements or equivalent elements. The drawings are illustrated to facilitate a better understanding of the embodiments of the present disclosure and are not necessarily drawn to scale.

Brief Description of the Drawings

[0117]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 1E

Figure 1F

Figure 1G

Figure 1H

Figure 1I

Figure 1J

Figure 1K

Figure 1L

Figure 2A

Figure 2B

Figure 2C

Figure 2D

Figure 2E

Figure 2F

Figure 2G

Figure 3A

Figure 3B

Figure 3C

Figure 3D

Figure 3E

Figure 3F

Figure 3G

Figure 3H

Figure 3I

Figure 4A

Figure 4B

Figure 4C

Figure 4D

Figure 4E

Figure 4F

Figure 4G

Figure 4H

Figure 4I

Figure 5

Figure 6A

Figure 6B

Figure 6C

Figure 6D

Figure 6E

Figure 6F

Figure 6G

Figure 7

Figure 8A

Figure 8B

Figure 8C

Figure 8D

Figure 8E

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

[0118] Embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. It should be understood that these embodiments are not intended to imply limitations on the scope of the present disclosure, but are described for the purpose of enabling those skilled in the art to better understand and thus implement the present disclosure. References throughout this specification to features, advantages, or similar language should not be construed as indicating that all features and advantages that can be realized with the present disclosure must be in or be part of a single embodiment of the disclosure. Rather, the language referring to the features and advantages is understood to mean that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize that the present disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages that may not be present in all embodiments of the present disclosure may be recognized in some embodiments.

[0119] As used herein, the term "network" refers to a network that complies with any suitable communication standard, such as new radio (NR), long term evolution (LTE), LTE-Advanced, wideband code division multiple access (WCDMA), high speed packet access (HSPA), code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), and other wireless networks. A CDMA network may implement wireless technologies such as Universal Terrestrial Radio Access (UTRA). UTRA includes WCDMA and other variants of CDMA. A TDMA network may implement wireless technologies such as GSM (Global System for Mobile Communications). An OFDMA network may implement wireless technologies such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMA, ad hoc networks, wireless sensor networks, etc. In the following description, the terms "network" and "system" may be used interchangeably. Further, communication between two devices in a network may be carried out in accordance with any suitable communication protocol, including but not limited to communication protocols defined by standards bodies such as 3GPP. For example, the communication protocol may include first generation (1G), 2G, 3G, 4G, 4.5G, 5G communication protocols, and / or any other protocol currently known or to be developed in the future.

[0120] The terms "network device", "network node", or "network function (NF)" refer to any suitable function that can be implemented in a network element (physical or virtual) of a communication network. For example, a network function can be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform, e.g., on a cloud infrastructure. For example, a 5G system (5GS) can include multiple NFs such as an AMF (Access and Mobility Function), an SMF (Session Management Function), an AUSF (Authentication Service Function), a UDM (Unified Data Management), a PCF (Policy Control Function), an AF (Application Function), a NEF (Network Exposure Function), a UPF (User Plane Function), and an NRF (Network Repository Function), a RAN (Radio Access Network), an SCP (Service Communication Proxy), an NWDAF (Network Data Analytics Function), an NSSF (Network Slice Selection Function), an NSSAAF (Network Slice Specific Authentication and Authorization Function), etc.

[0121] The term "terminal device" refers to any end device that can access a communication network and receive services from the communication network. By way of non-limiting example, the terminal device refers to a mobile terminal, a user equipment (UE), or other suitable devices. The UE can be, for example, a subscriber station (SS), a portable subscriber station, a mobile station (MS), or an access terminal (AT). The terminal device includes, but is not limited to, a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and playback device, a mobile phone, a cellular phone, a smartphone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable device, a personal digital assistant (PDA), a portable computer, a desktop computer, a wearable terminal device, an in-vehicle wireless terminal device, a wireless endpoint, a mobile station, a laptop embedded equipment (LEE), a laptop mounted equipment (LME), a USB dongle, a smart device, a wireless customer premise equipment (CPE), etc. In the following description, the terms "terminal device", "terminal", "user equipment", and "UE" may be used interchangeably. By way of example, the terminal device may represent a UE configured for communication according to one or more communication standards published by 3GPP, such as the LTE standard or the NR standard of 3GPP (3rd Generation Partnership Project). The "user equipment" or "UE" as used herein does not necessarily have a "user" in the sense of a human user who owns and / or operates the associated device. In some embodiments, the terminal device may be configured to send and / or receive information without direct human interaction. For example, the terminal device may be designed to send information to the network at a predetermined schedule when triggered by an internal or external event, or in response to a request from the communication network. Alternatively, the UE may represent a device that is intended for sale to, or operation by, a human user, but may not initially be associated with a particular human user.

[0122] As another example, in an Internet of Things (IoT) scenario, a terminal device may represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another terminal device and / or network equipment. In this case, the terminal device may be a machine-to-machine (M2M) device, and an M2M device may sometimes be referred to as a machine type communication (MTC) device in a 3GPP context. As one specific example, the terminal device may be a UE implementing the 3GPP narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices include sensors, metering devices such as power meters, industrial machinery, or household or personal electrical appliances, such as personal wearables like refrigerators, televisions, and clocks. In other scenarios, the terminal device may represent a vehicle or other equipment, and the vehicle or other equipment may be capable of monitoring its operating status and / or reporting on its operating status, or other functions associated with its operation.

[0123] References in this specification to "one embodiment", "an embodiment", "exemplary embodiment", etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one of ordinary skill in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0124] To describe various elements, terms such as "first" and "second" may be used in this specification, but it should be understood that these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, the first element may be referred to as the second element, and similarly, the second element may be referred to as the first element. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed terms.

[0125] The phrase "at least one of A and B" or "at least one of A or B" as used herein should be understood to mean "only A, only B, or both A and B". The phrase "A and / or B" should be understood to mean "only A, only B, or both A and B".

[0126] The technical terms used herein are only for the purpose of describing specific embodiments and do not limit the exemplary embodiments. The singular forms "a", "an", and "the" used herein shall include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises", "comprising", "has", "having", "includes", and / or "including" as used herein specify the presence of the stated features, elements, and / or components, etc., but it should be further understood that they do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0127] It should be noted that these terms used in this specification are only used for the ease of explanation and for distinguishing between nodes, devices, or networks, etc. As technology develops, other terms with similar / same meanings may also be used.

[0128] In the following description and claims, unless otherwise specified, all technical and scientific terms used in this specification shall have the same meaning as commonly understood by those of ordinary skill in the art to which this disclosure pertains.

[0129] The subject matter described in this specification can be implemented in any suitable type of system using any suitable components, but the embodiments disclosed herein are described with respect to a communication system adapted to the exemplary system architectures shown in FIGS. 1B, 1C, and 1D. For simplicity, the system architectures of FIGS. 1B, 1C, and 1D illustrate only some exemplary elements. In practice, the communication system may further include any additional elements suitable for supporting communication between terminal devices or between a wireless device and another communication device such as a landline phone, a service provider, or any other network node or terminal device. The communication system can provide communication and various types of services to one or more terminal devices to facilitate access of the terminal devices to the communication system and / or the use of services provided by or through the communication system.

[0130] Figure 1B shows the 5G system architecture for multicast and broadcast services, which is the same as Figure 5.1-1 in 3GPP TS23.247 V.17.2.0. Figure 1C shows the 5G system architecture for multicast and broadcast services in reference point representation, which is the same as Figure 5.1-2 in 3GPP TS23.247 V.17.2.0. The 5G MBS system architecture may include functional entities such as PCF (Policy Control Function), MB-SMF (Multicast / Broadcast Session Management Function), SMF (Session Management Function), MB-UPF (Multicast / Broadcast User Plane Function), UPF (User Plane Function), AMF (Access and Mobility Function), NG-RAN (Next Generation Radio Access Network), UE (User Equipment), AF / AS (Application Function / Application Server), NEF (Network Exposure Function), MBSF (Multicast / Broadcast Service Function), MBSTF (Multicast / Broadcast Service Transport Function), UDM (Unified Data Management), UDR (Unified Data Repository), NRF (Network Repository Function), etc. These functional entities are described in Section 5.3.2 of 3GPP TS23.247 V.17.2.0.

[0131] MBSF is optional and can be collocated with NEF or AF / AS, and MBSTF is an optional network function.

[0132] The existing service-based interfaces of Nnrf, Nudm, and Nsmf are extended to support MBS. The existing service-based interfaces of Npcf and Nnef are extended to support MBS.

[0133] The MBS-capable AF uses either Nmbsf or Nnef to interact with MBSF.

[0134] SMF and MB-SMF can be collocated or deployed separately.

[0135] The MBS system architecture may include the following reference points.

[0136] N3mb: Reference point between (R)AN and MB-UPF.

[0137] N4mb: Reference point between MB-SMF and MB-UPF.

[0138] N6mb: Reference point between MB-UPF and AF / AS.

[0139] N7mb: Reference point between MB-SMF and PCF.

[0140] N11mb: Reference point between AMF and MB-SMF.

[0141] N16mb: Reference point between SMF and MB-SMF.

[0142] N19mb: Reference point between UPF and MB-UPF.

[0143] N29mb: Reference point between MB-SMF and NEF.

[0144] Nmb1: Reference point between MB-SMF and MBSF.

[0145] Nmb2: Reference point between MBSF and MBSTF.

[0146] Nmb5: Reference point between MBSF and NEF.

[0147] Nmb8: Reference point between MBSTF and AF.

[0148] Nmb9: Reference point between MB-UPF and MBSTF.

[0149] Nmb10: Reference point between MBSF and AF.

[0150] Nmb12: Reference point between MBSF and PCF.

[0151] Nmb13: Reference point between MB-SMF and AF.

[0152] The existing reference points of N1, N2, N4, N10, N11, N30 and N33 are extended to support MBS.

[0153] In terms of their functions, Nmb13, N29mb and Nmb1 are equivalent, Nmb5 and Nmb10 are equivalent, and Nmb9 and N6mb are equivalent.

[0154] Figure 1D shows the MBS-eMBMS interworking system architecture in the service layer, which is the same as Figure 5.2-1 of 3GPP TS23.247 V17.2.0.

[0155] The interworking between MBS and eMBMS (evolved MBMS) in the service layer function is applicable when the same multicast / broadcast service is provided via eMBMS and MBS. Figure 1D illustrates the system architecture for the interworking between E-UTRAN / EPC eMBMS and MBS in the service layer with collocated BM-SC and MBSF / MBSTF functions. E-UTRAN represents the Evolved Universal Terrestrial Radio Access Network. EPC represents the Evolved Packet Core.

[0156] BM-SC + MBSF / MBSTF exposes common Nmb5 / Nmb10 / xMB-C / MB2-C and Nmb8 / xMB-U / MB2-U reference points to the NEF and / or AF / AS. A common TMGI is used for the AF / AS. The TMGI is also used as an identifier for transport on E-UTRAN / EPC.

[0157] Note: MB2-C / U is both a legacy reference point and a 5GS reference point.

[0158] Figure 1E shows a flowchart of an MBS session update without policy and charging control (PCC), which is the same as Figure 7.1.1.6-1 in 3GPP TS 23.247 V17.2.0.

[0159] The following italicized content is a copy of Section 7.1.1.6 of 3GPP TS 23.247 V17.2.0.

[0160] This procedure is used by the AF to update the MBS service area and / or update the QoS of the MBS session. Updating the QoS of the MBS session may lead to the addition of one or more new MBS QoS flows. The procedure applies to both multicast and broadcast communications, unless otherwise specified.

[0161] For local multicast services and location-dependent multicast services, the AF may perform service notification to the UE to update the MBS service area either before the MBS session update procedure is initiated or after the MBS session update procedure is completed.

[0162] 1. The AF of the content provider initiates an MBS session update to the NEF / MBSF, for example, to update the MBS service area and / or service requirements, or to activate or deactivate an MBS session. The AF may provide updated information for the MBS session (identified by the MBS session ID) by sending an MBS session update request ([MBS session ID], MBS information, AF identifier). The MBS information may include service requirements, MBS service area information, and media information. Service requirement adjustment may lead to the addition of one or more new MBS QoS flows, the removal of one or more existing MBS QoS flows, or the update of one or more existing MBS QoS flows.

[0163] 2. The NEF checks the permission of the AF.

[0164] 3. The NEF / MBSF forwards the MBS session update request to the MB-SMF.

[0165] 4. The MB-SMF locally derives the updated QoS parameters.

[0166] 5 - 6. The MB-SMF may need to update the MB-UPF if, for example, a new MBS QoS flow should be created or an existing MBS QoS flow should be deleted.

[0167] 7. In broadcast communication, the MB-SMF continues the procedure with the AMF and the NG-RAN as specified in Section 7.3.3. In multicast communication, the MB-SMF continues the procedure with the AMF and the NG-RAN as specified in Section 7.2.5 (in the case of service activation / deactivation) and Section 7.2.6 (in the case of QoS update and service area update).

[0168] 8. When the MBS service area is updated, the MB-SMF stores the new service area in its profile at the NRF.

[0169] 9. The MB-SMF responds to MBS session updates.

[0170] 10. The NEF / MBSF responds to MBS session updates.

[0171] Figure 1F shows a flowchart of MBS session update with PCC, which is the same as Figure 7.1.1.7-1 in 3GPP TS23.247 V17.2.0.

[0172] The following italicized content is a copy of Section 7.1.1.7 of 3GPP TS23.247 V17.2.0.

[0173] For local multicast services and location-dependent multicast services, the AF may perform service announcements to the UE to update the MBS service area before the MBS session update procedure is started or after the MBS session update procedure is completed.

[0174] 1 - 2. The same as those in Figure 7.1.1.6-1.

[0175] Steps 3 - 6 apply to the update of the MBS service area and / or the activation / deactivation of the MBS session.

[0176] 3. The NEF / MBSF forwards the MBS session update request to the MB-SMF and removes updates not related to the MBS service area and / or the activation / deactivation of the MBS session.

[0177] 4. In broadcast communication, the MB-SMF continues procedures towards the AMF and the NG-RAN as specified in section 7.3.3. In multicast communication, the MB-SMF continues procedures towards the AMF and the NG-RAN as specified in (for service activation / deactivation) section 7.2.5, and (for service area update) section 7.2.x.

[0178] 5. If the MBS service area is updated, the MB-SMF stores the new service area in its profile at the NRF.

[0179] 6. The MB-SMF responds to MBS session updates.

[0180] For other updates of service description and QoS related updates, there are two alternatives.

[0181] In alternative A, the MB-SMF is the Npcf_MBSPolicy Authorization_Update service operation consumer. Steps 7, 8, 14, and 15 apply.

[0182] In alternative B, the NEF is the Npcf_MBSPolicy Authorization_Update service operation consumer. Steps 12 and 16 apply.

[0183] Steps 10 to 13 and 27 are executed for both alternative A and alternative B.

[0184] 7. [Optional, alternative A] The NEF / MBSF forwards the MBS session update request to the MB-SMF.

[0185] 8. [Optional, alternative A] The MB-SMF sends an Npcf_MBSPolicy Authorization_Update request to the PCF together with the updated service requirements. The PCF determines whether the request is permitted.

[0186] 9. [Optional, alternative B] The NEF / MBSF updates the MBS policy authorization for the MBS session at the PCF by sending an Npcf_MBSPolicyAuthorization_Update request message (MBS session ID, service requirements), provides the input received from the AF, and removes updates related to the MBS service area and / or MBS session activation / deactivation.

[0187] 10. Based on the input received in step 9 or 10, the PCF may provide the updated policy rules to the MB-SMF by issuing an Npcf_MBSPolicyControl_UpdateNotify request message containing the updated policy information for the MBS session.

[0188] 11 - 12. The same as steps 5 - 6 in Figure 7.1.1.6-1.

[0189] 13. The MB-SMF sends an Npcf_MBSPolicyControl_UpdateNotify response to the PCF.

[0190] 14. [Optional, alternative A] The PCF sends an Npcf_MBSPolicyAuthorization_Update response to the MB-SMF.

[0191] 15. [Optional, alternative A] The MB-SMF responds to the MBS session update.

[0192] 16. [Optional, alternative B] The PCF sends an Npcf_MBSPolicyAuthorization_Update response to the NEF / MBSF.

[0193] 17. In broadcast communication, the MB-SMF continues the procedure with the AMF and the NG-RAN as specified in clause 7.3.3. In multicast communication, the MB-SMF continues the procedure with the AMF and the NG-RAN as specified in clause 7.2.6 (in case of QoS update).

[0194] 18. Same as step 10 in Figure 7.1.1.6-1.

[0195] Figure 1G shows a flowchart of MBS session update for broadcast, which is the same as Figure 7.3.3-1 in 3GPP TS23.247 V17.2.0.

[0196] The following italicized content is a copy of clause 7.3.3 of 3GPP TS23.247 V17.2.0.

[0197] MBS session update for broadcast is used by the AF to update the broadcast area or service requirements of the MBS session, which may lead to the addition of (one or more) new MBS QoS flows, the removal of (one or more) existing MBS QoS flows, or the update of (one or more) existing MBS QoS flows.

[0198] 1. The AF starts the MBS session update procedure by sending an Nnef_MBSSession_Update request to the NEF / MBSF together with the TMGI. The AF may adjust the service requirements and / or the broadcast area. Adjustment of the service requirements may lead to the addition of (one or more) new MBS QoS flows, the removal of (one or more) existing MBS QoS flows, or the update of (one or more) existing MBS QoS flows.

[0199] 2. The MB-SMF sends the Namf_MBSBroadcast_ContextUpdate request (TMGI, N2 SM information ([5G QoS profile]), [updated MBS service area]) to the AMF. If the broadcast area is updated, the MB-SMF may use the NRF to discover one or more AMFs based on the new broadcast area and select one or more appropriate AMFs. The MB-SMF may include the maximum response time in the request.

[0200] In response to a change in the MBS service area, the MB-SMF may send Namf_MBSBroadcast_ContextCreate to some AMFs in the new MBS service area and Namf_MBSBroadcast_ContextRelease to some other AMFs in the old MBS service area.

[0201] 3. The AMF sends an MBS session resource update to the NG-RAN together with the TMGI, the updated 5G QoS profile, and the updated MBS service area.

[0202] In response to a change in the MBS service area, the AMF may send an MBS session resource setup to some NG-RANs in the new MBS service area (see section 7.3.1) and an MBS session resource release to some other NG-RANs in the old MBS service area.

[0203] 4. The NG-RAN updates the MBS session context.

[0204] 5. The NG-RAN reports the success of the update of the MBS session resources (which may include multiple MBS QoS flows) by sending the (one or more) MBS session resource update response (TMGI, N2 SM information ([N3mb DL tunnel information])) message to the AMF. The N3mb DL tunnel information is applicable for point-to-point transport between the MB-UPF and the NG-RAN and is available only when the NG-RAN wants the transport to be changed. The NG-RAN should be ready to receive using the N3mb DL tunnel. For further details, refer to TS38.413

[15] .

[0205] 6. The AMF sends the Namf_MBSBraodcast_ContextUpdate response to the MB-SMF. If the AMF receives the NG-RAN response from all the (one or more) involved NG-RANs, the AMF should include an indication of the completion of the operation in all the NG-RANs.

[0206] 7. The NG-RAN updates the MBS session. This is done in parallel with steps 5 to 6.

[0207] 8. Another NG-RAN may report the success of the update of the MBS session resources (which may include multiple MBS QoS flows) by sending the MBS session resource update response (TMGI, N2 SM information ([N3mb DL tunnel information])) message after the AMF transfers the Namf_MBSBroadcst_ContextUpdate response () to the MB-SMF. The N3mb DL tunnel information is applicable for point-to-point transport between the MB-UPF and the NG-RAN and is available only when the NG-RAN wants the transport to be changed. The NG-RAN should be ready to receive using the N3mb DL tunnel. For further details, refer to TS38.413

[15] .

[0208] 9. The AMF forwards the Namf_MBSBroadcast_ContextStatusNotify request() to the MB-SMF. When the AMF has received responses from all NG-RAN nodes, the AMF should include an indication of the completion of the operations in all NG-RANs. If the AMF does not receive responses from all NG-RAN nodes before the maximum response time has elapsed since the reception of the Namf_MBSBroadcast_ContextUpdate request, the AMF should forward a Namf_MBSBroadcast_ContextStatusNotify request() indicating partial success or failure.

[0209] Figure 1H shows a flowchart of MBS session deletion without PCC, which is the same as Figure 7.1.1.4-1 in 3GPP TS23.247 V17.2.0.

[0210] The following italicized content is a copy of Section 7.1.1.4 of 3GPP TS23.247 V17.2.0.

[0211] This procedure is used by the AF to delete an MBS session. This procedure may also include the release of the TMGI allocation. The procedure applies to both multicast and broadcast communications, unless otherwise specified. This procedure releases reserved resources in both the 5GC and the NG-RAN.

[0212] 1. The AF of the content provider may request to delete an MBS session (MBS session ID).

[0213] 2 / 3. If the MBSTF is inserted into the user plane, the MBSF requests the MBSTF to release the user plane resources.

[0214] 4. The NEF / MBSF requests the MB-SMF to delete the resources for the MBS session.

[0215] 5. In a broadcast session, the MB-SMF triggers resource release to the AMF as specified in section 7.3.2. In a multicast session, the MB-SMF triggers resource release to the SMF as specified in section 7.2.2.3.

[0216] 6 / 7. The MB-SMF requests the MB-UPF to release user plane resources.

[0217] 8. [Conditional] When an MBS session is created and the MB-SMF sets the MBS session ID in the profile, the MB-SMF updates its NF profile in the NRF to release the MBS session ID.

[0218] 9. The MB-SMF responds to the NEF / MBSF.

[0219] 10. The NEF / MBSF responds to the AF.

[0220] 11. [Optional] The AF requests the NEF / MBSF to deallocate (one or more) TMGIs.

[0221] 12. [Conditional on step 11] The NEF / MBSF forwards the request to deallocate (one or more) TMGIs to the MB-SMF.

[0222] 13. [Conditional on step 12] The MB-SMF responds to the NEF or MBSF by sending a de-allocate TMGI Response message.

[0223] 14. [Conditional on step 13] The NEF or MBSF forwards the de-allocate TMGI Response message to the AF.

[0224] Figure 1I shows a flowchart of MBS session deletion with PCC, which is the same as Figure 7.1.1.5-1 in 3GPP TS23.247 V17.2.0.

[0225] The following italicized content is a copy of Section 7.1.1.5-1 in 3GPP TS23.247 V17.2.0.

[0226] This procedure is used by the AF to release the MBS session. This procedure may also include the release of TMGI allocation. The procedure applies to both multicast and broadcast communications unless otherwise specified. This procedure releases reserved resources in both the 5GC and the NG-RAN.

[0227] 1 - 4. The same as those in Figure 7.1.1.4-1.

[0228] There are two alternatives to start the policy permission service operation.

[0229] If the MB-SMF is the Npcf_MBSPolicy Authorization service consumer, i.e., alternative A in Section 7.1.1.3, step 5 is executed.

[0230] If the NEF is the Npcf_MBSPolicy Authorization service consumer, i.e., alternative B in Section 7.1.1.3, step 6 is executed.

[0231] 5. (Alternative A) The MB-SMF sends an NMBSPolicyAuthorization_Delete request to the PCF that handles the policy of the MBS session.

[0232] 6. (Alternative B) The NEF / MBSF sends an NMBSPolicyAuthorization_Delete request to the PCF that handles the policy of the MBS session.

[0233] 7. The PCF sends an Npcf_MBSPolicyControl_UpdateNotify request to the MB-SMF to release the MBS policy association. The MB-SMF sends a positive response to the request.

[0234] 8 - 11. The same as steps 5 - 8 in Figure 7.1.1.4-1.

[0235] 12. The MB-SMF sends an Npcf_MBSPolicyControl_Delete request to request the deletion of the SM policy association with the PCF.

[0236] 13. The PCF deregisters in the BSF that it is handling the MBS session.

[0237] 14. The MB-SMF sends an Nmbsmf_MBSSession_Delete response to the NEF / MBSF.

[0238] 15 - 19. The same as steps 10 - 14 in Figure 7.1.1.4-1.

[0239] Figure 1J shows a flowchart of the MBS session release for broadcast, which is the same as Figure 7.3.2-1 in 3GPP TS23.247 V17.2.0.

[0240] The following italicized content is a copy of Section 7.3.2 of 3GPP TS23.247 V17.2.0.

[0241] The MBS session release for broadcast follows the MBS session deletion (e.g., TMGI allocation release and MBS session deletion), and thus the resources for shared MBS delivery are released. The AF can stop the MBS session while keeping the TMGI allocated.

[0242] 1. AF / AS may stop the media stream before sending the MBS session release request (TMGI) message to the 3GPP network.

[0243] 2. AF / AS executes the MBS session deletion procedure (steps 1 to 10 in Figure 7.1.1.4-1 or steps 1 to 13 in Figure 7.1.1.5-1) to request the release of the MBS session.

[0244] 3. MB-SMF sends a Namf_MBSBroadcast_ContextRelease request (TMGI) to the (one or more) AMF(s) that were involved in the MBS session.

[0245] 4. The AMF sends an N2 message to all the RAN nodes it was involved with to release the MBS session. If an NG-RAN node receives multiple N2 messages for releasing the MBS session for the same TMGI (e.g., from several AMFs to which the NG-RAN is connected), the NG-RAN executes steps 5 and 6 only once.

[0246] 5. NG-RAN stops PTM transmission.

[0247] 6. If N3mb multicast transport is used, the NG-RAN sends a Leave message (LL SSM) to stop the media stream to this NG-RAN node. If N3mb point-to-point transport is used, the NG-RAN releases the NG-RAN's DL N3mb tunnel information. The NG-RAN deletes the NG-RAN's MBS session context.

[0248] 7. The NG-RAN reports the success of releasing the resources for the MBS session by sending a (one or more) MBS session resource release response (TMGI) message(s) to the (one or more) AMF(s).

[0249] 8. The AMF sends the Namf_MBSBroadcast_ContextRelease response (TMGI) to the MB-SMF.

[0250] 9. The AF may initiate the TMGI allocation release procedure (steps 11 to 14 in Figure 7.1.1.4-1 or steps 14 to 17 in Figure 7.1.1.5-1).

[0251] 3GPP TR23.700-47 V0.2.0 includes Solution #12 for group message delivery over MBS broadcast.

[0252] The following italicized content is a copy of section 6.12 of 3GPP TR23.700-47 V0.2.0.

[0253] 6.12 Solution #12: Group message delivery

[0254] 6.12.1 Introduction

[0255] This solution addresses the following aspects in Key Issue #4, namely whether and how to extend the MBS function to provide a group message delivery similar to that available in eMBMS.

[0256] 6.12.2 Functional description

[0257] This solution describes a method for NEF-based group message delivery over MBS that is comparable to SCEF-based group message delivery over MBMS.

[0258] This solution utilizes the object delivery method in the MBSTF specified in TS26.502

[11] for group message delivery via MBS. The object delivery method in the MBSTF is equivalent to the file delivery method in eMBMS. The object delivery method can benefit from application layer forward error correction (AL-FEC) to achieve reliable delivery, which is essential for group message delivery.

[0259] The NEF is responsible for handling the group message delivery request from the AF. The NEF converts the group message into a file and determines the metadata information of the file. In the control plane, the NEF performs application service provisioning including creating an MBS session and starting an MBS session to trigger broadcast to the 5GC and NR, creating an MBS user service and creating an MBS user data import session. In the user plane, the NEF is responsible for importing the file into the MBSTF so that the MBSTF can deliver the file to the UE via 5GC shared traffic delivery and NR broadcast.

[0260] Figure 1K shows a flowchart of group message delivery via MBS broadcast, which is the same as Figure 6.12.3.2-1 in 3GPP TR23.700-47 V0.2.0.

[0261] The following italicized content is a copy of Sections 6.12.3.2, 6.12.3.3, and 6.12.3.4 of 3GPP TR23.700-47 V0.2.0.

[0262] 1. The AF sends a group message request, which includes the group message payload, the MBS service area, the group message delivery start time, and the stop time, to the NEF.

[0263] Editor's note: Other parameters in the group message request are FFS.

[0264] 2. The NEF checks the permission of the AF. When geographical area information or urban address information is provided by the AF as the MBS service area, the NEF converts the MBS service area into a cell ID list or a TAI list.

[0265] Note 2: The NEF is obliged to distribute group messages.

[0266] 3. The NEF converts the group message payload into a file and determines the metadata information of the file (such as the file URL, etc.).

[0267] If application service provisioning is not performed, steps 4 to 8 need to be executed. Otherwise, steps 4 to 8 can be skipped.

[0268] 4. The NEF performs application service provisioning for the MBSF as specified in step 1 of section 5.2 of TS26.502

[11] , which includes calling Nmbsf_MBSUserService_Create and Nmbsf_MBSUserDataIngestSession_Create on the MBSF.

[0269] The target service area is set to the MBS service area.

[0270] The distribution method is set to the object distribution method used for file distribution.

[0271] The distribution operation mode is set to a file or a carousel according to the judgment of the NEF.

[0272] The object acquisition method is set to push or pull according to the judgment of the NEF.

[0273] 5. The MBSF performs MBS session establishment as specified in section 7.1.1.2 or section 7.1.1.3 of TS 23.247 [4].

[0274] 6. The MBSF performs distribution session provisioning as specified in step 2 of section 5.2 of TS 26.502

[11] . The MBSF calls Nmbstf_MBSDistributionSession_Create on the MBSTF and passes the parameters of the MBS distribution session received in step 4 to the MBSTF.

[0275] 7. The MB-SMF initiates the start of the MBS session for the broadcast procedure as specified in steps 2 to 9 of section 7.3.1 of TS 23.247 [4].

[0276] 8. When the MBSF performs service notification, the MBSF initiates the MBS user service notification as specified in step 3 of section 5.2 of TS 26.502

[11] . The application may receive appropriate information from the MBS client through the MBS-6 API (see TS 26.502

[11] ).

[0277] Editor's note: How the MBSF sends service notification information to the NEF acting as the AF depends on TS 26.502 defined by SA4.

[0278] 9. The NEF sends the group message response to the AF. When the AF performs service notification, the service notification information including file metadata may optionally be included in the group message response.

[0279] 10. When the AF needs to perform service notification, the AF sends the application service notification to the UE as specified in step 4 of section 5.2 of TS 26.502

[11] .

[0280] 11. The NEF performs user data import for the MBSTF as specified in step 5 of section 5.2 of TS 26.502

[11] . The NEF may push a file to the MBSTF or may let the MBSTF pull the file from the NEF.

[0281] 12. The MBSTF performs packetization and optionally FEC encoding as specified in section 4.3.3.2 of TS 26.502

[11] .

[0282] 13. The MBSTF distributes packets to the MB-UPF and to the NG-RAN for delivery to the UE, and distributes NG-RAN broadcasts to the UE, as specified in steps 13 to 15 of section 7.3.1 of TS 23.247 [4].

[0283] 14. Based on the service notification information received in step 8 or step 10, the UE uses the MBS client to receive packets, perform FEC decoding if necessary to restore the file, and obtain group messages from the file, as specified in section 4.3.5 of TS 26.502

[11] . The MBS client can expose the file to applications in the UE using the MBS-7 API (see TS 26.502

[11] ).

[0284] 6.12.3.3 Modification of Previously Submitted Group Messages

[0285] Editor's Note: How the modification of previously submitted group messages can be implemented is FFS.

[0286] 6.12.4 Impact on Services, Entities and Interfaces.

[0287] The functional entities defined in section 5.3.2 of TS23.247 [4] and section 6.2 of TS23.501 [2] are reused, except for the following additions.

[0288] NEF:

[0289] - Support the group message delivery interface to AF and optionally include service notification information in the group message delivery response to AF.

[0290] - Convert the group message to a file and determine the file's metadata information.

[0291] - Create an MBS user service and MBS user data import session to MBSF.

[0292] - Import the file to MBSTF.

[0293] Editor's note: The impact of the addition is FFS.

[0294] Figure 1L shows a flowchart of the modification of a previously submitted group message, which is the same as Figure 5.5.2-1 of 3GPP TS23.682 V17.2.0.

[0295] The following italicized content is a copy of section 5.5.2 of 3GPP TS23.682 V17.2.0.

[0296] 0. The precondition for this flow is the successful completion of step 11 from section 5.5.1.

[0297] 1. Application level interaction may be applied for a specific group of devices to retrieve relevant MBMS service information, e.g., TMGI in the case of MB2, start time, etc., or ServiceId in the case of xMB. When the application receives the ServiceId through the application level interaction, the application can activate the reception using the MBMS device API (see TS26.347

[42] ). The application level interaction between the UE and the SCS / AS is outside the scope of this specification.

[0298] 2. The SCS / AS determines that a modification of a previously received group message delivery request is required. The SCS / AS sends a group message modification request (TLTRI, requested action, message delivery start time, message delivery stop time (xMB only), optional, external group identifier, SCS identifier, TMGI (MB2 only), group message payload, location information, accuracy) message to the SCEF. In the case of xMB, the SCEF uses the external group identifier to identify the associated MBMS service. The requested action is set to either "Modify" or "Cancel". "Modify" indicates that the request is for modifying the transaction identified by the TLTRI. "Cancel" indicates that the request is for canceling the transaction identified by the TLTRI. When set to "Modify", the remaining parameters except the message delivery start time are optional and are only included if they are different from those in step 6 from section 5.5.1. When set to "Cancel", no other parameters are included.

[0299] 3. The SCEF uses the TLTRI to identify the context of the group message delivery requests that were accepted before being executed in section 5.5.1. If the associated transaction cannot be found, or if the transaction is found but step 13a from section 5.5.1 has been completed, step 4 is executed with an appropriate cause value and the flow stops at this step. In other cases, the flow proceeds.

[0300] 4. If the requested action is set to "cancel", in order to release the associated MBMS resources, when MB2 is used, the mechanism defined in section 5.1.2.3.3 of TS23.468

[30] is used by the SCEF, and when xMB is used, the mechanism defined in section 5.4.5 of TS26.348

[46] is executed. If the requested action is set to "modify", when MB2 is used, in order to modify the associated MBMS resources, the mechanism defined in section 5.1.2.4 of TS23.468

[30] is used by the SCEF, and when xMB is used, the mechanism defined in section 5.4.4 of TS26.348

[46] is used with the following changes.

[0301] - In step 1 of this procedure, the SCEF acting as the GCS AS (when MB2 is used) or the content provider (when xMB is used) may include the location information from step 2. If the location information is not provided in step 2 of this procedure, the SCEF uses, based on the local settings, either a list of MBMS service area identification information, or a list of cell IDs, or both, as the MBMS broadcast area.

[0302] - In step 2 of this procedure, the BM-SC may map the (one or more) city addresses (if provided) and / or the (one or more) geographical areas (if provided) of the location information to the MBMS service area identification information that receives the operator policy.

[0303] 5. If the requested action is set to "cancel", the SCEF sends a group message modification response (cause) message with an appropriate cause value to the SCS / AS according to whether the cancellation is accepted, and the flow stops at this step. If the requested action is set to "modify", the SCEF sends a group message modification response (cause, TMGI, acceptance status) message to the SCS / AS to indicate whether the requested modification is accepted. The use of parameters is the same as in step 11 of section 5.5.1.

[0304] 6. Steps 12 to 14 of section 5.5.1 are executed.

[0305] 3GPP TS26.348 V16.3.0 specifies the user plane for file delivery on the xMB reference point as follows.

[0306] 5.5.2 File distribution

[0307] Provisioning files for file distribution shall use one of the following options.

[0308] - WebDAV as described in RFC4918 [7] over HTTP over TLS. The content provider shall provide an authorized access token with every HTTPS transaction.

[0309] - HTTP over TLS for file retrieval. The BM-SC shall use at least HTTP version 1.1.

[0310] The content provider shall ensure that the content is available at the BM-SC before its scheduled transmission time. For example, in the case of DASH segments, the segments shall be pushed to the BM-SC taking into account the timing requirements indicated in the MPD.

[0311] Also, for all files declared as part of the file list of a session, all declared files shall be available before their indicated availability time or, if not provided, before the session start.

[0312] As an alternative to providing the properties of the file-based service and the transport-related requirements for delivery over the MBMS bearer service via the "file list" property of the "session" resource in subclause 5.4.6, the content provider may elect to convey the same information via a file delivery manifest as described in clause 5.6.

[0313] As described above, there are several problems with existing group message modification and cancellation resolution. To overcome or mitigate at least one of the above problems or other problems, embodiments of the present disclosure propose an improved solution for group message modification and cancellation.

[0314] In one embodiment, the solution may cover three deployments, namely, · Group message modification using MBMS in EPS (Evolved Packet System), also referred to as "eMBMS", · Group message modification using MBS in 5GS, · Group message modification using interworking between MBS and eMBMS may cover.

[0315] In one embodiment corresponding to the above deployment, AF sends group message delivery messages to SCEF, NEF, or SCEF+NEF (combined SCEF and NEF), respectively.

[0316] In one embodiment, in the MBS deployment in 5GS, when a group message is modified, the system may behave as follows.

[0317] 1-1 NEF converts the group message payload into a file with the same file URI (Uniform Resource Identifier) as the previous group message.

[0318] 1-2 NEF distributes the updated file to MBSTF via two options.

[0319] Option 1: NEF encapsulates the group message into a file. · Option 1.1: NEF pushes the file to MBSTF via WebDAV (Web-based Distributed Authoring and Versioning) ingestion. · Option 1.2: NEF instructs MBSF to update the file. MBSF sends it to MBSTF, and MBSTF pulls the file from NEF via (one or more) HTTP. It is possible for NEF to upload the file to an HTTP (Hypertext Transfer Protocol) server and for MBSTF to download it from the HTTP server.

[0320] Option 2: NEF sends the updated group message to MBSF (e.g., during a group message modification request). MBSF sends the updated group message to MBSTF.

[0321] 1-3 MBSTF receives the updated file, encodes the file (including FEC encoding), and distributes the packetized file to the MB-UPF (ROUTE or FLUTE). Then, the 5GC can distribute the packetized file to the UE on the MBS broadcast via the NG-RAN. ROUTE indicates real-time transport object distribution on unidirectional transport. FLUTE indicates file distribution on unidirectional transport. FEC indicates forward error correction.

[0322] In one embodiment, in an eMBMS deployment, when a group message is modified, the system may behave as follows.

[0323] Same as 1-1 above, except that SCEF is used instead of NEF.

[0324] Same as 1-2 above, except that SCEF is used instead of NEF and BM-SC is used instead of MBSF and MBSTF.

[0325] BM-SC encodes the file (including FEC encoding) and distributes the packetized file to the E-UTRAN via the MBMS-GW (FLUTE). The E-UTRAN broadcasts on the Uu.

[0326] In one embodiment, in a deployment with interworking between MBS and eMBMS compared to the MBS deployment in 5GS, when a group message is modified,

[0327] Same as 1-1 above, except that NEF+SCEF is used instead of NEF.

[0328] Same as 1-2 above, except that NEF+SCEF is used instead of NEF and BM-SC+MBSF+MBSTF is used instead of MBSF and MBSTF.

[0329] BM-SC + MBSF + MBSTF utilizes the "file delivery" function to encode the updated files (including FEC encoding). The packetized files are delivered separately from BM-SC + MBSF + MBSTF, via the EPC to the E-UTRAN, and via the 5GC to the NG-RAN.

[0330] In one embodiment, in the MBS deployment in 5GS, when a group message is cancelled, the system behaves as follows.

[0331] 2-1 The NEF instructs the MBSTF to cancel via two options.

[0332] Option 1: The NEF instructs the MBSF to cancel the file. The MBSF sends it to the MBSTF.

[0333] Option 2: The NEF sends an HTTP delete to the MBSTF.

[0334] 2-2 The MBSTF stops file delivery and, if necessary, notifies the MBS client regarding the cancellation.

[0335] 2-3 The NEF abandons the MBS user data import session for the MBSF. The MBSF abandons the MBS distribution session for the MBSTF and triggers the MBS session deletion in the 5GC and NR.

[0336] In one embodiment, in the eMBMS deployment, when a group message is cancelled, the system behaves as follows.

[0337] Same as 2-1 above, except that the SCEF is used instead of the NEF, and the BM-SC is used instead of the MBSF and MBSTF.

[0338] The same as 2-2 above, except that the BM-SC stops file delivery and notifies the MBMS client either via in-band fragmentation delivery or out-of-band.

[0339] The same as 2-3 above, except that the BM-SC stops the MBMS session in the EPC and LTE.

[0340] In one embodiment, in a deployment with interworking between MBS and eMBMS, compared to the MBS deployment in 5GS, when a group message is cancelled,

[0341] The same as 2-1 above, except that NEF+SCEF is used instead of the NEF.

[0342] The same as 2-2 above, except that BM-SC+MBSF+MBSTF stops file delivery and separately notifies the MBMS client and the MBS client.

[0343] The same as 2-3 above, except that BM-SC+MBSF+MBSTF stops the MBMS session in the EPC and LTE, and stops the MBS session in the 5GC and NR.

[0344] FIG. 2A shows a flowchart of a method according to an embodiment of the present disclosure, which may be implemented by an apparatus implemented in / acting as a public node or communicatively coupled to a public node. Accordingly, the apparatus may provide means for achieving various parts of method 200, as well as means for achieving other processes together with other components.

[0345] In block 202, the public node may receive a group message request from the application node.

[0346] The application node can be any suitable node that can provide similar or the same functions as the AF or, as described in 3GPP TS23.501 V17.1.1, the application server (AS) or the service capability server (SCS), or as described in 3GPP TS23.682 V17.2.0. For example, the application node can be a content provider or a multicast source or a broadcast source.

[0347] In one embodiment, the application node includes an AF as described in 3GPP TS23.501 V17.1.1.

[0348] In one embodiment, the application node includes an AS / SCS as described in 3GPP TS23.682 V17.2.0.

[0349] The public node can be any suitable network function that can provide similar or the same functions as the NEF, SCEF, combined SCEF and NEF, as described in 3GPP TS23.501 V17.1.1 and 3GPP TS23.682 V17.2.0.

[0350] In one embodiment, the public node includes at least one of a network exposure function (NEF), a service capability exposure function (SCEF), or a combined NEF and SCEF.

[0351] The group message request can be any suitable message that can be used to modify or cancel a group message delivery transaction.

[0352] In one embodiment, the group message request can include a group message modification request with a requested action set to modify or cancel, as described in 3GPP TS23.682 V17.2.0.

[0353] In one embodiment, the group message request may include a group message modification request or a group message cancellation request.

[0354] The group message request may include any suitable parameters. For example, the group message request may include a requested action, a group message payload, an MBS service area, a group message delivery start time, a stop time, an external group identifier, etc. A public node such as the NEF may use the external group identifier to identify the associated MBS service. The requested action is set to either "modify" or "cancel". "Modify" indicates that the request is for modifying a group message delivery transaction. "Cancel" indicates that the request is for canceling a group message delivery transaction.

[0355] In block 204, when the group message request is for modifying the group message delivery (or indicates modifying the group message delivery) and includes a group message payload, the public node may convert the group message payload into a file. For example, a public node such as the NEF converts the group message payload (or group message) into a file. A public node such as the NEF determines the metadata information of the file (such as a file URL or a file URI, etc.). The file can refer to a file object or an object under the context of a service provided by the MBSF and / or MBSTF.

[0356] In one embodiment, the determined file metadata (such as in a group message delivery procedure) is used as the metadata information of the file. For example, the file metadata of the original file (such as the file to be delivered or the current file being delivered) may be used as the metadata information of the file.

[0357] In one embodiment, the determined file metadata includes a file Uniform Resource Locator (URL) and / or a file Uniform Resource Identifier (URI). The file URI or URL can be used to identify the file. The file URI or URL can be used by the BM-SC / MBSTF / UE to download the file.

[0358] In block 206, the public node may send the file to a second broadcast multicast node.

[0359] In one embodiment, the public node may send the file to a first broadcast multicast node.

[0360] The first broadcast multicast node can be any suitable network function that provides a function similar to or the same as a Broadcast Multicast Service Center (BM-SC) or a combined BM-SC, Multicast / Broadcast Service Function (MBSF), and Multicast / Broadcast Service Transport Function (MBSTF) as described in 3GPP TS23.247 V17.2.0 or 3GPP TS23.682 V17.2.0.

[0361] In one embodiment, the first broadcast multicast node includes at least one of a BM-SC, or a combined BM-SC, MBSF, and MBSTF.

[0362] The second broadcast multicast node can be any suitable network function that provides a function similar to or the same as an MBSTF as described in 3GPP TS23.247 V17.2.0.

[0363] In one embodiment, the second broadcast multicast node includes an MBSTF.

[0364] The publishing node may send the file to the first broadcast multicast node or the second broadcast multicast node in various ways, and the present disclosure has no restrictions thereon. For example, the publishing node may send the file directly or via another network node to the first broadcast multicast node or the second broadcast multicast node. The publishing node may send the file in response to a request from the first broadcast multicast node or the second broadcast multicast node to the first broadcast multicast node or the second broadcast multicast node. The publishing node may push the file to the first broadcast multicast node or the second broadcast multicast node.

[0365] FIG. 2B shows a flowchart of a method according to another embodiment of the present disclosure that may be implemented in or as a publishing node or by an apparatus communicatively coupled to the publishing node. Thus, the apparatus may provide means for achieving various parts of method 210, as well as means for achieving other processes along with other components. For some of the parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0366] In this embodiment, when the capture mode or object acquisition method is set to pull, the publishing node may send the file to the first broadcast multicast node as follows.

[0367] In block 212, the publishing node may send a second indication of the update of the file to the first broadcast multicast node.

[0368] In one embodiment, the second indication is a property or parameter having a refresh or update value within the session parameters for notifying the first or second broadcast multicast node regarding the refresh of the file.

[0369] In block 214, the public node may receive a request to fetch a file from a first broadcast multicast node.

[0370] In block 216, the public node may send a response including the file to the first broadcast multicast node.

[0371] For example, if the fetch mode is pull, a public node such as SCEF may call an Update Session to the first broadcast multicast node such as BM-SC, which instructs an update of the file. This instruction may be a property with a refresh or update value within the session parameters to notify the first broadcast multicast node such as BM-SC regarding the refresh of the file. The file may also be included in the file list. If the fetch mode is pull, the first broadcast multicast node such as BM-SC pulls the file from the public node such as SCEF.

[0372] As another example, a public node such as SCEF instructs a first broadcast multicast node such as BM-SC to update a file. The public node such as SCEF uploads the file to an HTTP server, and the first broadcast multicast node such as BM-SC downloads the file from the HTTP server.

[0373] FIG. 2C shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or as a public node or by an apparatus communicatively coupled to the public node. Thus, the apparatus may provide means for achieving various parts of method 220, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0374] In this embodiment, when the capture mode or the object acquisition method is set to pull, the publishing node can send the file to the second broadcast multicast node as follows.

[0375] In block 222, the publishing node may send a second instruction for updating the file to the third broadcast multicast node, and the third broadcast multicast node will send a third instruction based on the second instruction to the second broadcast multicast node.

[0376] In one embodiment, the second instruction is a property or parameter with a refresh or update value within the session parameters for notifying the first or second broadcast multicast node regarding the refresh of the file.

[0377] The third broadcast multicast node can be any suitable network function that can provide a function similar to or the same as the broadcast service function (MBSF) as described in 3GPP TS23.247 V17.2.0.

[0378] In one embodiment, the third broadcast multicast node includes MBSF.

[0379] In block 224, the publishing node may receive a request to fetch the file from the second broadcast multicast node.

[0380] In block 226, the publishing node may send a response including the file to the second broadcast multicast node.

[0381] For example, when the object acquisition method is set to pull, a public node such as NEF calls Nmbsf_MBSUserDataIngestSession_Update on a third broadcast multicast node such as MBSF for MBS user data ingestion session update. The update service operation instructs to update the file containing the updated group message. This instruction may be a property with a refresh or update value within the MBS distribution session parameters for notifying the second / third broadcast multicast node regarding the refresh of the file. The file may also be included in the file list. A third broadcast multicast node such as MBSF calls Nmbstf_MBSDistributionSession_Update on a second broadcast multicast node such as MBSTF. The update service operation instructs to update the file containing the updated group message. This instruction may be a property with a refresh or update value within the MBS distribution session parameters for notifying the second / third broadcast multicast node regarding the refresh of the file. The file may also be included in the file list.

[0382] FIG. 2D shows a flowchart of a method according to another embodiment of the present disclosure that may be implemented in or by an apparatus implemented as or communicatively coupled to a public node within a public node. Thus, the apparatus may provide means for achieving various parts of method 230, as well as means for achieving other processes along with other components. For some parts described in the above embodiments, their descriptions are omitted here for brevity.

[0383] In this embodiment, when the ingestion mode or the object acquisition method is set to pull, the public node may send the file to the first broadcast multicast node or the second broadcast multicast node as follows.

[0384] In block 232, the public node may upload a file to an HTTP server.

[0385] In block 234, the public node may send a second instruction for file update to the first broadcast multicast node or the third broadcast multicast node. The third broadcast multicast node will send a third instruction based on the second instruction to the second broadcast multicast node. The second instruction includes the address of the HTTP server.

[0386] For example, a public node such as NEF / SCEF instructs the first / third broadcast multicast node for file update. Also, a third broadcast multicast node such as MBSF instructs a second broadcast multicast node such as MBSTF for file update. A public node such as NEF / SCEF uploads a file to the HTTP server, and the first / second broadcast multicast node downloads the file from the HTTP server.

[0387] In one embodiment, the public node may upload a file to an HTTP server. The second instruction may include the address of the HTTP server storing the file. The first or second broadcast multicast node may download the file from the HTTP server.

[0388] FIG. 2E shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented by an apparatus implemented in / acting as a public node or communicatively coupled to a public node. Thus, the apparatus may provide means for achieving various parts of method 240, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for brevity.

[0389] In this embodiment, when the capture mode or the object acquisition method is set to push, the public node can send a file to the first broadcast multicast node or the second broadcast multicast node as follows.

[0390] In block 242, the public node can push the file to the second broadcast multicast node.

[0391] In one embodiment, the public node can push the file to the first broadcast multicast node.

[0392] In one embodiment, the file is included in the file list.

[0393] In one embodiment, after receiving a group message request from an application node, a public node such as SCEF can check the permission of the AF. A public node such as SCEF can convert the location information into either a list of MBMS service area identification information or a list of cell IDs, or both, as the MBMS broadcast area.

[0394] In one embodiment, after receiving a group message request from an application node, a public node such as NEF can check the permission of the AF. When geographical area information or urban address information is provided by the AF as the MBS service area, a public node such as NEF converts the MBS service area into a list of cell ID (identifiers) or a list of TAI.

[0395] FIG. 2F shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented by or in a device implemented as a public node or communicatively coupled to a public node. Thus, the device may provide means for achieving various parts of method 240, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0396] In block 252, the public node may receive a group message request from an application node. Block 252 is the same as block 202 in FIG. 2A.

[0397] In block 254, when the group message request is for a modification of group message delivery and includes a group message payload, the public node may send the group message payload to a first broadcast multicast node or a third broadcast multicast node.

[0398] For example, the NEF sends a group message modify request to the MBSF together with an updated group message. The MBSF responds to the NEF. The MBSF sends a group message modify request to the MBSTF together with the updated group message. The MBSTF responds to the MBSF. The MBSTF converts the updated group message into a file.

[0399] As another example, the SCEF sends a group message modify request to the BM-SC together with an updated group message (i.e., the group message payload). The BM-SC responds to the SCEF. The BM-SC converts the updated group message into a file.

[0400] Figure 2G shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented by or in communication with a device implemented as a public node or coupled to a public node. Thus, the device may provide means for achieving various parts of method 260, as well as means for achieving other processes along with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0401] In block 262, the public node may receive a group message request from an application node. Block 262 is the same as block 202 in Figure 2A.

[0402] In block 264, optionally, when the group message request is for cancellation of group message delivery (e.g., instructing cancellation of group message delivery), the public node may send a first instruction to cancel file delivery to a third broadcast multicast node.

[0403] In one embodiment, the capture mode or object acquisition method may be set to pull.

[0404] In one embodiment, when the group message request is for cancellation of group message delivery and the capture mode or object acquisition method is set to pull, the public node may send a first instruction to cancel file delivery to a first broadcast multicast node or a third broadcast multicast node.

[0405] In block 266, optionally, when the group message request is for cancellation of group message delivery (e.g., instructing cancellation of group message delivery), the public node may send an HTTP delete to cancel file delivery to a second broadcast multicast node.

[0406] In one embodiment, the capture mode or object acquisition method may be set to push.

[0407] In one embodiment, when the group message request is for cancellation of group message delivery and the capture mode or object acquisition method is set to push, the public node may send an HTTP DELETE to the first broadcast multicast node or the second broadcast multicast node to cancel the file delivery.

[0408] In one embodiment, the first instruction is a property or parameter having a cancellation value (e.g., within a session parameter) for notifying the first broadcast multicast node or the second broadcast multicast node regarding cancellation of file delivery.

[0409] For example, when the capture mode is set to pull, the SCEF invokes a session update on the BM-SC. The service update operation instructs cancellation of the file delivery. The session update operation instructs cancellation of the file delivery. This instruction may be a property having a cancellation value within the session parameters for notifying the BM-SC regarding cancellation of the file. The file may also be included in the file list. When the capture mode is set to push, the SCEF sends an HTTP DELETE to the BM-SC to cancel the file delivery. The BM-SC stops the file delivery and, if necessary, notifies the MBMS client regarding the cancellation. The cancellation may be included in the schedule fragments delivered within or outside the bandwidth of the MBMS session.

[0410] As another example, when the object acquisition method is set to pull, the NEF calls Nmbsf_MBSUserDataIngestSession_Update on the MBSF. The service update operation instructs cancellation of the file delivery. This instruction may be a property with a cancellation value within the MBS distribution session parameters for notifying the MBSF regarding cancellation of the file. The file may also be included in the file list. The MBSF calls Nmbstf_MBSDistributionSession_Update on the MBSTF. The service update operation instructs cancellation of the file delivery. This instruction may be a property with a cancellation value within the MBS distribution session parameters for notifying the MBSF regarding cancellation of the file. The file may also be included in the file list. When the object acquisition method is set to push, the NEF sends an HTTP DELETE to the MBSTF to cancel the file delivery. The MBSTF stops the file delivery and, if necessary, notifies the MBS client regarding the cancellation, which may be in-band or out-of-band within the MBS broadcast session delivered to the MBS client.

[0411] Figure 3A shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or as a first broadcast multicast node or by an apparatus communicatively coupled to the first broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 300, as well as means for achieving other processes along with other components. For some parts described in the above embodiments, their descriptions are omitted here for brevity.

[0412] In block 302, the first broadcast multicast node may receive a file from a public node or an HTTP server, or may receive from a public node a group message payload, or a first instruction to cancel file delivery, or an HTTP deletion for canceling file delivery. The file is converted from the group message payload, which is included in a group message request that instructs modification or cancellation of group message delivery from an application node to a public node.

[0413] In block 304, when a file is received and group message delivery has not started, the first broadcast multicast node may encode the file and use the file to replace the original file. The file will be delivered after group message delivery has started.

[0414] Encoding the file may include performing packetization for the file and optionally FEC (Forward Error Correction) encoding.

[0415] In one embodiment, determined file metadata (e.g., in a group message delivery procedure) is used as metadata information for the file.

[0416] In one embodiment, the determined file metadata includes a file uniform resource locator (URL) and / or a file uniform resource identifier (URI).

[0417] Figure 3B shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or by an apparatus implemented as or communicatively coupled to a first broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 310, as well as means for achieving other processes along with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0418] In block 312, the first broadcast multicast node may receive a file from a public node or an HTTP server, or receive from the public node a group message payload, or a first instruction to cancel file delivery, or an HTTP deletion to cancel file delivery. The file is converted from the group message payload, which is included in a group message request that instructs modification or cancellation of group message delivery from an application node to the public node.

[0419] In block 314, when the file is received and group message delivery has started, the first broadcast multicast node may encode the file, stop the ongoing group message delivery, and start delivery of the file, or start delivery of the file after the ongoing group message has been delivered.

[0420] Figure 3C shows a flowchart of a method according to another embodiment of the present disclosure, which can be implemented in or by an apparatus implemented as or communicatively coupled to a first broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 320, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0421] In block 322, the first broadcast multicast node may receive a file from a public node or an HTTP server, or may receive from a public node a group message payload, or a first instruction to cancel file delivery, or an HTTP deletion to cancel file delivery. The file is converted from the group message payload, which is included in a group message request that instructs modification or cancellation of group message delivery from an application node to a public node.

[0422] In block 324, when receiving a group message payload and the group message delivery has not started, the first broadcast multicast node may convert the group message payload into a file, encode the file, and use the file to replace the original file. The file will be delivered after the group message delivery has started.

[0423] FIG. 3D shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or by a device implemented as or communicatively coupled to a first broadcast multicast node. Thus, the device may provide means for achieving various parts of method 330, as well as means for achieving other processes along with other components. For some parts described in the above embodiments, their descriptions are omitted here for brevity.

[0424] In block 332, the first broadcast multicast node may receive a file from a public node or an HTTP server, or may receive from the public node a group message payload, or a first instruction to cancel file delivery, or an HTTP deletion to cancel file delivery. The file is converted from the group message payload, which is included in a group message request that instructs modification or cancellation of group message delivery from an application node to a public node.

[0425] In block 334, upon receiving a group message payload and when group message delivery has started, the first broadcast multicast node may convert the group message payload to a file, encode the file, stop ongoing group message delivery, and start delivery of the file, or may start delivery of the file after ongoing group message delivery has been made.

[0426] FIG. 3E shows a flowchart of a method according to another embodiment of the present disclosure, which can be implemented in or by an apparatus implemented as or communicatively coupled to a first broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 340, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0427] In block 342, the first broadcast multicast node may receive a file from a public node or an HTTP server, or may receive from the public node a group message payload, or a first instruction to cancel file delivery, or an HTTP deletion for canceling file delivery. The file is converted from the group message payload, which is included in a group message request that instructs modification or cancellation of group message delivery from an application node to a public node.

[0428] In block 344, upon receiving the first instruction or HTTP deletion and when group message delivery has started, the first broadcast multicast node may stop file delivery and / or notify a Multimedia Broadcast / Multicast Service (MBMS) client regarding cancellation of file delivery.

[0429] In one embodiment, the cancellation is included in a schedule fragment delivered within or outside the bandwidth of an MBMS session to at least one Multimedia Broadcast / Multicast Service (MBMS) client.

[0430] FIG. 3F shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or by a device implemented as or communicatively coupled to a first broadcast multicast node. Thus, the device may provide means for achieving various parts of method 350, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0431] In block 352, the first broadcast multicast node may receive a file from a public node or an HTTP server, or from a public node, a group message payload, or a first indication to cancel file delivery, or an HTTP deletion to cancel file delivery. The file is converted from the group message payload, which is included in a group message request that instructs modification or cancellation of group message delivery from an application node to a public node.

[0432] In block 354, upon receiving the first indication or HTTP deletion and when group message delivery has not started, the first broadcast multicast node may cancel file delivery and / or notify a Multimedia Broadcast / Multicast Service (MBMS) client regarding cancellation of file delivery.

[0433] In one embodiment, the cancellation is included in a schedule fragment distributed within or outside the bandwidth of an MBMS session to at least one Multimedia Broadcast / Multicast Service (MBMS) client.

[0434] Figure 3G shows a flowchart of a method according to another embodiment of the present disclosure, which can be implemented in or by a device implemented as or communicatively coupled to a first broadcast multicast node. Thus, the device may provide means for achieving various parts of method 360, as well as means for achieving other processes along with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0435] In one embodiment, when the capture mode or object acquisition method is set to pull, the first broadcast multicast node may receive a file from the public node as follows.

[0436] In block 362, the first broadcast multicast node may receive a second indication of an update of the file from the public node.

[0437] In one embodiment, the second indication is a property or parameter with a refresh or update value within the session parameters for notifying the first broadcast multicast node regarding the refresh of the file.

[0438] In block 364, the first broadcast multicast node may send a request to the public node to fetch the file.

[0439] In block 366, the first broadcast multicast node may receive a response including the file from the public node.

[0440] FIG. 3H shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or by an apparatus implemented as or communicatively coupled to a first broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 370, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0441] In one embodiment, when the capture mode or object acquisition method is set to pull, the first broadcast multicast node may receive a file from an HTTP server as follows.

[0442] In block 372, the first broadcast multicast node may receive a second indication of an update of the file from a public node. The second indication includes the address of the HTTP server storing the file.

[0443] In one embodiment, the second indication is a property or parameter with a refresh or update value within the session parameters for notifying the first broadcast multicast node regarding the refresh of the file.

[0444] In block 374, the first broadcast multicast node may send a request to the HTTP server to fetch the file.

[0445] In block 376, the first broadcast multicast node may receive a response including the file from the HTTP server.

[0446] Figure 3I shows a flowchart of a method according to another embodiment of the present disclosure, which can be implemented in or by a device implemented as or communicatively coupled to a first broadcast multicast node. Thus, the device may provide means for achieving various parts of method 380, as well as means for achieving other processes along with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0447] In one embodiment, when the capture mode or object acquisition method is set to push, the first broadcast multicast node may receive a file from the public node as follows.

[0448] In block 382, the first broadcast multicast node may receive a file pushed by the public node.

[0449] In one embodiment, the file is included in a file list.

[0450] In one embodiment, the first instruction is a property or parameter (e.g., within session parameters) with a cancel value for notifying the first broadcast multicast node regarding cancellation of file distribution.

[0451] In one embodiment, the public node includes an SCEF, or a combined NEF and SCEF.

[0452] In one embodiment, the first broadcast multicast node includes a BM-SC, or a combined BM-SC, MBSF, and MBSTF.

[0453] In one embodiment, the group message request includes a group message modification request with a requested action set to modify or cancel.

[0454] In one embodiment, the group message request includes a group message modification request or a group message cancellation request.

[0455] FIG. 4A shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or by a second broadcast multicast node or a device communicatively coupled to the second broadcast multicast node. Thus, the device may provide means for achieving various parts of method 400, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0456] At block 402, the second broadcast multicast node may receive a file from the public node, or receive an HTTP deletion to cancel file distribution from the public node, or receive a first indication of cancellation of file distribution from a third broadcast multicast node. The file may be converted from a group message payload, which may be included in a group message request instructing modification or cancellation of group message distribution from the application node to the public node.

[0457] In one embodiment, the second broadcast multicast node may receive a file from the public node or an HTTP server, or receive an HTTP deletion to cancel file distribution from the public node, or receive a group message payload or a first indication of cancellation of file distribution from a third broadcast multicast node. The file is converted from a group message payload, and the group message payload is included in a group message request instructing modification or cancellation of group message distribution from the application node to the public node.

[0458] In one embodiment, the determined file metadata (e.g., in a group message delivery procedure) is used as the metadata information of the file.

[0459] In one embodiment, the determined file metadata includes a file uniform resource locator (URL) and / or a file uniform resource identifier (URI).

[0460] At block 404, optionally, when the file is received and group message delivery has not started, the second broadcast multicast node may encode the file and use the file to replace the original file. The file will be delivered after group message delivery has started.

[0461] FIG. 4B shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in / by a second broadcast multicast node or by an apparatus communicatively coupled to the second broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 410, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0462] At block 412, the second broadcast multicast node may receive a file from the public node, or receive an HTTP deletion for canceling file delivery from the public node, or receive a first instruction for canceling file delivery from a third broadcast multicast node. The file is converted from the group message payload, and the group message payload is included in a group message request that instructs modification or cancellation of group message delivery from the application node to the public node.

[0463] In one embodiment, the second broadcast multicast node may receive a file from a public node or an HTTP server, or receive an HTTP deletion to cancel a file distribution from the public node, or receive a group message payload or a first indication of cancellation of a file distribution from a third broadcast multicast node. The file is converted from the group message payload, and the group message payload is included in a group message request that instructs modification or cancellation of group message distribution from an application node to a public node.

[0464] At block 414, when receiving a file and the group message distribution has started, the second broadcast multicast node may encode the file, stop the ongoing group message distribution, and start the distribution of the file, or start the distribution of the file after the ongoing group message has been distributed.

[0465] FIG. 4C shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or as a second broadcast multicast node or by an apparatus communicatively coupled to the second broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 420, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0466] In block 422, the second broadcast multicast node may receive a file from the public node or an HTTP server, or receive an HTTP deletion to cancel file distribution from the public node, or receive a group message payload or a first indication of cancellation of file distribution from a third broadcast multicast node. The file is converted from the group message payload, and the group message payload is included in a group message request that instructs modification or cancellation of group message distribution from the application node to the public node.

[0467] In block 424, when receiving a group message payload and the group message distribution has not started, the second broadcast multicast node may convert the group message payload into a file, encode the file, and use the file to replace the original file. The file will be distributed after the group message distribution has started.

[0468] FIG. 4D shows a flowchart of a method according to another embodiment of the present disclosure that may be implemented within or as the second broadcast multicast node or by an apparatus communicatively coupled to the second broadcast multicast node. Accordingly, the apparatus may provide means for achieving various parts of method 430, as well as means for achieving other processes along with other components. For some parts described in the above embodiments, their descriptions are omitted here for brevity.

[0469] In block 432, the second broadcast multicast node may receive a file from the public node or an HTTP server, or receive an HTTP deletion to cancel file distribution from the public node, or receive a group message payload or a first indication of cancellation of file distribution from a third broadcast multicast node. The file is converted from the group message payload, and the group message payload is included in a group message request that instructs modification or cancellation of group message distribution from the application node to the public node.

[0470] In block 434, when receiving a group message payload and when group message distribution starts, the second broadcast multicast node may convert the group message payload into a file, encode the file, stop the ongoing group message distribution, and start file distribution, or start file distribution after the ongoing group message has been distributed.

[0471] FIG. 4E shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or as the second broadcast multicast node or by an apparatus communicatively coupled to the second broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 440, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0472] In block 442, the second broadcast multicast node may receive a file from the public node, or receive an HTTP deletion to cancel file distribution from the public node, or receive a first instruction to cancel file distribution from a third broadcast multicast node. The file is converted from the group message payload, which is included in a group message request that instructs modification or cancellation of group message distribution from the application node to the public node.

[0473] In one embodiment, the second broadcast multicast node may receive a file from the public node or an HTTP server, or receive an HTTP deletion to cancel file distribution from the public node, or receive a group message payload or a first instruction to cancel file distribution from a third broadcast multicast node. The file is converted from the group message payload, which is included in a group message request that instructs modification or cancellation of group message distribution from the application node to the public node.

[0474] In block 444, upon receiving the first instruction or the HTTP deletion and when group message distribution has started, the second broadcast multicast node may stop file distribution and / or notify the multicast / broadcast service (MBS) client regarding cancellation of file distribution.

[0475] In one embodiment, the cancellation is distributed to at least one MBS client, either within the bandwidth of the MBS session or outside the bandwidth of the MBS session.

[0476] Figure 4F shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in a second broadcast multicast node or by an apparatus communicatively coupled to the second broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 450, as well as means for achieving other processes along with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0477] In block 452, the second broadcast multicast node may receive a file from a public node, or receive an HTTP deletion for canceling file distribution from the public node, or receive a first instruction to cancel file distribution from a third broadcast multicast node. The file is converted from a group message payload, which is included in a group message request that instructs modification or cancellation of group message distribution from an application node to a public node.

[0478] In one embodiment, the second broadcast multicast node may receive a file from a public node or an HTTP server, or receive an HTTP deletion for canceling file distribution from the public node, or receive a group message payload or a first instruction to cancel file distribution from a third broadcast multicast node. The file is converted from a group message payload, which is included in a group message request that instructs modification or cancellation of group message distribution from an application node to a public node.

[0479] In block 454, when the second broadcast / multicast node receives a first instruction or an HTTP deletion and group message delivery has not started, the second broadcast / multicast node may cancel the file delivery and / or notify the multicast / broadcast service (MBS) client regarding the cancellation of the file delivery.

[0480] In one embodiment, the cancellation is delivered to at least one MBS client within or outside the bandwidth of the MBS session.

[0481] FIG. 4G shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or as the second broadcast / multicast node or by an apparatus communicatively coupled to the second broadcast / multicast node. Thus, the apparatus may provide means for achieving various parts of method 460, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0482] In one embodiment, when the capture mode or object acquisition method is set to pull, the second broadcast / multicast node may receive a file from the public node as follows.

[0483] In block 462, the second broadcast / multicast node may receive a third instruction based on a second instruction for updating the file from the third broadcast / multicast node.

[0484] In block 464, the second broadcast / multicast node may send a request to the public node to fetch the file.

[0485] In block 466, the second broadcast multicast node may receive a file from the public node.

[0486] FIG. 4H shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or as the second broadcast multicast node or by an apparatus communicatively coupled to the second broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 470, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0487] In one embodiment, when the capture mode or object acquisition method is set to pull, the second broadcast multicast node may receive a file from an HTTP server as follows.

[0488] In block 472, the second broadcast multicast node may receive a third instruction based on a second instruction for updating the file from a third broadcast multicast node. The second instruction includes the address of the HTTP server storing the file.

[0489] In block 474, the second broadcast multicast node may send a request to the HTTP server to fetch the file.

[0490] In block 476, the second broadcast multicast node may receive a response including the file from the HTTP server.

[0491] In one embodiment, the second instruction is a property or parameter with a refresh or update value within the multicast / broadcast service (MBS) distribution session parameters for notifying a second broadcast multicast node regarding the refresh of a file.

[0492] FIG. 4I shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in a second broadcast multicast node or by an apparatus communicatively coupled to the second broadcast multicast node. Thus, the apparatus may provide means for achieving various parts of method 480, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0493] In one embodiment, when the capture mode or object acquisition method is set to push, the second broadcast multicast node may receive a file from the public node as follows.

[0494] At block 482, the second broadcast multicast node may receive a file pushed by the public node.

[0495] In one embodiment, the file is included in a file list.

[0496] In one embodiment, the first instruction is a property or parameter with a cancel value (e.g., within the MBS distribution session parameters) for notifying the second broadcast multicast node regarding the cancellation of file distribution.

[0497] In one embodiment, the public node includes a NEF, or a combined NEF and SCEF.

[0498] In one embodiment, the second broadcast multicast node includes an MBSTF.

[0499] In one embodiment, the third broadcast multicast node includes an MBSF.

[0500] In one embodiment, a group message request includes a group message modification request having a requested action set to modify or cancel.

[0501] In one embodiment, a group message request includes a group message modification request or a group message cancellation request.

[0502] FIG. 5 shows a flowchart of a method according to another embodiment of the present disclosure, which can be implemented in or as a third broadcast multicast node or by an apparatus communicatively coupled to the third broadcast multicast node. Thus, the apparatus can provide means for achieving various parts of method 500, as well as means for achieving other processes along with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0503] In block 502, the third broadcast multicast node may receive a second instruction for file update or a first instruction for cancellation of file distribution from the publishing node. The file may be converted from a group message payload, and the group message payload may be included in a group message request that instructs modification or cancellation of group message distribution from the application node to the publishing node.

[0504] In one embodiment, the third broadcast multicast node may receive from the public node a second instruction for file update, or a group message payload, or a first instruction for cancellation of file distribution. The file is converted from the group message payload, and the group message payload is included in a group message request that instructs modification or cancellation of group message distribution from the application node to the public node.

[0505] In block 504, the third broadcast multicast node may send the second instruction or the first instruction to the second broadcast multicast node.

[0506] In one embodiment, the third broadcast multicast node may send the second instruction or the group message payload or the first instruction to the second broadcast multicast node.

[0507] In block 506, optionally, when the first instruction is received, the third broadcast multicast node may notify the multicast / broadcast service (MBS) client regarding cancellation of file distribution.

[0508] In one embodiment, the cancellation is distributed to at least one MBS client within the bandwidth of the MBS session or outside the bandwidth of the MBS session.

[0509] In one embodiment, the third broadcast multicast node may notify the multicast / broadcast service (MBS) client regarding cancellation of file distribution.

[0510] In one embodiment, the first instruction is a property or parameter with a cancellation value (e.g., within the session parameters) for notifying the second broadcast multicast node regarding cancellation of file distribution.

[0511] In one embodiment, the second instruction is a property or parameter with a refresh or update value within the session parameters for notifying a second broadcast multicast node regarding the refresh of a file.

[0512] In one embodiment, the public node includes the NEF, or a combined NEF and SCEF.

[0513] In one embodiment, the second broadcast multicast node includes the MBSTF.

[0514] In one embodiment, the third broadcast multicast node includes the MBSF.

[0515] In one embodiment, the group message request includes a group message modification request with a requested action set to modify or cancel.

[0516] In one embodiment, the group message request includes a group message modification request or a group message cancellation request.

[0517] FIG. 6A shows a flowchart of a method according to another embodiment of the present disclosure, which may be implemented in or as a user equipment or by an apparatus communicatively coupled to the user equipment. Accordingly, the apparatus may provide means for achieving various parts of method 600, as well as means for achieving other processes together with other components. For some parts described in the above embodiments, their descriptions are omitted here for the sake of brevity.

[0518] In block 602, the user equipment may receive a message from a second broadcast multicast node or a third broadcast multicast node. The message includes a cancellation of file delivery.

[0519] In one embodiment, the user equipment may receive a message from a first broadcast multicast node. The message includes a cancellation of file distribution.

[0520] For example, as described above, the first / second / third broadcast multicast node may notify the MBS / MBMS client of the user equipment regarding the cancellation of file distribution, and then the user equipment may receive a message from the first broadcast multicast node or the second broadcast multicast node or the third broadcast multicast node.

[0521] In one embodiment, the cancellation is received within the bandwidth of a multicast / broadcast service (MBS) session or a multimedia broadcast / multicast service (MBMS) session, or outside the bandwidth of the MBS session or the MBMS session.

[0522] In one embodiment, the user equipment includes a multicast / broadcast service (MBS) client or a multimedia broadcast / multicast service (MBMS) client.

[0523] In one embodiment, the first broadcast multicast node includes at least one of a broadcast multicast service center (BM-SC), or a combined BM-SC, a multicast / broadcast service function (MBSF), and a multicast / broadcast service transport function (MBSTF).

[0524] In one embodiment, the second broadcast multicast node includes MBSTF, and the third broadcast multicast node includes MBSF.

[0525] Figure 6B shows a flowchart of group message delivery on MBMS in EPS according to another embodiment of the present disclosure.

[0526] In step 1, the AF sends a group message modification request, which includes a requested action, a group message payload, location information, a group message delivery start time, a stop time, and an external group identifier, to the SCEF. The SCEF uses the external group identifier to identify the associated MBS service. The requested action is set to either "modify" or "cancel". "Modify" indicates that the request is for modifying a group message delivery transaction. "Cancel" indicates that the request is for canceling a group message delivery transaction.

[0527] There may be any other parameters during the group message modification request.

[0528] In step 2, the SCEF checks the permission of the AF. The SCEF converts the location information into either a list of MBMS service area identification information as an MBMS broadcast area, or a list of cell IDs, or both.

[0529] If the requested action is "modify" and the group message payload is updated, steps 3 to 5 are executed.

[0530] In step 3, the SCEF converts the group message payload into a file and uses the determined file metadata (such as a file URL or a file URI, etc.) in the group message delivery procedure.

[0531] In step 4, if the intake mode is pull, the SCEF calls for a session update to the BM-SC, which instructs the file update. This instruction can be a property or parameter with a refresh or update value within the session parameters for notifying the BM-SC regarding the file refresh. The file can also be included in the file list.

[0532] In step 5, if the intake mode is pull, the BM-SC pulls the file from the SCEF. If the intake mode is push, the SCEF pushes the updated file to the BM-SC.

[0533] In step 6, the BM-SC performs packetization for the updated file and optionally FEC encoding.

[0534] If the group message delivery has not started, the BM-SC simply uses the updated file to replace the original file. Also, the updated file will be delivered after the delivery starts.

[0535] If the group message delivery has started, the BM-SC stops the ongoing delivery and starts the delivery of the updated file to the MBMS GW (gateway). The MBMS-GW delivers the content to the LTE-RAN, and the LTE-RAN broadcasts the content to the UEs.

[0536] If the requested action is "modify" and the MBS service area is updated, steps 7 to 8 are executed.

[0537] In step 7, the SCEF calls for a session update on the BM-SC. The service update operation instructs the MBMS service area update.

[0538] In step 8, the BM-SC executes an MBMS session update procedure to update the MBMS service area.

[0539] If the requested action is "cancel", steps 9 to 13 are executed. If group message delivery has not started, steps 9 to 11 can be skipped. If group message delivery has started, steps 9 to 11 are required when the BM-SC needs to notify the MBMS client regarding cancellation of file delivery.

[0540] In step 9, if the fetch mode is set to pull, the SCEF invokes a session update on the BM-SC. The service update operation instructs cancellation of file delivery. This instruction can be a property or parameter having a cancel value (e.g., within session parameters) for notifying the BM-SC regarding cancellation of the file. The file can also be included in the file list.

[0541] In step 10, if the fetch mode is set to push, the SCEF sends an HTTP delete to the BM-SC to cancel file delivery.

[0542] In step 11, the BM-SC stops file delivery and, if necessary, notifies the MBMS client regarding cancellation. The cancellation can be included in the schedule fragments delivered within the MBMS session bandwidth or outside the MBMS bandwidth.

[0543] In step 12, the SCEF invokes a session termination on the BM-SC.

[0544] In step 13, the BM-SC triggers execution of an MBMS session stop for the LTE RAN via the EPC.

[0545] In step 14, the SCEF sends a group message modification response to the AF.

[0546] FIG. 6C shows a flowchart of another option for steps 3 to 5 of FIG. 6B according to another embodiment of the present disclosure.

[0547] In step a, the SCEF sends a group message modification request to the BM-SC together with the updated group message. The BM-SC responds to the SCEF.

[0548] In step b, the BM-SC converts the updated group message into a file.

[0549] FIG. 6D shows a flowchart of group message modification and cancellation on MBS broadcast according to another embodiment of the present disclosure.

[0550] In the procedure referred to 3GPP TS26.502 v1.0.0, the NEF is the MBS application provider.

[0551] In step 1, the AF sends a group message modification request, which includes a requested action, a group message payload, an MBS service area, a group message delivery start time, a stop time, and an external group identifier, to the NEF. The NEF uses the external group identifier to identify the associated MBS service. The requested action is set to either "modify" or "cancel". "Modify" indicates that the request is for modifying the group message delivery transaction. "Cancel" indicates that the request is for canceling the group message delivery transaction.

[0552] There may be any other parameters during the group message request.

[0553] In step 2, the NEF checks the permission of the AF. If the geographical area information or the urban address information is provided by the AF as the MBS service area, the NEF converts the MBS service area into a cell ID list or a TAI list.

[0554] If the requested action is "Modify" and the group message payload is updated, steps 3 to 6 are executed.

[0555] In step 3, the NEF converts the group message payload into a file and uses the determined file metadata (such as a file URL or a file URI, etc.).

[0556] In step 4, if the object acquisition method is set to Push, steps 4 to 5 can be skipped. If the object acquisition method is set to Pull, the NEF calls the MBS user data ingestion session update (Nmbsf_MBSUserDataIngestSession_Update) on the MBSF. The service update operation instructs the update of the file containing the updated group message. This instruction can be a property or a parameter with a refresh or update value within the MBS distribution session parameters for notifying the MBSF regarding the refresh of the file. The file can also be included in the file list.

[0557] In step 5, the MBSF calls the MBS distribution session update (Nmbstf_MBSDistributionSession_Update) on the MBSTF. The service update operation instructs the update of the file containing the updated group message. This instruction can be a property or a parameter with a refresh or update value within the MBS distribution session parameters for notifying the MBSF regarding the refresh of the file. The file can also be included in the file list.

[0558] In step 6, if the object acquisition method is set to push, the NEF pushes the update file to the MBSTF. If the object acquisition method is set to pull, the MBSTF pulls the updated file from the NEF.

[0559] In step 7, the MBSTF performs packetization for the updated file and optionally FEC encoding.

[0560] If the group message delivery has not started, the MBSTF simply uses the updated file to replace the original file. Also, the updated file will be delivered after the delivery starts.

[0561] If the group message delivery has started, the MBSTF stops the ongoing delivery and starts delivering the updated file to the MB-UPF. The MB-UPF delivers the content to the NG-RAN, and the NG-RAN broadcasts the content to the UE.

[0562] If the requested action is "modify" and the MBS service area is updated, steps 8 to 9 are executed.

[0563] In step 8, the NEF calls Nmbsf_MBSUserService_Update on the MBSF. The service update operation instructs the MBS service area update.

[0564] In step 9, the MBSF performs an MBS session update as specified in section 7.1.1.6 or section 7.1.1.7 of 3GPP TS23.247 V17.2.0 to update the MBS service area, which triggers an MBS session update for broadcasting as specified in section 7.3.3 of 3GPP TS23.247 V17.2.0.

[0565] If the required action is "Cancel", steps 10 to 16 are executed. If the group message delivery has not started, steps 10 to 13 may be skipped. If the group message delivery has started, steps 10 to 13 are required when the MBSF needs to notify the MBS client regarding the cancellation of the file delivery.

[0566] In step 10, if the object acquisition method is set to push, steps 10 to 11 may be skipped. If the object acquisition method is set to pull, the NEF calls Nmbsf_MBSUserDataIngestSession_Update on the MBSF. The service update operation instructs the cancellation of the file delivery. This instruction may be a property or parameter with a cancellation value within the MBS distribution session parameters for notifying the MBSF regarding the cancellation of the file. The file may also be included in the file list.

[0567] In step 11, the MBSF calls Nmbstf_MBSDistributionSession_Update on the MBSTF. The service update operation instructs the cancellation of the file delivery. This instruction may be a property with a cancellation value within the MBS distribution session parameters for notifying the MBSF regarding the cancellation of the file. The file may also be included in the file list. The MBSTF stops the file delivery.

[0568] In step 12, if the object acquisition method is set to push, the NEF may send an HTTP DELETE to the MBSTF to cancel the file delivery. The MBSTF stops the file delivery.

[0569] In step 13, the MBSF notifies the MBS client, if necessary, regarding the cancellation of file delivery, which can be within or outside the bandwidth delivered within the MBS broadcast session to the MBS client.

[0570] In step 14, the NEF calls, on the MBSF, the MBS user data ingestion session destruction (Nmbsf_MBSUserDataIngestSession_Destroy) or the MBS user data ingestion session deletion (Nmbsf_MBSUserDataIngestSession_DELETE).

[0571] In step 15, the MBSF calls, on the MBSTF, the MBS distribution session destruction (Nmbstf_MBSDistributionSession_Destroy) or the MBS user distribution session deletion (Nmbstf_MBSDistributionSession_DELETE).

[0572] In step 16, the MBSF performs the MBS session deletion as specified in section 7.1.1.4 or section 7.1.1.5 of 3GPP TS23.247 V17.2.0, which triggers the release of the MBS session for broadcast as specified in section 7.3.2 of 3GPP TS23.247 V17.2.0.

[0573] In step 17, the NEF sends a group message modification response to the AF.

[0574] Figure 6E shows a flowchart of another option for steps 3 to 6 of Figure 6D according to another embodiment of the present disclosure.

[0575] In step a, the NEF sends a group message modification request to the MBSF together with the updated group message. The MBSF responds to the NEF.

[0576] In step b, the MBSF sends the updated group message modification request to the MBSTF while being updated. The MBSTF responds to the MBSF.

[0577] In step c, the MBSTF converts the updated group message into a file.

[0578] Figure 6F shows a flowchart of group message delivery on MBMS and MBS broadcasts according to another embodiment of the present disclosure.

[0579] The flowchart of Figure 6F is the same as the flowchart of Figure 6B except for the following additions.

[0580] The SCEF is replaced with SCEF+NEF.

[0581] The BM-SC is replaced with BM-SC+MBSF+MBSTF.

[0582] In step 4, when the capture mode is pull, the SCEF+NEF invokes a session update for BM-SC+MBSF+MBSTF and / or an MBS user data capture session update, which instructs a file update.

[0583] In step 6, the BM-SC+MBSF+MBSTF distributes the content separately to the LTE-RAN via the EPC and to the NG-RAN via the 5GC.

[0584] In step 7, the SCEF+NEF invokes a session update for BM-SC+MBSF+MBSTF and / or an MBS user service update. The service update operation instructs an MBMS service area update.

[0585] In step 8, BM-SC + MBSF + MBSTF separately executes an MBMS session update procedure for updating the MBMS service area in eMBMS and an MBS session update procedure for updating the MBS service area in MBS.

[0586] In step 9, SCEF + NEF invokes a session update for BM-SC + MBSF + MBSTF and / or an MBS user service update. The service update operation instructs cancellation of a file.

[0587] In step 11, BM-SC + MBSF + MBSTF separately notifies cancellation to the MBMS client and the MBS client. The cancellation can be within or outside the bandwidth distributed in the MBMS session and the MBS broadcast session.

[0588] In step 12, BM-SC + MBSF + MBSTF separately executes an MBMS session stop procedure in eMBMS and an MBS session deletion procedure in MBS.

[0589] FIG. 6G shows another optional flowchart of steps 3 to 5 of FIG. 6F according to another embodiment of the present disclosure.

[0590] In step a, SCEF + NEF sends a group message modification request to BM-SC + MBSF + MBSTF together with the updated group message. BM-SC + MBSF + MBSTF responds to SCEF + NEF.

[0591] In step b, BM-SC + MBSF + MBSTF converts the updated group message into a file.

[0592] In one embodiment, the following content may be added to 3GPP TR23.700-47 V.0.2.0.

[0593] It is proposed to capture the following changes in 3GPP TR23.700-47 V0.2.0.

[0594] Figure 7 shows a flowchart of the modification or cancellation of group message delivery via MBS broadcast according to another embodiment of the present disclosure.

[0595] In the procedure referred to 3GPP TS26.502 v1.0.0, the NEF is the MBS application provider.

[0596] In step 1, the AF sends a group message modification request including the requested action, group message payload, MBS service area, group message delivery start time, stop time, and external group identifier to the NEF. The NEF uses the external group identifier to identify the associated MBS service. The requested action is set to either "modify" or "cancel". "Modify" indicates that the request is for modifying the group message delivery transaction. "Cancel" indicates that the request is for canceling the group message delivery transaction.

[0597] Other parameters in the group message request are FFS.

[0598] In step 2, the NEF checks the permission of the AF. If geographical area information or urban address information is provided by the AF as the MBS service area, the NEF converts the MBS service area into a cell ID list or a TAI list.

[0599] If the requested action is "modify" and the group message payload is updated, steps 3 to 6 are executed.

[0600] In step 3, NEF converts the group message payload into a file and uses the determined file metadata (e.g., file URL, etc.) as described in section 6.12.3.2 of 3GPP TR23.700-47 V0.2.0.

[0601] In step 4, if the object acquisition method is set to push, steps 4 to 5 can be skipped. If the object acquisition method is set to pull, NEF calls Nmbsf_MBSUserDataIngestSession_Update on MBSF. The service update operation instructs the update of the file containing the updated group message.

[0602] In step 5, MBSF calls Nmbstf_MBSDistributionSession_Update on MBSTF. The service update operation instructs the update of the file containing the updated group message.

[0603] In step 6, if the object acquisition method is set to push, NEF pushes the updated file to MBSTF. If the object acquisition method is set to pull, MBSTF pulls the updated file from NEF. Also, MBSTF distributes the updated file to MB-UPF in 5GC.

[0604] If the requested action is "modify" and the MBS service area is updated, steps 7 to 8 are executed.

[0605] In step 7, NEF calls Nmbsf_MBSUserService_Update on MBSF. The service update operation instructs the MBS service area update.

[0606] In step 8, the MBSF performs an MBS session update as specified in section 7.1.1.6 or section 7.1.1.7 of 3GPP TS 23.247 V17.2.0 to update the MBS service area, which triggers an MBS session update for broadcast as specified in section 7.3.3 of 3GPP TS 23.247 V17.2.0.

[0607] If the requested action is "cancel", steps 9 to 14 are executed. Steps 9 to 11 are required when group message delivery starts and the MBSF needs to notify the MBS client regarding the cancellation of file delivery. Otherwise, steps 9 to 14 can be skipped.

[0608] In step 9, the NEF calls Nmbsf_MBSUserDataIngestSession_Update on the MBSF. The service update operation instructs the cancellation of file delivery. The MBSF notifies the MBS client regarding the cancellation of file delivery if necessary.

[0609] In step 10, if the object acquisition method is set to pull, the MBSF calls Nmbstf_MBSDistributionSession_Update on the MBSTF. The service update operation instructs the cancellation of file delivery. The MBSTF stops file delivery.

[0610] In step 11, if the object acquisition method is set to push, the NEF may send an HTTP DELETE to the MBSTF to cancel file delivery. The MBSTF stops file delivery.

[0611] In step 12, the NEF calls Nmbsf_MBSUserDataIngestSession_Destroy on the MBSF.

[0612] In step 13, the MBSF calls Nmbstf_MBSDistributionSession_Destroy on the MBSTF.

[0613] In step 14, the MBSF performs MBS session deletion as specified in section 7.1.1.4 or section 7.1.1.5 of 3GPP TS23.247 V17.2.0, which triggers the release of the MBS session for broadcasting as specified in section 7.3.2 of 3GPP TS23.247 V17.2.0.

[0614] In step 15, the NEF sends a group message modification response to the AF.

[0615] In one embodiment, the following content may be added to 3GPP TR23.700-47 V.0.2.0.

[0616] 6.X.4 Impact on services, entities, and interfaces.

[0617] Except for the following additions, the functional entities defined in section 5.3.2 of 3GPP TS23.247 V17.2.0 and section 6.2 of 3GPP TS23.501 V17.1.1 are reused.

[0618] NEF:

[0619] - Support the group message delivery and group message modification interfaces to the AF, and optionally include service notification information in the group message delivery response to the AF.

[0620] - Convert the group message to a file and determine the metadata information of the file.

[0621] - Create an MBS user service and an MBS user data import session to the MBSF in group message delivery.

[0622] - Update the MBS user service to the MBSF for MBS service area update. When the group message is updated, update the MBS user data import session to the MBSF.

[0623] - Optionally, when group message delivery starts and the MBSF needs to notify the MBSF client regarding cancellation of file delivery, update the MBS user data import session to the MBSF to cancel or delete the file to the MBSTF. Discard the MBS user data import session to the MBSF.

[0624] - Import the file to the MBSTF.

[0625] By applying the proposed solution according to the embodiments of the present disclosure, many advantages can be achieved. For example, some embodiments herein may enable group message modification and group message cancellation on MBMS, MBS, and MBS interworking with MBMS. Some embodiments herein may correct the drawbacks within the current group message modification via MBMS (it is not feasible to replace the group message using session property update to the BM-SC). Some embodiments herein may improve the limitations regarding the current group message cancellation via MBMS (SCEF session termination to the BM-SC, however, the UE is not aware of the cancellation of the group message). The embodiments herein are not limited to the features and advantages described above. Those skilled in the art will recognize additional features and advantages upon reading the following detailed description.

[0626] FIG. 8A is a block diagram showing an apparatus suitable for practicing some embodiments of the present disclosure. For example, the public node, the first broadcast multicast node, the second broadcast multicast node, the third broadcast multicast node, and the user equipment described above can be implemented as or through apparatus 800.

[0627] Apparatus 800 includes at least one processor 821, such as a digital processor (DP), and at least one memory (MEM) 822 coupled to processor 821. Apparatus 800 may further include a transmitter TX and a receiver RX 823 coupled to processor 821. MEM 822 stores a program (PROG) 824. PROG 824 may include instructions that, when executed on the associated processor 821, enable apparatus 800 to operate in accordance with embodiments of the present disclosure. The combination of at least one processor 821 and at least one MEM 822 may form processing means 825 adapted to implement various embodiments of the present disclosure.

[0628] Various embodiments of the present disclosure may be implemented by a computer program executable by one or more of processor 821, software, firmware, hardware, or a computer program executable in a combination thereof.

[0629] MEM 822 can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as, by way of non-limiting example, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory.

[0630] Processor 821 can be of any type suitable for the local technical environment and can include, by way of non-limiting example, one or more of a general-purpose computer, a dedicated computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture.

[0631] In one embodiment where the device is implemented as or at a public node, memory 822 includes instructions executable by processor 821, whereby the public node operates according to any of the methods associated with the public node described above.

[0632] In one embodiment where the device is implemented as or at a first broadcast multicast node, memory 822 includes instructions executable by processor 821, whereby the first broadcast multicast node operates according to any of the methods associated with the first broadcast multicast node described above.

[0633] In one embodiment where the device is implemented as or at a second broadcast multicast node, memory 822 includes instructions executable by processor 821, whereby the second broadcast multicast node operates according to any of the methods associated with the second broadcast multicast node described above.

[0634] In one embodiment where the device is implemented as or at a third broadcast multicast node, memory 822 includes instructions executable by processor 821, whereby the third broadcast multicast node operates according to any of the methods associated with the third broadcast multicast node described above.

[0635] In one embodiment where the apparatus is implemented as or in a user equipment, the memory 822 includes instructions executable by the processor 821, whereby the user equipment operates in accordance with any of the methods related to the user equipment described above.

[0636] FIG. 8B is a block diagram showing a public node according to an embodiment of the present disclosure. As shown, the public node 830 includes a first receiving module 831 configured to receive a group message request from an application node.

[0637] In one embodiment, when the group message request is for a modification of group message delivery and includes a group message payload, the public node 830 further includes a conversion module 832 configured to convert the group message payload into a file. The public node 830 further includes a first sending module 833 configured to send the file to a second broadcast multicast node.

[0638] In one embodiment, when the group message request is for a cancellation of group message delivery, the public node 830 further includes a third sending module 834 configured to send a first instruction for cancellation of file delivery to a third broadcast multicast node. The public node 830 further includes a fourth sending module 835 configured to send an HTTP delete to the second broadcast multicast node to cancel the file delivery.

[0639] FIG. 8C is a block diagram showing a first broadcast multicast node according to an embodiment of the present disclosure. As shown, the first broadcast multicast node 850 is configured to receive a file from a public node or an HTTP server, or to receive from a public node a group message payload, or a first instruction to cancel file delivery, or an HTTP deletion to cancel file delivery. The file is converted from the group message payload, and the group message payload is included in a group message request instructing modification or cancellation of group message delivery from an application node to a public node.

[0640] In one embodiment, when the first broadcast multicast node 850 receives a file and group message delivery has not started, the first broadcast multicast node 850 further comprises a first encoding module 852 configured to encode the file and a first usage module 853 configured to use the file to replace the original file. The file will be delivered after group message delivery has started.

[0641] In one embodiment, when the first broadcast multicast node 850 receives a file and group message delivery has started, the first broadcast multicast node 850 further comprises a second encoding module 854 configured to encode the file, a first stop module 855 configured to stop ongoing group message delivery, and a first start module 856 configured to start delivery of the file or to start delivery of the file after an ongoing group message has been delivered.

[0642] In one embodiment, when the first broadcast / multicast node 850 receives a group message payload and group message delivery has not started, the first broadcast / multicast node 850 further includes a first conversion module 857 configured to convert the group message payload into a file, a third encoding module 858 configured to encode the file, and a second usage module 859 configured to use the file to replace the original file. The file will be delivered after group message delivery has started.

[0643] In one embodiment, when the first broadcast / multicast node 850 receives a group message payload and group message delivery has started, the first broadcast / multicast node 850 further includes a second conversion module 860 configured to convert the group message payload into a file, a fourth encoding module 861 configured to encode the file, a second stop module 862 configured to stop ongoing group message delivery, and a second start module 863 configured to start delivering the file or start delivering the file after an ongoing group message has been delivered.

[0644] In one embodiment, when the first broadcast / multicast node 850 receives a first instruction or an HTTP deletion and group message delivery has started, the first broadcast / multicast node 850 further includes a third stop module 864 configured to stop file delivery and / or notify a Multimedia Broadcast / Multicast Service (MBMS) client regarding cancellation of file delivery.

[0645] In one embodiment, when the first broadcast multicast node 850 receives a first instruction or an HTTP deletion and group message delivery has not started, it further includes a cancellation module 865 configured to cancel file delivery and / or a notification module 866 configured to notify a Multimedia Broadcast / Multicast Service (MBMS) client regarding cancellation of file delivery.

[0646] FIG. 8D is a block diagram showing a second broadcast multicast node according to an embodiment of the present disclosure. As shown, the second broadcast multicast node 870 includes a first receiving module 871 configured to receive a file from a public node, or receive an HTTP deletion to cancel file delivery from a public node, or receive a first instruction to cancel file delivery from a third broadcast multicast node. The file can be converted from a group message payload, and the group message payload can be included in a group message request that instructs modification or cancellation of group message delivery from an application node to a public node.

[0647] In one embodiment, when the second broadcast multicast node 870 receives a file and group message delivery has not started, it further includes a first encoding module 872 configured to encode the file and a first usage module 873 configured to use the file to replace the original file. The file will be delivered after group message delivery has started.

[0648] In one embodiment, when the second broadcast multicast node 870 receives a file and group message delivery is started, the second broadcast multicast node 870 further includes a second encoding module 874 configured to encode the file, a first stop module 875 configured to stop ongoing group message delivery, and a first start module 876 configured to start delivering the file or start delivering the file after an ongoing group message has been delivered.

[0649] In one embodiment, when the second broadcast multicast node 870 receives a first instruction or an HTTP deletion and group message delivery is started, the second broadcast multicast node 870 further includes a third stop module 877 configured to stop file delivery and / or a first notification module 878 configured to notify a multicast / broadcast service (MBS) client regarding cancellation of file delivery.

[0650] In one embodiment, when the second broadcast multicast node 870 receives a first instruction or an HTTP deletion and group message delivery has not been started, the second broadcast multicast node 870 further includes a cancellation module 879 configured to cancel file delivery and / or a second notification module 880 configured to notify a multicast / broadcast service (MBS) client regarding cancellation of file delivery.

[0651] FIG. 8E is a block diagram showing a third broadcast multicast node according to an embodiment of the present disclosure. As shown, the third broadcast multicast node 890 includes a receiving module 891 configured to receive from a public node a second instruction for file update, or a group message payload, or a first instruction for cancellation of file distribution. The file is converted from the group message payload, and the group message payload is included in a group message request instructing modification or cancellation of group message distribution from an application node to a public node. The third broadcast multicast node 880 further includes a sending module 892 configured to send the second instruction, or the group message payload, or the first instruction to a second broadcast multicast node.

[0652] In one embodiment, the third broadcast multicast node 880 further includes a notification module 893 configured to notify a multicast / broadcast service (MBS) client regarding cancellation of file distribution when the first instruction is received.

[0653] FIG. 9 is a block diagram showing a user equipment according to an embodiment of the present disclosure. As shown, the user equipment 900 includes a receiving module 901 configured to receive a message from a second broadcast multicast node or a third broadcast multicast node. The message may include cancellation of file distribution.

[0654] The term "unit" or "module" may have its ordinary meaning in the field of electronics, electrical devices, and / or electronic devices, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logic solids and / or discrete devices, computer programs or instructions, etc. for performing respective tasks, procedures, calculations, outputs, and / or display functions such as those described herein.

[0655] When there are functional units, the public node, the first broadcast multicast node, the second broadcast multicast node, the third broadcast multicast node, and the user equipment may not require a fixed processor or memory, and any computing resources and storage resources may be composed of the public node, the first broadcast multicast node, the second broadcast multicast node, the third broadcast multicast node, and the user equipment in the communication system. The introduction of virtualization technology and network computing technology may improve the utilization efficiency of network resources and the flexibility of the network.

[0656] According to one aspect of the present disclosure, there is provided a computer program product tangibly stored on a computer-readable storage medium and including instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods described above.

[0657] According to one aspect of the present disclosure, there is provided a computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform any of the methods described above.

[0658] Furthermore, an exemplary overall communication system including the above-described terminal device and a network node (such as the above-described public node, the first broadcast multicast node, the second broadcast multicast node, or the third broadcast multicast node) is introduced as follows.

[0659] Embodiments of the present disclosure provide a communication system including a host computer including a processing circuit configured to provide user data and a communication interface configured to forward the user data to a cellular network for transmission to a terminal device. The cellular network includes a base station such as the above-described radio access network node and / or a terminal device such as the above-described UE.

[0660] In an embodiment of the present disclosure, the system further includes a terminal device. The terminal device is configured to communicate with a base station.

[0661] In an embodiment of the present disclosure, the processing circuit of the host computer is configured to execute a host application, thereby providing user data, and the terminal device includes a processing circuit configured to execute a client application associated with the host application.

[0662] Embodiments of the present disclosure also provide a communication system including a host computer including a communication interface configured to receive user data generated from a transmission from a terminal device and a base station. The transmission is from the terminal device to the base station. The terminal device is the above-described UE. The base station is the above-described radio access network node.

[0663] In an embodiment of the present disclosure, the processing circuit of the host computer is configured to execute a host application. The terminal device is configured to execute a client application associated with the host application, thereby providing user data to be received by the host computer.

[0664] FIG. 10 is a schematic diagram showing a wireless network according to some embodiments.

[0665] The subject matter described herein can be implemented in any suitable type of system using any suitable components, but the embodiments disclosed herein are described with respect to wireless networks such as the exemplary wireless network shown in FIG. 10. For simplicity, the wireless network of FIG. 10 only illustrates network 1006, network nodes 1060 and 1060b (corresponding to network-side nodes), and WDs 1010, 1010b, and 1010c (corresponding to terminal devices). In practice, the wireless network can further include any additional elements suitable for supporting communication between wireless devices or between a wireless device and another communication device such as a landline phone, a service provider, or any other network node or end device. Among the components shown, network node 1060 and wireless device (WD) 1010 are illustrated with additional detail. The wireless network can provide communication and other types of services to one or more wireless devices to facilitate access of the wireless devices to the wireless network and / or use of services provided by or through the wireless network.

[0666] A wireless network can include and / or interface with any type of communication, telecommunication, data, cellular, and / or wireless network, or other similar types of systems. In some embodiments, the wireless network can be configured to operate according to a particular standard or other type of predefined rules or procedures. Thus, particular embodiments of the wireless network can implement communication standards such as GSM (Global System for Mobile Communications), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, or 5G standards, wireless local area network (WLAN) standards such as the IEEE802.11 standard, and / or any other appropriate wireless communication standards such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, and / or ZigBee standards.

[0667] Network 1006 can include one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTN), packet data networks, optical networks, wide area networks (WAN), local area networks (LAN), wireless local area networks (WLAN), wired networks, wireless networks, metropolitan area networks, and other networks that enable communication between devices.

[0668] Network node 1060 and WD 1010 include various components that are described in more detail below. These components cooperate to provide network node and / or wireless device functionality, such as providing a wireless connection in a wireless network. In different embodiments, the wireless network may comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals, whether via a wired connection or a wireless connection.

[0669] As used herein, a network node refers to a device that is configured, constructed, and / or operable to communicate directly or indirectly with a wireless device and / or other network nodes or devices in a wireless network to enable and / or provide wireless access to the wireless device and / or perform other functions (e.g., administration) in the wireless network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., wireless access points), base stations (BSs) (e.g., wireless base stations, Node B, evolved Node B (eNB), and NR Node B (gNB)). Base stations can be categorized based on the amount of coverage provided by the base station (or, alternatively, the transmission power level of the base station), in which case they may also be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station can be a relay node or a relay donor node that controls a relay. A network node can also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), which may sometimes be referred to as a remote radio head (RRH). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may sometimes be referred to as nodes in a distributed antenna system (DAS). Further examples of network nodes include multi-standard radio (MSR) devices such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), core network nodes (e.g., MSC, MME), O&M nodes, OSS nodes, SON nodes, positioning nodes (e.g., E-SMLC), and / or MDTs. As another example, a network node can be a virtual network node, as described in more detail below.However, more generally, a network node can represent any suitable device (or group of devices) that is configured, constructed, and / or operable to enable access to and / or provide access to a wireless network and / or provide some service to a wireless device that has accessed the wireless network.

[0670] In FIG. 10, network node 1060 includes a processing circuit 1070, a device-readable medium 1080, an interface 1090, auxiliary equipment 1084, a power source 1086, a power circuit 1087, and an antenna 1062. The network node 1060 shown in the exemplary wireless network of FIG. 10 can represent a device that includes the shown combination of hardware components, although other embodiments can include network nodes with different combinations of components. It should be understood that a network node can include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. Moreover, although the components of network node 1060 are illustrated as a single box located within a larger box or as a single box nested within multiple boxes, in reality, a network node can include multiple different physical components that make up a single shown component (e.g., device-readable medium 1080 can include multiple separate hard drives as well as multiple RAM modules).

[0671] Similarly, network node 1060 can be assembled from a plurality of physically distinct components (e.g., a Node B component and an RNC component, or a BTS component and a BSC component, etc.), each of which can have its own respective components. In some scenarios where network node 1060 includes a plurality of distinct components (e.g., a BTS component and a BSC component), one or more of the distinct components can be shared among several network nodes. For example, a single RNC can control multiple Node Bs. In such scenarios, each unique pair of Node B and RNC can, in some cases, be regarded as a single distinct network node. In some embodiments, network node 1060 can be configured to support a plurality of radio access technologies (RATs). In such embodiments, some components can be replicated (e.g., separate device-readable media 1080 for different RATs), and some components can be reused (e.g., the same antenna 1062 can be shared by RATs). Network node 1060 can also include a plurality of sets of various illustrated components for different radio technologies, such as, for example, GSM, WCDMA, LTE, NR, WiFi, or Bluetooth radio technologies, integrated into network node 1060. These radio technologies can be integrated with the same or different chips or sets of chips, and other components within network node 1060.

[0672] The processing circuit 1070 is configured to perform any decision-making operation, computational operation, or similar operation (e.g., some acquisition operations) as described herein as provided by a network node. These operations performed by the processing circuit 1070 may include processing the information acquired by the processing circuit 1070, for example, by converting the acquired information into other information, comparing the acquired information or the converted information with the information stored in the network node, and / or performing one or more operations based on the acquired information or the converted information and as a result of the processing having made a decision.

[0673] The processing circuit 1070 may include a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, one or more combinations of resources, or a combination of hardware, software and / or encoded logic, operable to provide the network node 1060 functionality either alone or in combination with other network node 1060 components such as the device-readable medium 1080. For example, the processing circuit 1070 may execute instructions stored on the device-readable medium 1080 or instructions stored in the memory within the processing circuit 1070. Such functionality may include providing any of the various wireless features, functions, or benefits described herein. In some embodiments, the processing circuit 1070 may include a system on chip (SOC).

[0674] In some embodiments, the processing circuit 1070 may include one or more of a radio frequency (RF) transceiver circuit 1072 and a baseband processing circuit 1074. In some embodiments, the radio frequency (RF) transceiver circuit 1072 and the baseband processing circuit 1074 may be on separate chips (or sets of chips), boards, or units such as a radio unit and a digital unit. In alternative embodiments, some or all of the RF transceiver circuit 1072 and the baseband processing circuit 1074 may be on the same chip or set of chips, board, or unit.

[0675] In some embodiments, some or all of the functions described herein as provided by a network node, base station, eNB, or other such network device may be implemented by a processing circuit 1070 executing instructions stored in a device-readable medium 1080, or in a memory within the processing circuit 1070. In alternative embodiments, some or all of the functions may be provided by the processing circuit 1070 without executing instructions stored in a separate or distinct device-readable medium, such as in a hardwired manner. In any of those embodiments, whether or not executing instructions stored in a device-readable storage medium, the processing circuit 1070 may be configured to perform the described functions. The benefits provided by such functions are not limited to the processing circuit 1070 alone, or to other components of the network node 1060, but are enjoyed generally by the network node 1060 as a whole, and / or by end users and the wireless network.

[0676] Device-readable medium 1080 may include, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disc (CD) or digital video disc (DVD)), any form of volatile or non-volatile computer-readable memory, and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that can store information, data, and / or instructions used by processing circuit 1070. Device-readable medium 1080 may store any suitable instructions, data, or information, including one or more of an application including a computer program, software, logic, rules, code, tables, etc., and / or other instructions that can be executed by processing circuit 1070 and utilized by network node 1060. Device-readable medium 1080 may be used to store calculations performed by processing circuit 1070 and / or data received via interface 1090. In some embodiments, processing circuit 1070 and device-readable medium 1080 may be considered integrated.

[0677] Interface 1090 is used in the wired or wireless communication of signaling and / or data between network node 1060, network 1006, and / or WD 1010. As shown, interface 1090 comprises (one or more) ports / (one or more) terminals 1094 for sending and receiving data to and from network 1006, for example, over a wired connection. Interface 1090 also includes a radio front-end circuit 1092 that may be coupled to antenna 1062 or, in some embodiments, may be part of antenna 1062. The radio front-end circuit 1092 comprises a filter 1098 and an amplifier 1096. The radio front-end circuit 1092 may be connected to antenna 1062 and processing circuit 1070. The radio front-end circuit may be configured to condition the signals communicated between antenna 1062 and processing circuit 1070. The radio front-end circuit 1092 may receive digital data to be transmitted to other network nodes or WDs via a wireless connection. The radio front-end circuit 1092 may convert the digital data into a radio signal having appropriate channel and bandwidth parameters using a combination of filter 1098 and / or amplifier 1096. The radio signal may then be transmitted via antenna 1062. Similarly, when receiving data, antenna 1062 may collect the radio signal, which is then converted into digital data by radio front-end circuit 1092. The digital data may be passed to processing circuit 1070. In other embodiments, the interface may include different components and / or different combinations of components.

[0678] In some alternative embodiments, network node 1060 may not include a separate radio front-end circuit 1092. Instead, processing circuit 1070 may comprise a radio front-end circuit and may be connected to antenna 1062 without a separate radio front-end circuit 1092. Similarly, in some embodiments, all or part of RF transceiver circuit 1072 may be regarded as part of interface 1090. In yet other embodiments, interface 1090 may include one or more ports or terminals 1094, radio front-end circuit 1092, and RF transceiver circuit 1072 as part of a wireless unit (not shown), and interface 1090 may communicate with baseband processing circuit 1074, which is part of a digital unit (not shown).

[0679] Antenna 1062 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. Antenna 1062 may be coupled to radio front-end circuit 1090 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna 1062 may comprise one or more omnidirectional, sector, or panel antennas operable to transmit / receive wireless signals, for example, between 2 GHz and 66 GHz. Omnidirectional antennas may be used to transmit / receive wireless signals in any direction, sector antennas may be used to transmit / receive wireless signals from devices within a particular area, and panel antennas may be line-of-sight antennas used to transmit / receive wireless signals in a relatively straight line. In some cases, the use of two or more antennas may be referred to as MIMO. In some embodiments, antenna 1062 may be separate from network node 1060 and may be connectable to network node 1060 through an interface or port.

[0680] Antenna 1062, interface 1090, and / or processing circuit 1070 may be configured to perform any receiving operations and / or some acquisition operations described herein as being performed by a network node. Any information, data, and / or signals may be received from a wireless device, another network node, and / or any other network equipment. Similarly, antenna 1062, interface 1090, and / or processing circuit 1070 may be configured to perform any transmitting operations described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to a wireless device, another network node, and / or any other network equipment.

[0681] Power circuit 1087 may comprise a power management circuit or be coupled to a power management circuit and is configured to supply power for performing the functions described herein to the components of network node 1060. Power circuit 1087 may receive power from power source 1086. Power source 1086 and / or power circuit 1087 may be configured to provide power to the various components of network node 1060 in a form suitable for each respective component (e.g., at the voltage and current levels required for each respective component). Power source 1086 may be either included within power circuit 1087 and / or network node 1060 or external to power circuit 1087 and / or network node 1060. For example, network node 1060 may be connectable to an external power source (e.g., an electrical outlet) via an input circuit or interface such as an electrical cable, whereby the external power source supplies power to power circuit 1087. As a further example, power source 1086 may comprise a power source in the form of a battery or battery pack connected to or integrated within power circuit 1087. The battery may provide backup power in the event of a loss of external power. Other types of power sources such as photovoltaic devices may also be used.

[0682] An alternative embodiment of network node 1060 may be responsible for providing some aspects of the functionality of a network node, including any of the functions described herein and / or any of the functions necessary to support the subject matter described herein, and may include additional components other than those shown in FIG. 10. For example, network node 1060 may include user interface equipment for enabling the input of information to network node 1060 and for enabling the output of information from network node 1060. This may enable a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 1060.

[0683] As used herein, a wireless device (WD) refers to a device that is capable of wirelessly communicating with a network node and / or another wireless device, configured and / or operable to do so. Unless otherwise specified, the term WD may be used interchangeably with user equipment (UE) herein. Wireless communication may involve transmitting and / or receiving a wireless signal using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information through the air. In some embodiments, a WD may be configured to transmit and / or receive information without direct human interaction. For example, a WD may be designed to transmit information to a network at a predetermined schedule when triggered by an internal or external event or in response to a request from the network. Examples of WDs include, but are not limited to, smartphones, mobile phones, cell phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback appliances, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptop computers, laptop embedded equipment (LEE), laptop-mounted equipment (LME), smart devices, wireless customer premise equipment (CPE), in-vehicle wireless terminal devices, etc. A WD may support device-to-device (D2D) communication, for example, by implementing 3GPP standards for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X), in which case it may be referred to as a D2D communication device. As another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another WD and / or a network node. In this case, the WD may be a machine-to-machine (M2M) device, and an M2M device may sometimes be referred to as an MTC device in a 3GPP context.As one specific example, the WD can be a UE implementing the 3GPP narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or household or personal electrical appliances (e.g., refrigerators, televisions, etc.), personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, the WD can represent a vehicle or other equipment, and the vehicle or other equipment can monitor its operating status and / or report on its operating status, or other functions associated with its operation are possible. The WD described above can represent an endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Further, the WD described above can be mobile, in which case the device may also be referred to as a mobile device or mobile terminal.

[0684] As shown, the wireless device 1010 includes an antenna 1011, an interface 1014, a processing circuit 1020, a device-readable medium 1030, a user interface device 1032, an auxiliary device 1034, a power source 1036, and a power circuit 1037. The WD 1010 can include one or more sets of the shown components for different wireless technologies supported by the WD 1010, for example, to name just a few, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies. These wireless technologies can be integrated into the same or different chips or sets of chips as other components within the WD 1010.

[0685] Antenna 1011 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals and is connected to interface 1014. In some alternative embodiments, antenna 1011 is separate from WD 1010 and may be connectable to WD 1010 through an interface or port. Antenna 1011, interface 1014, and / or processing circuit 1020 may be configured to perform any of the receive or transmit operations described herein as being performed by the WD. Any information, data, and / or signals may be received from network nodes and / or another WD. In some embodiments, the radio front-end circuitry and / or antenna 1011 may be regarded as an interface.

[0686] As shown, interface 1014 includes a wireless front-end circuit 1012 and an antenna 1011. The wireless front-end circuit 1012 includes one or more filters 1018 and an amplifier 1016. The wireless front-end circuit 1014 is connected to antenna 1011 and processing circuit 1020 and is configured to condition signals communicated between antenna 1011 and processing circuit 1020. The wireless front-end circuit 1012 may be coupled to antenna 1011 or may be part of antenna 1011. In some embodiments, WD 1010 may not include a separate wireless front-end circuit 1012; rather, processing circuit 1020 may include a wireless front-end circuit and may be connected to antenna 1011. Similarly, in some embodiments, some or all of RF transceiver circuit 1022 may be considered part of interface 1014. The wireless front-end circuit 1012 may receive digital data to be transmitted to other network nodes or WDs via a wireless connection. The wireless front-end circuit 1012 may convert the digital data into a wireless signal having appropriate channel and bandwidth parameters using a combination of filters 1018 and / or amplifier 1016. The wireless signal may then be transmitted via antenna 1011. Similarly, when receiving data, antenna 1011 may collect a wireless signal, which may then be converted into digital data by wireless front-end circuit 1012. The digital data may be passed to processing circuit 1020. In other embodiments, the interface may include different components and / or different combinations of components.

[0687] The processing circuit 1020 can include one or more combinations of a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or a combination of hardware, software, and / or encoded logic, operable to provide the WD1010 functionality, either alone or in conjunction with other WD1010 components such as the device-readable medium 1030. Such functionality can include providing any of the various wireless features or benefits described herein. For example, the processing circuit 1020 can execute instructions stored on the device-readable medium 1030 or instructions stored in memory within the processing circuit 1020 to provide the functionality disclosed herein.

[0688] As shown, processing circuit 1020 includes one or more of RF transceiver circuit 1022, baseband processing circuit 1024, and application processing circuit 1026. In other embodiments, the processing circuit may include different components and / or different combinations of components. In some embodiments, the processing circuit 1020 of WD1010 may comprise a system-on-a-chip (SOC). In some embodiments, RF transceiver circuit 1022, baseband processing circuit 1024, and application processing circuit 1026 may be on separate chips or a set of chips. In an alternative embodiment, some or all of baseband processing circuit 1024 and application processing circuit 1026 may be combined to form one chip or a set of chips, and RF transceiver circuit 1022 may be on a separate chip or a set of chips. In yet another alternative embodiment, some or all of RF transceiver circuit 1022 and baseband processing circuit 1024 may be on the same chip or a set of chips, and application processing circuit 1026 may be on a separate chip or a set of chips. In still other alternative embodiments, some or all of RF transceiver circuit 1022, baseband processing circuit 1024, and application processing circuit 1026 may be combined within the same chip or a set of chips. In some embodiments, RF transceiver circuit 1022 may be part of interface 1014. RF transceiver circuit 1022 may condition RF signals for processing circuit 1020.

[0689] In some embodiments, some or all of the functions described herein as being performed by the WD may be provided by a processing circuit 1020 that executes instructions stored on a device-readable medium 1030, which in some embodiments may be a computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by the processing circuit 1020 without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired fashion. In any of those particular embodiments, whether or not executing instructions stored on a device-readable storage medium, the processing circuit 1020 may be configured to perform the functions described. The benefits provided by such functions are enjoyed not limited to the processing circuit 1020 alone, but by the WD1010 as a whole, and / or generally by the end user and the wireless network.

[0690] The processing circuit 1020 may be configured to perform any decision-making operation, computational operation, or similar operation (e.g., some acquisition operations) described herein as being performed by the WD. Such operations as performed by the processing circuit 1020 may include processing information obtained by the processing circuit 1020, e.g., by converting the obtained information to other information, comparing the obtained information or the converted information with information stored by the WD1010, and / or performing one or more operations based on the obtained information or the converted information and as a result of the processing having made a decision.

[0691] The device-readable medium 1030 may be operable to store an application including one or more of a computer program, software, logic, rules, code, tables, etc., and / or other instructions executable by the processing circuit 1020. The device-readable medium 1030 may include a computer memory (e.g., random access memory (RAM) or read-only memory (ROM)), a mass storage medium (e.g., a hard disk), a removable storage medium (e.g., a compact disc (CD) or digital video disc (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that can store information, data, and / or instructions used by the processing circuit 1020. In some embodiments, the processing circuit 1020 and the device-readable medium 1030 may be considered integrated.

[0692] The user interface device 1032 may provide components that enable a human user to interact with the WD1010. Such interaction can be in many forms, such as visual, auditory, tactile, etc. The user interface device 1032 may be operable to create an output to the user and to enable the user to provide an input to the WD1010. The type of interaction may vary depending on the type of user interface device 1032 installed on the WD1010. For example, if the WD1010 is a smartphone, the interaction may be via a touch screen, and if the WD1010 is a smart meter, the interaction may be through a screen that provides usage (e.g., the number of gallons used) or a speaker that provides an audible alarm (e.g., if smoke is detected). The user interface device 1032 may include an input interface, devices and circuits, as well as an output interface, devices and circuits. The user interface device 1032 is configured to enable the input of information to the WD1010 and is connected to the processing circuit 1020 to enable the processing circuit 1020 to process the input information. The user interface device 1032 may include, for example, a microphone, a proximity or other sensor, a key / button, a touch display, one or more cameras, a USB port, or other input circuits. The user interface device 1032 is also configured to enable the output of information from the WD1010 and to enable the processing circuit 1020 to output information from the WD1010. The user interface device 1032 may include, for example, a speaker, a display, a vibration circuit, a USB port, a headphone interface, or other output circuits. Using one or more input and output interfaces, devices, and circuits of the user interface device 1032, the WD1010 may communicate with an end user and / or a wireless network, enabling the end user and / or the wireless network to benefit from the functions described herein.

[0693] Auxiliary device 1034 is operable to provide more specific functions that may not generally be performed by the WD. This may include specialized sensors for performing measurements for various purposes, interfaces for additional types of communication such as wired communication, and the like. The inclusion of components of the auxiliary device 1034, and the types of components of the auxiliary device 1034, may vary depending on the embodiment and / or scenario.

[0694] Power source 1036 may, in some embodiments, be in the form of a battery or battery pack. Other types of power sources may also be used, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a battery. The WD 1010 may further include a power circuit 1037 for distributing power from the power source 1036 to various parts of the WD 1010 that require power from the power source 1036 to perform any of the functions described or indicated herein. The power circuit 1037 may, in some embodiments, include a power management circuit. The power circuit 1037 may alternatively or additionally be operable to receive power from an external power source, in which case the WD 1010 may be connectable to an external power source (such as an electrical outlet) via an input circuit or interface such as a power cable. The power circuit 1037 may also, in some embodiments, be operable to distribute power from an external power source to the power source 1036. This may be, for example, for charging the power source 1036. The power circuit 1037 may perform any formatting, converting, or other modification on the power from the power source 1036 to make it suitable for each component of the WD 1010 to which the power is supplied.

[0695] FIG. 11 is a schematic diagram showing a user device according to some embodiments.

[0696] FIG. 11 shows one embodiment of a UE according to various aspects described herein. A user equipment or UE as used herein does not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended for sale to, or operation by, a human user, but may not be associated with, or initially associated with, a particular human user. Alternatively, a UE may represent a device (e.g., a smart power meter) that is not intended for sale to, or operation by, an end user, but may be associated with a user or operated for the benefit of a user. UE 1100 can be any UE identified by the Third Generation Partnership Project (3GPP), including an NB-IoT UE, a machine type communication (MTC) UE, and / or an extended MTC (eMTC) UE. The UE 1100 shown in FIG. 11 is an example of a WD configured for communication according to one or more communication standards published by 3GPP, such as the GSM, UMTS, LTE, and / or 5G standards of the Third Generation Partnership Project (3GPP). As described above, the terms WD and UE may be used interchangeably. Thus, FIG. 11 shows a UE, but the components described herein are equally applicable to a WD, and vice versa.

[0697] In FIG. 11, UE 1100 includes a processing circuit 1101 operably coupled to an input / output interface 1105, a radio frequency (RF) interface 1109, a network connection interface 1111, a memory 1115 including a random access memory (RAM) 1117, a read-only memory (ROM) 1119, a storage medium 1121, etc., a communication subsystem 1131, a power supply 1133, and / or any other components, or any combination thereof. The storage medium 1121 includes an operating system 1123, an application program 1125, and data 1127. In other embodiments, the storage medium 1121 may include other similar types of information. Some UEs may utilize all of the components shown in FIG. 11 or only a subset of those components. The level of integration between components may vary from UE to UE. Further, some UEs may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0698] In FIG. 11, the processing circuit 1101 may be configured to process computer instructions and data. The processing circuit 1101 may be any sequential state machine operable to execute machine instructions stored in the memory as a machine-readable computer program, such as one or more hardware-implemented state machines (e.g., in discrete logic, FPGA, ASIC, etc.), programmable logic together with appropriate firmware, a microprocessor or digital signal processor (DSP) together with appropriate software, one or more program embedded, general-purpose processors, or any combination of the above. For example, the processing circuit 1101 may include two central processing units (CPUs). Data may be information in a form suitable for use by a computer.

[0699] In the illustrated embodiment, the input / output interface 1105 can be configured to provide a communication interface to an input device, an output device, or an input / output device. The UE 1100 can be configured to use an output device via the input / output interface 1105. The output device can use the same type of interface port as the input device. For example, a USB port can be used to provide input to and output from the UE 1100. The output device can be a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smart card, another output device, or any combination thereof. The UE 1100 can be configured to use an input device via the input / output interface 1105 to enable a user to capture information to the UE 1100. The input device can include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smart card, etc. The presence-sensitive display can include a capacitive or resistive touch sensor for detecting input from a user. The sensor can be, for example, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, a light sensor, a proximity sensor, another similar sensor, or any combination thereof. For example, the input device can be an accelerometer, a magnetometer, a digital camera, a microphone, and a light sensor.

[0700] In FIG. 11, the RF interface 1109 can be configured to provide a communication interface to RF components such as a transmitter, a receiver, and an antenna. The network connection interface 1111 can be configured to provide a communication interface to the network 1143a. The network 1143a can include wired and / or wireless networks such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a communication network, another similar network, or any combination thereof. For example, the network 1143a can include a Wi-Fi network. The network connection interface 1111 can be configured to include a receiver and a transmitter interface used to communicate with one or more other devices on a communication network according to one or more communication protocols such as Ethernet, TCP / IP, SONET, ATM, etc. The network connection interface 1111 can implement receiver and transmitter functions suitable for a communication network link (e.g., optical, electrical, etc.). The transmitter and receiver functions can share circuit components, software, or firmware, or alternatively, can be implemented separately.

[0701] RAM 1117 can be configured to interface with the processing circuit 1101 via the bus 1102 to provide storage or caching of data or computer instructions during the execution of software programs such as an operating system, application programs, and device drivers. ROM 1119 can be configured to provide computer instructions or data to the processing circuit 1101. For example, ROM 1119 can be configured to store invariant low-level system code or data for basic system functions such as basic input / output (I / O), startup, or reception of keystrokes from a keyboard, stored in non-volatile memory. The storage medium 1121 can be configured to include memory such as RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disk, optical disk, floppy disk, hard disk, removable cartridge, or flash drive. In one example, the storage medium 1121 can be configured to include an operating system 1123, an application program 1125 such as a web browser application, widget or gadget engine, or another application, and a data file 1127. The storage medium 1121 can store any of a variety of operating systems or combinations of operating systems for use by the UE 1100.

[0702] The memory medium 1121 can be configured to include several physical drive units, such as a redundant array of independent disks (RAID), a floppy disk drive, a flash memory, a USB flash drive, an external hard disk drive, a thumb drive, a pen drive, a key drive, a high-definition digital versatile disc (HD-DVD) optical disc drive, an internal hard disk drive, a Blu-Ray optical disc drive, a holographic digital data storage (HDDS) optical disc drive, an external mini dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, a subscriber identity module or a removable user identity information (SIM / RUIM) module such as a smart card memory, other memories, or any combination thereof. The memory medium 1121 can enable the UE1100 to access computer-executable instructions, application programs, etc. stored in a temporary or non-temporary memory medium, offload data, or upload data. A manufactured product such as a manufactured product using a communication system can be tangibly embodied in the memory medium 1121, and the memory medium 1121 can comprise a device-readable medium.

[0703] In FIG. 11, the processing circuit 1101 can be configured to communicate with the network 1143b using the communication subsystem 1131. The network 1143a and the network 1143b can be the same one or more networks or different one or more networks. The communication subsystem 1131 can be configured to include one or more transceivers used to communicate with the network 1143b. For example, the communication subsystem 1131 can be configured to include one or more transceivers for communicating with one or more remote transceivers of another WD, UE, or base station capable of wireless communication, such as another WD, UE, or base station of a radio access network (RAN), according to one or more communication protocols such as IEEE802.11, CDMA, WCDMA, GSM, LTE, UTRAN, WiMax. Each transceiver can include a transmitter 1133 and / or a receiver 1135 for implementing a transmitter function or a receiver function suitable for a RAN link (such as frequency allocation). Further, the transmitter 1133 and the receiver 1135 of each transceiver can share circuit components, software, or firmware, or alternatively, can be implemented separately.

[0704] In the illustrated embodiment, the communication functions of the communication subsystem 1131 can include data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as the use of the Global Positioning System (GPS) for determining location, other similar communication functions, or any combination thereof. For example, the communication subsystem 1131 can include cellular communication, Wi-Fi communication, Bluetooth communication, and GPS communication. The network 1143b can include wired and / or wireless networks such as a local area network (LAN), a wide area network (WAN), a computer network, a wireless network, a communication network, other similar networks, or any combination thereof. For example, the network 1143b can be a cellular network, a Wi-Fi network, and / or a near-field network. The power supply 1113 can be configured to provide alternating current (AC) or direct current (DC) power to the components of the UE 1100.

[0705] The features, benefits, and / or functions described herein can be implemented in one of the components of the UE 1100 or can be divided across multiple components of the UE 1100. Further, the features, benefits, and / or functions described herein can be implemented in any combination of hardware, software, or firmware. In one example, the communication subsystem 1131 can be configured to include any of the components described herein. Further, the processing circuit 1101 can be configured to communicate with any of such components over the bus 1102. In another example, any of such components can be represented by program instructions stored in a memory that, when executed by the processing circuit 1101, perform the corresponding functions described herein. In another example, the functions of any of such components can be divided between the processing circuit 1101 and the communication subsystem 1131. In another example, the non-computation-intensive functions of any of such components can be implemented in software or firmware, and the computation-intensive functions can be implemented in hardware.

[0706] FIG. 12 is a schematic diagram showing a virtualized environment according to some embodiments.

[0707] FIG. 12 is a schematic block diagram showing a virtualized environment 1200 in which functions implemented according to some embodiments can be virtualized. In this context, virtualizing means creating a virtual version of a device or apparatus that may include virtualizing a hardware platform, a memory device, and networking resources. As used herein, virtualization can be applied to a node (e.g., a virtualized base station or a virtualized radio access node), or to a device (e.g., a UE, a wireless device, or any other type of communication device) or a component of that device, and at least a portion of the functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, or containers running on one or more physical processing nodes in one or more networks).

[0708] In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines hosted in one or more virtual environments 1200 hosted by one or more of the hardware nodes 1230. Further, in embodiments where the virtual node is not a radio access node or does not require wireless connectivity (e.g., a core network node), the network node can be fully virtualized.

[0709] The functionality may be implemented by one or more applications 1220 (alternatively, sometimes referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) that are operable to implement some of the features, functionality, and / or benefits of some of the embodiments disclosed herein. The application 1220 is operated in a virtualized environment 1200 that provides hardware 1230 comprising a processing circuit 1260 and a memory 1290-1. The memory 1290-1 includes instructions 1295 executable by the processing circuit 1260 such that the application 1220 is operable to provide one or more of the features, benefits, and / or functionality disclosed herein.

[0710] The virtualized environment 1200 comprises a general-purpose or special-purpose network hardware device 1230 that includes a set of one or more processors or processing circuitry 1260, where the set of one or more processors or processing circuitry 1260 can be a commercial off-the-shelf (COTS) processor, a dedicated application-specific integrated circuit (ASIC), or any other type of processing circuitry that includes digital or analog hardware components or dedicated processors. Each hardware device can include a memory 1290-1, which can be non-persistent memory for temporarily storing instructions 1295 or software executed by the processing circuitry 1260. Each hardware device can include one or more network interface controllers (NICs) 1270, also known as network interface cards, where the network interface controller (NIC) 1270 includes a physical network interface 1280. Each hardware device can also include a non-transitory, persistent, machine-readable storage medium 1290-2 that stores software 1295 and / or instructions executable by the processing circuitry 1260. The software 1295 can include any type of software, including software for instantiating one or more virtualization layers (also called hypervisors) 1250, software for executing virtual machines 1240, and software that enables it to perform the functions, features, and / or benefits described in relation to some of the embodiments described herein.

[0711] The virtual machine 1240 comprises virtual processing, virtual memory, virtual networking or interfaces, and virtual storage areas, and can be operated by a corresponding virtualization layer 1250 or hypervisor. Different embodiments of instances of virtual appliances 1220 can be implemented on one or more of the virtual machines 1240, and the implementation can be done in different ways.

[0712] During operation, processing circuit 1260 executes software 1295 to instantiate a hypervisor or virtualization layer 1250, which may sometimes be referred to as a virtual machine monitor (VMM). The virtualization layer 1250 may present a virtual operating platform to virtual machines 1240 that appears as networking hardware.

[0713] As shown in FIG. 12, the hardware 1230 can be a stand-alone network node with general or specific components. The hardware 1230 can include an antenna 12225 and can implement some functions via virtualization. Alternatively, the hardware 1230 can be part of a larger class of hardware (such as in the case of a data center or customer premise equipment (CPE)) that is managed via a management and orchestration (MANO) 12100 in which multiple hardware nodes cooperate and particularly oversee the lifecycle management of the application 1220.

[0714] The virtualization of hardware is referred to as network function virtualization (NFV) in some contexts. NFV can be used to consolidate many network equipment types onto industry-standard high-volume server hardware, physical switches, and physical storage that can be located within data centers and customer premise equipment.

[0715] In the context of NFV, the virtual machines 1240 can be software implementations of physical machines that run programs as if those programs were running on non-virtualized physical machines. Each of the virtual machines 1240 forms a separate virtual network element (VNE) with that part of the hardware 1230 that executes the virtual machine, whether it is hardware dedicated to that virtual machine and / or hardware shared by that virtual machine with other virtual machines among the virtual machines 1240.

[0716] Furthermore, in the context of NFV, a virtual network function (VNF) is responsible for handling a proprietary network function operating in one or more virtual machines 1240 over a hardware networking infrastructure 1230, corresponding to the application 1220 in FIG. 12.

[0717] In some embodiments, one or more radio units 12200, each including one or more transmitters 12220 and one or more receivers 12210, may be coupled to one or more antennas 12225. The radio unit 12200 may communicate directly with the hardware node 1230 via one or more suitable network interfaces and may be used in combination with virtual components to provide a virtual node having radio capabilities, such as a radio access node or a base station.

[0718] In some embodiments, some signaling may be implemented using a control system 12230 that may alternatively be used for communication between the hardware node 1230 and the radio unit 12200.

[0719] FIG. 13 is a schematic diagram showing a communication network connected to a host computer via an intermediate network according to some embodiments.

[0720] Referring to FIG. 13, according to one embodiment, a communication network 1310, such as a 3GPP type cellular network, includes an access network 1311, such as a radio access network, and a core network 1314. The access network 1311 includes a plurality of base stations 1312a, 1312b, 1312c, such as NB, eNB, gNB, or other types of radio access points, each defining a corresponding coverage area 1313a, 1313b, 1313c. Each base station 1312a, 1312b, 1312c is connectable to the core network 1314 over a wired or wireless connection 1315. A first UE 1391 located in the coverage area 1313c is configured to wirelessly connect to the corresponding base station 1312c or be paged by the corresponding base station 1312c. A second UE 1392 in the coverage area 1313a is wirelessly connectable to the corresponding base station 1312a. Although a plurality of UEs 1391, 1392 are shown in this example, the disclosed embodiments are equally applicable to situations where only one UE is in the coverage area or only one UE is connected to the corresponding base station 1312a or 1312b or 1312c.

[0721] The communication network 1310 is itself connected to a host computer 1330, which may be embodied in the hardware and / or software of a stand-alone server, a cloud-implemented server, a distributed server, or as processing resources in a server farm. The host computer 1330 may be under the ownership or control of a service provider, or may be operated by or on behalf of a service provider. The connections 1321 and 1322 between the communication network 1310 and the host computer 1330 may extend directly from the core network 1314 to the host computer 1330, or may proceed via an optional intermediate network 1320. The intermediate network 1320 may be one of a public network, a private network, or a hosted network, or a combination of two or more of them, and the intermediate network 1320 may, if any, be a backbone network or the Internet, and in particular, the intermediate network 1320 may include two or more sub-networks (not shown).

[0722] The communication system of FIG. 13 enables connectivity between the connected UEs 1391, 1392 and the host computer 1330 as a whole. The connectivity can be described as an over-the-top (OTT) connection 1350. The host computer 1330 and the connected UEs 1391, 1392 are configured to communicate data and / or signaling via the OTT connection 1350, mediated by the access network 1311, the core network 1314, any intermediate network 1320, and possible further infrastructure (not shown). The OTT connection 1350 can be transparent in the sense that the participating communication devices through which the OTT connection 1350 passes are unaware of the routing of the uplink and downlink communications. For example, the base station 1312a or 1312b or 1312c may not be informed or need not be informed about the past routing of the incoming downlink communication with data generated from the host computer 1330 that is to be forwarded (e.g., handed over) to the connected UE 1391. Similarly, the base station 1312a or 1312b or 1312c need not be aware of the future routing of the outgoing uplink communication originating from the UE 1391 and directed towards the host computer 1330.

[0723] FIG. 14 is a schematic diagram showing a host computer communicating with a user equipment via a base station over a partial wireless connection, according to some embodiments.

[0724] Next, an exemplary implementation of the UE, base station, and host computer described in the previous paragraph according to one embodiment will be described with reference to FIG. 14. In communication system 1400, host computer 1410 comprises hardware 1415 including a communication interface 1416 configured to set up and maintain a wired or wireless connection with an interface of different communication devices of communication system 1400. Host computer 1410 further comprises a processing circuit 1418 that may have storage and / or processing capabilities. In particular, processing circuit 1418 may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. Host computer 1410 further comprises software 1411 stored on or accessible by host computer 1410 and executable by processing circuit 1418. Software 1411 includes host application 1412. Host application 1412 may be operable to provide services to remote users such as UE 1430 that connects via an OTT connection 1450 terminating at UE 1430 and host computer 1410. When providing services to a remote user, host application 1412 may provide user data transmitted using OTT connection 1450.

[0725] Communication system 1400 further includes a base station 1420 provided in the communication system, and the base station 1420 includes hardware 1425 that enables the base station 1420 to communicate with the host computer 1410 and the UE 1430. The hardware 1425 includes a communication interface 1426 for setting up and maintaining a wired or wireless connection with an interface of different communication devices in the communication system 1400, and a wireless interface 1427 for setting up and maintaining at least a wireless connection 1470 with a UE 1430 located in a coverage area (not shown in FIG. 14) served by the base station 1420. The communication interface 1426 can be set to facilitate the connection 1460 to the host computer 1410. The connection 1460 can be direct, or the connection 1460 can pass through a core network of the communication system (not shown in FIG. 14) and / or one or more intermediate networks external to the communication system. In the illustrated embodiment, the hardware 1425 of the base station 1420 further includes a processing circuit 1428, and the processing circuit 1428 can include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The base station 1420 further has software 1421 stored internally or accessible via an external connection.

[0726] The communication system 1400 further includes the UE 1430 already mentioned. The hardware 1435 of the UE 1430 may include a radio interface 1437 configured to set up and maintain a radio connection 1470 with a base station serving the coverage area where the UE 1430 is currently located. The hardware 1435 of the UE 1430 further includes a processing circuit 1438, which may include one or more programmable processors, application-specific integrated circuits, field-programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The UE 1430 further comprises software 1431 stored in or accessible by the UE 1430 and executable by the processing circuit 1438. The software 1431 includes a client application 1432. The client application 1432 may be operable to provide services to a human or non-human user via the UE 1430 under the support of the host computer 1410. In the host computer 1410, the running host application 1412 may communicate with the running client application 1432 via an OTT connection 1450 that terminates at the UE 1430 and the host computer 1410. When providing services to the user, the client application 1432 may receive request data from the host application 1412 and provide user data in response to the request data. The OTT connection 1450 may transfer both the request data and the user data. The client application 1432 may interact with the user to generate the user data provided by the client application 1432.

[0727] Note that the host computer 1410, base station 1420, and UE 1430 shown in FIG. 14 can be the same as or equivalent to the host computer 1330, one of the base stations 1312a, 1312b, 1312c in FIG. 13, and one of the UEs 1391, 1392, respectively. That is, the operations inside these entities can be as shown in FIG. 14, and separately, the surrounding network topology can be the same as that in FIG. 13.

[0728] In FIG. 14, the OTT connection 1450 is abstractly depicted to show communication between the host computer 1410 and the UE 1430 via the base station 1420 without explicit mention of the intermediary device and the exact routing of messages through these devices. The network infrastructure can determine the routing, and the network infrastructure can be configured to hide the routing from the UE 1430 or from the service provider operating the host computer 1410, or both. While the OTT connection 1450 is active, the network infrastructure can further make a determination to dynamically change the routing (e.g., based on network load distribution considerations or reconfiguration).

[0729] The wireless connection 1470 between the UE 1430 and the base station 1420 complies with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of the OTT services provided to the UE 1430 using the OTT connection 1450 in which the wireless connection 1470 forms the last segment. More precisely, some embodiments herein may enable group message correction and group message cancellation on MBMS, MBS, and MBS that interoperate with MBMS. Some embodiments herein may remedy the drawbacks within the current group message correction via MBMS (it is not feasible to replace the group message using session property updates to the BM-SC). Some embodiments herein may improve the limitations regarding the current group message cancellation via MBMS (SCEF session termination to the BM-SC, however, the UE is not aware of the cancellation of the group message).

[0730] Measurement procedures can be provided for the purpose of monitoring data rate, latency, and other factors that are improved by one or more embodiments. There may further be optional network functions for reconfiguring the OTT connection 1450 between the host computer 1410 and the UE 1430 in response to variations in measurement results. The measurement procedures and / or the network functions for reconfiguring the OTT connection 1450 can be implemented in the software 1411 and hardware 1415 of the host computer 1410 or in the software 1431 and hardware 1435 of the UE 1430, or both. In an embodiment, a sensor (not shown) can be deployed in or associated with a communication device through which the OTT connection 1450 passes, and the sensor can participate in the measurement procedure by providing values of the monitored quantities exemplified above or by providing values of other physical quantities that the software 1411, 1431 can calculate or estimate the monitored quantity. The reconfiguration of the OTT connection 1450 can include message format, retransmission settings, preferred routing, etc., and the reconfiguration need not affect the base station 1420 and can be unknown or imperceptible to the base station 1420. Such procedures and functions are known and practiced in the art. In some embodiments, the measurement can involve proprietary UE signaling that facilitates measurement of the host computer 1410 such as throughput, propagation time, latency, etc. The measurement can be implemented in that the software 1411 and 1431 cause messages, particularly empty or "dummy" messages, to be transmitted using the OTT connection 1450 while the software 1411 and 1431 monitor propagation time, errors, etc.

[0731] FIG. 15 is a schematic diagram showing a method implemented in a communication system including a host computer, a base station, and a user equipment according to some embodiments.

[0732] FIG. 15 is a flowchart showing a method implemented in a communication system according to an embodiment. The communication system may be the one described with reference to FIGS. 13 and 14 and includes a host computer, a base station, and a UE. For simplicity of the present disclosure, only the drawing reference to FIG. 15 is included in this section. In step 1510, the host computer provides user data. In an optional sub-step 1511 of step 1510, the host computer provides user data by executing a host application. In step 1520, the host computer initiates a transmission that conveys the user data to the UE. In an optional step 1530, the base station transmits the user data conveyed in the transmission initiated by the host computer to the UE according to the teachings of the embodiments described throughout the present disclosure. In an also optional step 1540, the UE executes a client application associated with the host application executed by the host computer.

[0733] FIG. 16 is a schematic diagram showing a method implemented in a communication system including a host computer, a base station, and a user equipment according to some embodiments.

[0734] FIG. 16 is a flowchart showing a method implemented in a communication system according to an embodiment. The communication system may include a host computer, a base station, and a UE, as described with reference to FIGS. 13 and 14. For simplicity of the present disclosure, only the drawing reference to FIG. 16 is included in this section. In step 1610 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides user data by executing a host application. In step 1620, the host computer initiates a transmission that conveys the user data to the UE. The transmission may pass through the base station in accordance with the teachings of the embodiments described throughout the present disclosure. In step 1630 (which may be optional), the UE receives the user data conveyed in the transmission.

[0735] FIG. 17 is a schematic diagram showing a method implemented in a communication system including a host computer, a base station, and a user equipment according to some embodiments.

[0736] FIG. 17 is a flowchart showing a method implemented in a communication system according to one embodiment. The communication system may include a host computer, a base station, and a UE as described with reference to FIGS. 13 and 14. For simplicity of the present disclosure, only the drawing reference to FIG. 17 is included in this section. In optional step 1710, the UE receives input data provided by the host computer. Additionally or alternatively, in step 1720, the UE provides user data. In optional sub-step 1721 of step 1720, the UE provides user data by executing a client application. In optional sub-step 1711 of step 1710, the UE executes a client application that provides user data in response to the received input data provided by the host computer. When providing user data, the executed client application may further consider user input received from the user. Regardless of the particular manner in which the user data is provided, the UE initiates, in optional sub-step 1730, the transmission of the user data to the host computer. In step 1740 of the method, the host computer receives the user data transmitted from the UE in accordance with the teachings of the embodiments described throughout the present disclosure.

[0737] FIG. 18 is a schematic diagram showing a method implemented in a communication system including a host computer, a base station, and a user equipment according to some embodiments.

[0738] FIG. 18 is a flowchart showing a method implemented in a communication system according to an embodiment. The communication system may include a host computer, a base station, and a UE as described with reference to FIGS. 13 and 14. For simplicity of the present disclosure, only the drawing reference to FIG. 18 is included in this section. In optional step 1810, according to the teachings of the embodiments described throughout the present disclosure, the base station receives user data from the UE. In optional step 1820, the base station initiates transmission of the received user data to the host computer. In optional step 1830, the host computer receives the user data carried in the transmission initiated by the base station.

[0739] Furthermore, the present disclosure may also provide a carrier containing a computer program as described above, and the carrier is one of an electronic signal, an optical signal, a wireless signal, or a computer-readable storage medium. The computer-readable storage medium can be, for example, an optical compact disc such as RAM (Random Access Memory), ROM (Read Only Memory), flash memory, magnetic tape, CD-ROM, DVD, Blu-ray Disc, or an electronic memory device.

[0740] The techniques described herein can be implemented by various means such that a device implementing one or more functions of the corresponding device described in one embodiment includes not only the means of the prior art but also the means for implementing one or more functions of the corresponding device described in that embodiment, and the device can include separate means for each individual function or means configured to perform two or more functions. For example, these techniques can be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or a combination thereof. In the case of firmware or software, the implementation can be through modules (e.g., procedures, functions, etc.) that execute the functions described herein.

[0741] Exemplary embodiments of the present specification have been described above with respect to block diagrams and flowcharts of methods and apparatuses. It will be understood that each block of the block diagrams and flowcharts, as well as combinations of blocks in the block diagrams and flowcharts, can be implemented by various means including computer program instructions. These computer program instructions can be loaded onto a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus for manufacturing a machine, such that the instructions executed on the computer or other programmable data processing apparatus create means for implementing the functions specified in one or more blocks of the flowchart.

[0742] Furthermore, although the operations are illustrated in a particular order, this should not be construed as requiring that such operations be performed in the particular order shown or in a sequential order, or that all of the illustrated operations be performed, for achieving desirable results. In some situations, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above description, these should not be construed as limitations on the scope of the subject matter described herein, but rather as descriptions and interpretations of features that may be specific to a particular embodiment. Some features described in the context of separate embodiments 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 separately in multiple embodiments, or in any suitable sub-combination.

[0743] Although this specification contains many details of particular implementations, these should not be construed as limitations on the scope of any implementation or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular implementations. Some features described herein in the context of separate embodiments 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 separately in multiple embodiments, or in any suitable sub-combination. Moreover, features may be described above as acting in some combinations and even initially claimed as such, but one or more features from a claimed combination may in some cases be deleted from that combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination.

[0744] As technology progresses, it will be apparent to those skilled in the art that inventive concepts may be implemented in various ways. The embodiments described above are provided for purposes of illustration and not limitation, and it should be understood that modifications and variations can be made without departing from the spirit and scope of the present disclosure as will be readily understood by those skilled in the art. Such modifications and variations are considered to be within the scope of the present disclosure and the appended claims. The scope of protection of the present disclosure is defined by the appended claims.

Claims

1. A method executed by a public node, comprising: receiving a group message request from an application node (202), wherein when the group message request is for modification of group message delivery and includes a group message payload, the method further comprises: converting the group message payload into a file (204); and sending the file to a second broadcast multicast node (206); alternatively, when the group message request is for cancellation of group message delivery, the method further comprises: sending a first instruction for cancellation of file delivery to a third broadcast multicast node (264), or sending an HTTP deletion for cancellation of file delivery to the second broadcast multicast node (266). A method.

2. The method according to claim 1, wherein the determined file metadata is used as metadata information of the file.

3. The method according to claim 2, wherein the determined file metadata includes a file uniform resource locator (URL) and / or a file uniform resource identifier (URI).

4. The method according to any one of claims 1 to 3, wherein the capture mode or the object acquisition method is set to pull.

5. The method according to any one of claims 1 to 4, wherein the capture mode or the object acquisition method is set to push.

6. When the capture mode or the object acquisition method is set to pull, sending the file to the second broadcast multicast node comprises: sending a second instruction for update of the file to a third broadcast multicast node, wherein the third broadcast multicast node sends a third instruction based on the second instruction to the second broadcast multicast node, and sending the second instruction for update of the file (222); receiving a request for fetching the file from the second broadcast multicast node (224); and sending a response including the file to the second broadcast multicast node (226). The method according to any one of claims 1 to 5, comprising **Claim 7** The method according to claim 6, wherein the second instruction is a property or parameter having a refresh or update value within session parameters for notifying the second broadcast multicast node regarding a refresh of the file. **Claim 8** When the capture mode or object acquisition method is set to push, sending the file to the second broadcast multicast node Pushing the file to the second broadcast multicast node (242) The method according to any one of claims 1 to 7, comprising **Claim 9** The method according to any one of claims 1 to 8, wherein the file is included in a file list. **Claim 10** The method according to any one of claims 1 to 9, wherein the first instruction is a property or parameter having a cancel value for notifying the second broadcast multicast node regarding cancellation of file distribution. **Claim 11** The public node is a network exposure function (NEF), or a combined NEF and service capability exposure function (SCEF) The method according to any one of claims 1 to 10, comprising at least one of. **Claim 12** The method according to any one of claims 1 to 11, wherein the second broadcast multicast node includes a multicast / broadcast service transport function (MBSTF). **Claim 13** The method according to any one of claims 1 to 12, wherein the third broadcast multicast node includes a multicast / broadcast service function (MBSF). **Claim 14** The method according to any one of claims 1 to 13, wherein the group message request includes a group message modification request having a requested action set to modification or cancellation. **Claim 15** The method according to any one of claims 1 to 14, wherein the group message request includes a group message modification request or a group message cancellation request. **Claim 16** A method performed by a second broadcast multicast node, comprising Receiving a file from a public node, or receiving an HTTP deletion to cancel file delivery from the public node, or receiving a first instruction to cancel file delivery from a third broadcast / multicast node, wherein the file is converted from a group message payload, and the group message payload is included in a group message request instructing modification or cancellation of group message delivery from an application node to the public node, receiving the file, or receiving the HTTP deletion, or receiving the first instruction (402) A method comprising. **Claim 17** Encoding the file and using the file to replace the original file when the file is received and group message delivery has not started, wherein the file is to be delivered after the group message delivery starts, encoding the file and using the file to replace the original file (404) The method according to claim 16, further comprising. **Claim 18** Encoding the file, stopping ongoing group message delivery, and starting delivery of the file when the file is received and the group message delivery has started, or starting delivery of the file after the ongoing group message has been delivered (414) The method according to claim 16 or 17, further comprising. **Claim 19** Stopping file delivery and / or notifying a multicast / broadcast service (MBS) client regarding cancellation of file delivery when the first instruction or the HTTP deletion is received and the group message delivery has started (444) The method according to any one of claims 16 to 18, further comprising. **Claim 20** Canceling file delivery and / or notifying a multicast / broadcast service (MBS) client regarding cancellation of file delivery when the first instruction or the HTTP deletion is received and group message delivery has not started (454) The method according to any one of claims 16 to 19, further comprising.

21. The method according to claim 19 or 20, wherein the cancellation is distributed to at least one MBS client within or outside the bandwidth of the MBS session.

22. The method according to any one of claims 16 to 21, wherein the determined file metadata is used as metadata information of the file.

23. The method according to claim 22, wherein the determined file metadata includes a file uniform resource locator (URL) and / or a file uniform resource identifier (URI).

24. When the capture mode or the object acquisition method is set to pull, receiving the file from the public node includes: Receiving a third instruction (462) based on a second instruction of an update of the file from the third broadcast multicast node; Sending a request to the public node to fetch the file (464); Receiving the file from the public node (466). The method according to any one of claims 16 to 23.

25. The method according to claim 24, wherein the second instruction is a property or parameter having a refresh or update value for notifying the second broadcast multicast node regarding a refresh of the file.

26. When the capture mode or the object acquisition method is set to push, receiving the file from the public node includes: Receiving the file pushed by the public node. The method according to any one of claims 16 to 25.

27. The method according to any one of claims 16 to 26, wherein the file is included in a file list.

28. The method according to any one of claims 16 to 27, wherein the first instruction is a property or parameter having a cancellation value for notifying the second broadcast multicast node regarding cancellation of file distribution.

29. The method according to any one of claims 16 to 28, wherein the public node includes a NEF, or a combined NEF and SCEF.

30. The method according to any one of claims 16 to 29, wherein the second broadcast multicast node includes an MBSTF.

31. The method according to any one of claims 16 to 30, wherein the third broadcast multicast node includes an MBSP.

32. The method according to any one of claims 16 to 31, wherein the group message request includes a group message modification request having a requested action set to modification or cancellation.

33. The method according to any one of claims 16 to 32, wherein the group message request includes a group message modification request or a group message cancellation request.

34. A method (500) performed by a third broadcast multicast node, comprising: receiving a second instruction for updating a file or a first instruction for canceling file distribution from a public node, wherein the file is converted from a group message payload, and the group message payload is included in a group message request instructing modification or cancellation of group message distribution from an application node to the public node, receiving a second instruction for updating a file or a first instruction for canceling file distribution (502); sending the second instruction or the first instruction to a second broadcast multicast node (504); The method (500) includes.

35. further comprising, when the first instruction is received, notifying a multicast / broadcast service (MBS) client regarding cancellation of file distribution (506). The method according to claim 34, further comprising.

36. The method according to claim 35, wherein the cancellation is distributed to at least one MBS client within or outside the bandwidth of the MBS session.

37. The method according to any one of claims 34 to 36, wherein the first instruction is a property or parameter having a cancellation value for notifying the second broadcast multicast node regarding cancellation of file distribution.

38. The method according to any one of claims 34 to 37, wherein the second instruction is a property or parameter having a refresh or update value within session parameters for notifying the second broadcast multicast node regarding the refresh of the file.

39. The method according to any one of claims 34 to 38, wherein the public node includes a NEF, or a combined NEF and SCEF.

40. The method according to any one of claims 34 to 39, wherein the second broadcast multicast node includes an MBSTF.

41. The method according to any one of claims 34 to 40, wherein the third broadcast multicast node includes an MBSF.

42. The method according to any one of claims 34 to 41, wherein the group message request includes a group message modification request having a requested action set to modification or cancellation.

43. The method according to any one of claims 34 to 42, wherein the group message request includes a group message modification request or a group message cancellation request.

44. A method (600) executed by a user equipment, comprising: Receiving a message from a second broadcast multicast node or a third broadcast multicast node, wherein the message includes a cancellation of file distribution (602) The method (600) comprising.

45. The method according to claim 44, wherein the cancellation is received within the bandwidth of a multicast / broadcast service (MBS) session or outside the bandwidth of the MBS session.

46. The method according to claim 44 or 45, wherein the user equipment includes an MBS client.

47. The method according to any one of claims 44 to 46, wherein the second broadcast multicast node includes an MBSTF and the third broadcast multicast node includes an MBSF.

48. A public node (800), comprising: A processor (821); A memory (822) coupled to the processor (821) comprising, wherein the memory (822) contains instructions executable by the processor (821), whereby the publishing node (800) is operable to receive a group message request from an application node and to operate so as to when the group message request pertains to a modification of group message delivery and includes a group message payload, the method further comprises converting the group message payload into a file, and sending the file to a second broadcast multicast node or when the group message request pertains to cancellation of group message delivery, the method further comprises sending a first instruction for cancellation of file delivery to a third broadcast multicast node, or sending an HTTP deletion to the second broadcast multicast node to cancel file delivery a publishing node (800). **Claim 49** The publishing node according to claim 48, further operable to execute the method according to any one of claims 2 to 15. **Claim 50** A second broadcast multicast node (800), comprising a processor (821), and a memory (822) coupled to the processor (821), wherein the memory (822) contains instructions executable by the processor (821), whereby the second broadcast multicast node (800) is operable to receive a file from a publishing node, or receive an HTTP deletion for cancelling file delivery from the publishing node, or receive a first instruction for cancellation of file delivery from a third broadcast multicast node, wherein the file is converted from a group message payload, and the group message payload is included in a group message request instructing modification or cancellation of group message delivery from an application node to the publishing node, to receive the file, or receive the HTTP deletion, or receive the first instruction a second broadcast multicast node (800). **Claim 51** The second broadcast multicast node according to claim 50, further operable to execute the method according to any one of claims 17 to 33. **Claim 52** A third broadcast multicast node (800), comprising: a processor (821); a memory (822) coupled to the processor (821), wherein the memory (822) includes instructions executable by the processor (821), whereby the third broadcast multicast node (800) is operable to: receive a second instruction for file update or a first instruction for cancellation of file distribution from a public node, wherein the file is converted from a group message payload, and the group message payload is included in a group message request for instructing modification or cancellation of group message distribution from an application node to the public node; send the second instruction or the first instruction to a second broadcast multicast node. The third broadcast multicast node (800) operable to perform the above. **Claim 53** The third broadcast multicast node according to claim 52, further operable to execute the method according to any one of claims 35 to 43. **Claim 54** A user device (800), comprising: a processor (821); a memory (822) coupled to the processor (821), wherein the memory (822) includes instructions executable by the processor (821), whereby the user device (800) is operable to receive a message from a second broadcast multicast node or a third broadcast multicast node, the message including cancellation of file distribution. The user device (800) operable to perform the above. **Claim 55** The user device according to claim 54, further operable to execute the method according to any one of claims 45 to 47. **Claim 56** ​ A computer-readable storage medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 47. **Claim 57** A computer program product including instructions that, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 47.

Images