Handling failed or pre-emptied MBS broadcast sessions

Abstract

There is provided an apparatus of a multicast / broadcast control unit, comprising at least one processor and at least one memory comprising computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, generate a multicast / broadcast control unit. The apparatus is caused to perform at least: initiating a multicast / broadcast session by sending a request to at least one radio access network node for allocating resources for the multicast / broadcast session; receiving an error message from at least one radio access network node, the error message indicating that resources cannot be allocated and / or maintained; and resending, after the predetermined time elapses, the request for allocating resources for the multicast / broadcast session to the at least one radio access network node that has sent the failure message.

Description

[0001] Related references

[0002] This patent application claims priority to Indian Patent Application No. 202211040865 filed on July 18, 2022, which is incorporated by reference as if reproduced herein in its entirety. Technical Field

[0003] The present invention relates to an apparatus, method and computer program product for handling a failed or pre-empted MBS broadcast session. Background Art

[0004] The abbreviations used in this manual have the following meanings:

[0005] AMF Access Management Function

[0006] DL Downlink

[0007] DSP Digital Signal Processor

[0008] MBS Multicast / Broadcast Service

[0009] MB-SMF Multicast Broadcast Session Management Function

[0010] MB-UPF Multicast Broadcast User Plane Function

[0011] MCCH Multicast Control Channel

[0012] MTCH Multicast Transport Channel

[0013] NGAP Next Generation Application Protocol

[0014] QoS Quality of Service

[0015] RAN Radio Access Network

[0016] TNL Tunnel

[0017] UE User Equipment

[0018] Example embodiments (but not limited thereto) relate to multicast and broadcast sessions. Specifically, in Release 17, two types of MBS sessions can be established, namely broadcast sessions and multicast sessions.

[0019] In a broadcast session, MBS data is delivered through a service area that may include multiple RAN nodes. At the start of a broadcast session, the MB-SMF sends a broadcast session start message including the MBS service area to the AMF. The AMF analyzes the MBS service area and sends an NGAP broadcast session establishment message to all RAN nodes involved in the service area. The RAN node performs admission control and, if there are sufficient resources, starts delivering broadcast data over the air.

[0020] It may happen later that the resource situation changes and the RAN node does not have enough resources for all MBS sessions and needs to pre-empt a low priority broadcast session. Therefore, the NGAP Broadcast release required message has been introduced, which the RAN node can send to the AMF to request the release of a broadcast session.

[0021] After receiving the NGAP broadcast release request message, the AMF generates an NG Broadcast release request message to request the RAN node to release the broadcast session. After receiving the NG Broadcast release request message, the RAN node releases the resources associated with the broadcast session and replies with an NG Broadcast release response message. The NG Broadcast release response message is sent to the AMF, and the AMF notifies the MB-SMF (including the N2 container) using the Namf_MBSBroadcast__ContextStatusNotify service operation.

[0022] However, even if the situation improves later, the RAN nodes are unable to support or join the MBS broadcast session. Summary of the invention

[0023] Example embodiments address this situation and aim to provide measures for improving MBS session handling in situations where a RAN node is unable to establish or maintain resources for an MBS session.

[0024] According to a first aspect, a device of a multicast / broadcast control unit is provided, the device comprising: at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, cause the device to at least perform: initiating a multicast / broadcast session by sending a request for allocating resources for the multicast / broadcast session to at least one radio access network node; receiving an error message from at least one radio access network node indicating that resources cannot be allocated or cannot be maintained; and resending the request for allocating resources for the multicast / broadcast session to at least one radio access network node that has sent a failure message after a predetermined time has passed.

[0025] According to a second aspect, there is provided a method for use in a multicast / broadcast control unit, the method comprising:

[0026] initiating a multicast / broadcast session by sending a request to at least one radio access network node for allocating resources for the multicast / broadcast session,

[0027] receiving an error message from at least one radio access network node indicating that resources cannot be allocated or cannot be maintained, and

[0028] After a predetermined time has elapsed, a request for allocating resources for the multicast / broadcast session is resent to at least one radio access network node that has sent the failure message.

[0029] The first and second aspects can be modified as follows:

[0030] The predetermined time may be preset (predetermined, predefined) by an internal timer of the device or the multicast / broadcast control unit.

[0031] With the error message, timer information may be received from at least one radio access network node, the timer information defining a predetermined time.

[0032] Information about the multicast / broadcast session may be stored.

[0033] Any updates received to previously stored information about the multicast / broadcast session may be stored and, after a predetermined time has elapsed, the most recently updated information used in a retransmission attempt to initiate the multicast / broadcast session.

[0034] The multicast / broadcast control unit may be, or may be part of, an access management function, and information about the multicast / broadcast session may be received from the multicast-broadcast session management function.

[0035] The multicast / broadcast control unit can be a multicast-broadcast session management function, or can be part of the multicast-broadcast session management function, and timer information can be received from at least one radio access network node via the access management function, and a request for allocating resources for a multicast / broadcast session can be resent via the access management function after expiration of a predetermined time.

[0036] Before resending the request for allocating resources for the multicast / broadcast session to the at least one radio access network node, it may be determined whether the at least one radio access network node is located in a service area designated for the multicast / broadcast session.

[0037] According to a third aspect, a device (e.g., a device of a radio access network node) is provided, comprising: at least one processor and at least one memory comprising computer program code, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the device to at least perform: receiving a request for allocating resources for a multicast / broadcast session from a multicast / broadcast control unit; in a case where resources cannot be allocated and / or resources must be released during the multicast / broadcast session, sending an error message to the multicast / broadcast control unit, the error message indicating that the resources cannot be allocated and / or cannot be maintained; and in response to receiving an additional request for allocating resources for the multicast / broadcast session, retrying to allocate resources.

[0038] According to a fourth aspect, there is provided a method (e.g., a method of a radio access network node), the method comprising:

[0039] receiving a request from a multicast / broadcast control unit for allocating resources for a multicast / broadcast session,

[0040] In case resources cannot be allocated and / or resources must be released during a multicast / broadcast session, sending an error message to the multicast / broadcast control unit indicating that resources cannot be allocated and / or cannot be maintained, and

[0041] In response to receiving an additional request to allocate resources for the multicast / broadcast session, allocating resources is retried.

[0042] The third and fourth aspects can be modified as follows:

[0043] 27. The method according to claim 26, further comprising:

[0044] Timer information may be included in the error message, the timer information indicating a time after which the multicast / broadcast session may be initiated again.

[0045] The timer information may be based on congestion experienced by a device (eg, a radio access network node).

[0046] An error message including the timer information may be sent to the access management function.

[0047] The timer information may be incorporated into an information element to be forwarded to the multicast broadcast session management function via the access management function.

[0048] According to a fifth aspect, a device (e.g., a device of a radio access network node) is provided, comprising: at least one processor and at least one memory comprising computer program code, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the device to at least perform: receiving a request for allocating resources for a multicast / broadcast session from a multicast / broadcast control unit; successfully allocating resources; pausing the multicast / broadcast session if the resources cannot be maintained at least temporarily during the multicast / broadcast session; continuing to store any updates regarding the multicast / broadcast session received from a multicast-broadcast session management function; and resuming the multicast / broadcast session when resources become available again.

[0049] According to a sixth aspect, there is provided a method (e.g., a method for use in a radio access network node), the method comprising:

[0050] receiving a request from a multicast / broadcast control unit for allocating resources for a multicast / broadcast session,

[0051] Allocate resources successfully.

[0052] In the event that resources cannot be maintained at least temporarily during the multicast / broadcast session, suspending the multicast / broadcast session,

[0053] continue to store any updates received from the multicast-broadcast session management function regarding the multicast / broadcast session, and

[0054] When resources become available again, the multicast / broadcast session is resumed.

[0055] The fifth and sixth aspects can be modified as follows:

[0056] The multicast / broadcast session may be suspended by leaving the transport network multicast and updating the multicast control channel, and may be resumed by joining the transport network multicast and updating the multicast control channel.

[0057] The multicast / broadcast session can be suspended by sending a session suspension request to the multicast-broadcast session management function via the access management function and by updating the multicast control channel, and the multicast / broadcast session can be resumed by sending a session resumption request to the multicast-broadcast session management function via the access management function and by updating the multicast control channel.

[0058] According to the seventh aspect, a device for multicast-broadcast session management function is provided, the device comprising: at least one processor and at least one memory comprising computer program code, the at least one memory and the computer program code being configured to, together with the at least one processor, enable the device to at least perform: receiving a session suspension request from a radio access network node requesting to suspend delivery for a multicast / broadcast session; and updating the session by removing a downlink tunnel to the radio access network node for the multicast / broadcast session at a multicast-broadcast user plane function; sending updates about the multicast / broadcast session to a RAN node; and receiving a session resumption request from the radio access network; and updating the session by adding a downlink tunnel at the multicast-broadcast user plane function.

[0059] According to an eighth aspect, there is provided a method for use in a multicast broadcast session management function, the method comprising:

[0060] receiving a session suspend request from a radio access network node requesting suspension of delivery for a multicast / broadcast session, and

[0061] updating the session by removing the downlink tunnel for the multicast / broadcast session to the radio access network node at the multicast-broadcast user plane function,

[0062] Send updates to the RAN nodes regarding multicast / broadcast sessions, and

[0063] receiving a session resumption request from a radio access network, and

[0064] The session is updated by adding a downlink tunnel at the multicast broadcast user plane function.

[0065] According to a ninth aspect of the present invention, there is provided a computer program product comprising code means for executing a method according to any one of the second, fourth, sixth and eighth aspects and / or their modifications when running on a processing component or module. The computer program product may be embodied on a computer-readable medium, and / or the computer program product may be directly loaded into an internal memory of a computer, and / or may be transmittable via a network by at least one of an upload, download and push process.

[0066] According to a tenth aspect, there is provided an apparatus comprising:

[0067] means for initiating a multicast / broadcast session by sending a request to at least one radio access network node for allocating resources for the multicast / broadcast session,

[0068] means for receiving an error message from at least one radio access network node indicating that resources cannot be allocated or cannot be maintained, and

[0069] Means for resending, after a predetermined time has elapsed, a request for allocation of resources for a multicast / broadcast session to at least one radio access network node that has sent a failure message.

[0070] According to an eleventh aspect, there is provided an apparatus comprising:

[0071] means for receiving a request from a multicast / broadcast control unit for allocating resources for a multicast / broadcast session,

[0072] means for, in case resources cannot be allocated and / or resources have to be released during a multicast / broadcast session, sending an error message to the multicast / broadcast control unit indicating that resources cannot be allocated and / or cannot be maintained, and

[0073] Means for retrying to allocate resources in response to receiving an additional request to allocate resources for the multicast / broadcast session.

[0074] According to a twelfth aspect, there is provided an apparatus comprising:

[0075] means for receiving a request from a multicast / broadcast control unit for allocating resources for a multicast / broadcast session,

[0076] components for successfully allocating resources,

[0077] means for suspending a multicast / broadcast session if resources cannot be maintained at least temporarily during the multicast / broadcast session,

[0078] means for continuing to store any updates received from the multicast-broadcast session management function regarding the multicast / broadcast session, and

[0079] Components for resuming a multicast / broadcast session when resources become available again.

[0080] According to a thirteenth aspect, there is provided an apparatus comprising:

[0081] means for receiving a session suspend request from a radio access network node requesting suspension of delivery for a multicast / broadcast session, and

[0082] means for updating a session by removing a downlink tunnel to a radio access network node for a multicast / broadcast session at a multicast-broadcast user plane function,

[0083] means for sending updates regarding the multicast / broadcast session to a radio access network node, and

[0084] means for receiving a session resumption request from a radio access network, and

[0085] Means for updating a session by adding a downlink tunnel at a multicast broadcast user plane function. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] These and other objects, features, details and advantages will become more apparent from the following detailed description of example embodiments taken in conjunction with the accompanying drawings, in which:

[0087] Figure 1A shows a multicast / broadcast control unit 1 according to an example embodiment,

[0088] Figure 1B shows a process performed by a multicast / broadcast control unit 1 according to an example embodiment,

[0089] Figure 2A A RAN node 2 is shown according to an example embodiment,

[0090] Figure 2B shows a process performed by a RAN node 2 according to an example embodiment,

[0091] Figure 3A shows an alternative process performed by a RAN node according to an example embodiment,

[0092] Figure 3B shows an alternative process performed by the multicast / broadcast control unit 1 as a multicast-broadcast session management function according to an example embodiment,

[0093] Figure 4 shows the signal flow according to the first embodiment,

[0094] Figure 5 and Figure 6 shows a signal flow according to the second embodiment,

[0095] Figures 7 to 9 shows a signal flow according to a third embodiment,

[0096] Fig.10 and Fig.11 shows a signal flow according to a fourth embodiment,

[0097] Fig.12shows a broadcast session establishment, unsuccessful operation, and

[0098] Fig.13 A broadcast session release requirement and successful operation according to another embodiment are shown. DETAILED DESCRIPTION

[0099] An exemplary embodiment will be described below. However, it should be understood that this description is given by way of example only, and the described exemplary embodiment should not be understood to limit the present invention thereto.

[0100] Before describing example embodiments, problems of the prior art will be discussed in more detail below.

[0101] During admission control in the RAN for a broadcast session, admission control may not be fully successful in some gNBs due to resource congestion, resulting in:

[0102] -RAN nodes (e.g. gNB) may need to fail the establishment of a broadcast session.

[0103] -RAN nodes (e.g. gNB) may need to pre-empt resources for lower priority broadcast sessions.

[0104] If the resource situation in a RAN node improves, there is currently no solution how the broadcast session can be resumed in that RAN node.

[0105] For example, the RAN node cannot see what happened to a broadcast session after it failed or was pre-empted, e.g. the broadcast session might even have been ended. Therefore, it does not make sense for the RAN node to blindly request that the AMF or MB-SMF be added to the broadcast session again, as the session might have ended after some time. This would waste signaling.

[0106] Therefore, the question is how to resume a broadcast session in the RAN node once the congestion situation has been resolved, after the RAN node fails admission control of the broadcast session due to resource congestion, or preempts a started broadcast session due to lack of resources.

[0107] As mentioned above, the Broadcast Release Required procedure is a Class 2 NGAP procedure using non-UE related signaling. The purpose of the Broadcast Session Release Required message is to trigger the CN to initiate the Broadcast Session Release procedure. Upon receiving the Broadcast Session Release Required message, the CN will realize that the RAN does not have sufficient resources to provide broadcast services over the radio, and will initiate the Broadcast Session Release procedure to release the MBS context corresponding to the previously established MBS session.

[0108] For example, broadcasting a session release request message such as Fig.13 shown.

[0109] Example embodiments aim to provide improved MBS session handling in situations where a RAN node is unable to establish or maintain an MBS session because, for example, the RAN node has to release resources.

[0110] Below, reference Figure 1A , Figure 1B , Figure 2A and Figure 2B A general overview of some example embodiments is described below.

[0111] Figure 1A A multicast / broadcast control unit 1 as an example of a first device according to this exemplary embodiment is shown. The first device may be a multicast / broadcast control unit or a part thereof. For example, the multicast / broadcast control unit may be an access management function (AMF) or a multicast broadcast session management function (MB-SMF). Figure 1B The process performed by the multicast / broadcast control unit 1 is illustrated.

[0112] Figure 1A The multicast / broadcast control unit 1 shown includes at least one processor 11 and at least one memory 12 including computer program code. The at least one processor 11 is configured to, together with the at least one memory 12 and the computer program code, cause the apparatus to execute: Figure 1B The RAN node shown in 1) sends a request for allocating resources for the multicast / broadcast session to initiate a multicast / broadcast session (S11); receives an error message from at least one radio access network node (S12), the error message indicating that resources cannot be allocated and / or cannot be maintained; and after a predetermined time, resends the request for allocating resources for the multicast / broadcast session to at least one radio access network node that has sent a failure message (S13).

[0113] Figure 2A A radio access network node (RAN node) 2 is shown as an example of a second device according to this exemplary embodiment. The second device may be a RAN node or a part thereof. In addition, the RAN node may be a gNB. Figure 2B The process performed by the RAN node 2 is illustrated.

[0114] Figure 2A The RAN node 2 shown in the figure comprises at least one processor 21 and at least one memory 22 including computer program code. The at least one processor 21 is configured to, together with the at least one memory 22 and the computer program code, cause the apparatus to execute: from a multicast / broadcast control unit (e.g., Figure 1A) receiving a request for allocating resources for a multicast / broadcast session (S21); in a case where resources cannot be allocated during the multicast / broadcast session and / or the resources must be released, sending an error message to a multicast / broadcast control unit (S22), the error message indicating that the resources cannot be allocated and / or cannot be maintained; and in response to receiving another request for allocating resources for the multicast / broadcast session, retrying to allocate resources (S23).

[0115] The above-mentioned apparatus 1 and apparatus 2 may further include I / O units 13 and 23. The I / O units 13 and 23 are capable of sending to and receiving from other network units.

[0116] Therefore, according to some example embodiments as described above, a retry of allocating resources to a multicast / broadcast session may be triggered.

[0117] The retry may be triggered by the AMF or MB-SMF after a predetermined time. The predetermined time may be preset by an internal timer of the AMF or MB-SMF. However, the predetermined time may also be determined by the RAN node, for example based on congestion experienced by the RAN node. Then, the retry (i.e. resending the request for allocating resources) does not occur before the predetermined time has passed.

[0118] The predetermined time determined by the RAN node may be referred to as timer information, and according to some embodiments this is referred to as a "wait timer before retry" or a "wait timer", and may be an information element (IE) inserted into a suitable message.

[0119] Reference below Figure 3A and Figure 3B to describe additional example embodiments.

[0120] Figure 3A An alternative process performed by the RAN node 2 is shown. In S31, the RAN node 2 receives a request for allocation of resources for a multicast / broadcast session from a multicast / broadcast control unit and successfully allocates resources. In S32, in case resources must be released during the multicast / broadcast session (e.g. at least temporarily pre-emptied), the multicast / broadcast session is suspended. In S33, the RAN node 2 continues to store any updates received from the multicast-broadcast session management function regarding the multicast / broadcast session and takes these updates into account even though the session is suspended, and then, when resources become available again, the RAN node resumes the multicast / broadcast session in S34.

[0121] Figure 3BAn alternative process performed by a multicast / broadcast control unit 1 (as a multicast-broadcast session management function) is shown. In S41, the multicast / broadcast control unit 1 receives a session suspension request from a radio access network node requesting suspension of delivery of a multicast / broadcast session, and in S42, updates the session by removing a downlink tunnel to the radio access network node for the multicast / broadcast session at a multicast-broadcast user plane function (MB-UPF), thereby stopping delivery of session data to the radio access network node. In S43, despite being in a suspended state, the multicast / broadcast control unit 1 continues to send updates about the multicast / broadcast session to the RAN node. In S44, the multicast / broadcast control unit 1 receives a session resumption request from the radio access network, and in S45, updates the session by adding a downlink tunnel at the multicast-broadcast user plane function, thereby resuming delivery of session data to the radio access network node.

[0122] Therefore, according to the above combination Figure 3A and Figure 3B The example embodiments described enable the RAN node to easily suspend an MBS session if necessary and resume the MBS session again later when resources are available again.

[0123] The above process is described below with reference to some more detailed embodiments.

[0124] First embodiment

[0125] According to the first embodiment, blind attempts and failures are triggered by AMF or MB-SMF

[0126] First, a pre-emptied session is described. That is, the RAN node pre-empties the broadcast session due to lack of resources and sends a broadcast release request message to the AMF to notify the release request.

[0127] Option 1: Retry triggered by AMF: After receiving the NG Broadcast Release Required message, the AMF retains the MBS Session Context as long as the MBS Session exists. It stores any updates to the N2 container and service area received from the MB-SMF. As long as the AMF sees that the RAN node is still part of the service area, the AMF may blindly retry sending the NG Session Establishment message to the RAN node from time to time. The RAN node then runs admission control and starts delivering broadcast data again if the congestion has disappeared.

[0128] Option 2: Retry triggered by MB-SMF: After receiving the NG Broadcast Release Response Transport Container (N2 container) within the Namf_MBSBroadcast__ContextStatusNotify request message, the MB-SMF retains the MBS session context as long as the MBS session exists. The MB-SMF may retry from time to time to send a Broadcast Session Update or Establishment message including the RAN node ID to the AMF. If the AMF can, it checks whether the RAN node is located in the most recently received service area, and if this is the case, the AMF may send a NG Broadcast Session Establishment to the RAN node to restart the session. The RAN node runs admission control and starts delivering broadcast data again if congestion has disappeared.

[0129] Session establishment failure: The RAN node fails to establish a broadcast session due to lack of resources.

[0130] The handling of the session establishment failure case can be inferred from the pre-cleared session case by replacing the message used by the RAN to notify the CN:

[0131] - For option 1: Replace "NG broadcast release request" with "NG broadcast session establishment failure".

[0132] - For option 2: Replace "NG Broadcast Release Response Transmission" with "NG Broadcast Setup Failure Transmission".

[0133] The first embodiment is described below in more detail.

[0134] Specifically, by referring to Figure 4 , describes example Option 1 for the first embodiment, i.e. blind attempts and failures triggered by the AMF for the pre-empty session case. It should be noted that gNB1 represents an example of a RAN node that has to pre-empty an MBS session due to congestion.

[0135] Procedure 1: gNB1 encounters congestion and decides to preempt the MBS session, as shown in A1. It sends a NG Broadcast Release Request, as shown in A2. After receiving the NG Broadcast Release Request message, the AMF sends a NG Broadcast Release Request message, as shown in A3. After receiving the NG Broadcast Release Response message from gNB1, the AMF generates a Namf_MBSBroadcast__ContextStatusNotify request to notify the MB-SMF of the release of gNB1, as shown in A4. This message contains the NG Broadcast Release Response transmission.

[0136] Procedure 2: When the internal timer expires, the AMF checks whether gNB1 is still in the service area (new) according to the latest service area notified from MB-SMF, as shown in A5. If gNB1 is still in the service area, the AMF attempts to send the NG Broadcast Setup Request again, as shown in A6. In this example, for procedure 2, gNB1 may still be in a congested situation and the admission control fails, as shown in A7. Therefore, in A8, gNB1 sends a Broadcast Setup Failure message to the AMF.

[0137] Procedure 3: Subsequently, when the internal timer expires, the AMF checks again whether gNB1 is still in the service area (new) based on the latest service area notified from the MB-SMF, as shown in A9. If gNB1 is still in the service area, the AMF attempts to send the NG broadcast establishment request again, as shown in A10. In this example, for procedure 3, gNB1 is no longer in a congested situation and the admission control is successful, as shown in A11. The broadcast session starts again in gNB1. gNB1 sends a NG broadcast session establishment response message to notify the AMF of the success, as shown in A12. The AMF conveys the information by sending a Namf_MBSBroadcast_ContextStatsuNotify request message including the NG broadcast establishment response transmission to the MB-SMF, as shown in A13.

[0138] As described above, by replacing the "NG broadcast release request" in the above call flow by "NG broadcast establishment failure", the same first embodiment option 1 diagram for the "session establishment failure" case can be easily derived.

[0139] Second embodiment

[0140] A second embodiment is described below, according to which the RAN timer is handled by the AMF. The following mainly describes the differences with respect to the first embodiment.

[0141] The following describes the case of pre-clearing the session, i.e., the RAN node pre-clears the broadcast session due to lack of resources and sends a broadcast release request to the AMF to notify the release.

[0142] RAN Node:

[0143] The RAN node includes a new "wait timer before retry" IE to the NG Broadcast Release Request message or the NG Broadcast Release Response message (new) to indicate an estimate related to a congestion period during which it is useless for the 5GC to attempt to recover the broadcast session. In the following, the "wait timer before retry" is also referred to as just the "wait timer". It may also be referred to as the "wait time" or the "wait time before retry".

[0144] If the RAN node receives a new broadcast session establishment after the timer expires, the RAN node performs admission control again. If the congestion has disappeared, it can accept the broadcast session and allocate radio resources. In this case, it replies to the AMF with an NG Broadcast Setup Response including an N2 container to inform the MB-SMF.

[0145] AMF Node:

[0146] When the AMF receives a NG Broadcast Release Request or NG Broadcast Release Response message for a given broadcast session including a "wait timer before retry", the AMF stores the wait timer and then:

[0147] 1 / If the AMF broadcast session is updated during the timer duration, the AMF stores the updated N2 container and updated service area (if any). The AMF will not attempt to resume the broadcast session in the RAN node until the wait timer it received from the RAN node expires.

[0148] 2 / While waiting for the timer to expire, if the RAN node is still within the service area of ​​the MBS session, the AMF may resend the NG broadcast session establishment, which includes: the latest N2 container for the broadcast session received from the MB-SMF since the broadcast release request / response was received (i.e., during the timer duration).

[0149] It should be noted that if a RAN node is no longer in the service area of ​​the MBS session, the AMF will not attempt to resume the broadcast session in that RAN node.

[0150] As described above in conjunction with the first embodiment, in the case of a session establishment failure, the RAN node fails to establish the broadcast session due to lack of resources.

[0151] The handling of this failed session establishment situation can be derived from the pre-cleared session situation by replacing "NG broadcast release request" with "NG broadcast session establishment failure".

[0152] In the following, reference Figure 5 The second embodiment is described in more detail. Similar to the case of the first embodiment, gNB1 is an example of a RAN node for which an MBS session needs to be cleared in advance. Specifically, an example of handling a RAN timer by an AMF in the case of clearing a session in advance is described.

[0153] Process 1: gNB1 encounters congestion and decides to preempt the MBS session, as shown in B1. It sends a NG Broadcast Release Request message, which includes a “wait timer before retry”, as shown in B2.

[0154] Procedure 2: After receiving the NG Broadcast Release Request message, the AMF stores the waiting timer and sends the NG Broadcast Release Request message, as shown in B3. After receiving the NG Broadcast Release Response message from gNB1, the AMF generates a Namf_MBSBroadcast__ContextStatusNotify request to notify the MB-SMF of the MBS session pre-clearance / release in gNB1, as shown in B4.

[0155] Procedure 3: During the waiting timer, the AMF receives a request from the MB-SMF to update the MBS session, as shown in B5. The AMF stores the received N2 container and service area. However, as long as the waiting timer is running, the AMF does not take any action (new) on gNB1 even if these modifications are involved, as shown in B6.

[0156] Process 4: While waiting for the timer to expire, the AMF analyzes the latest stored service area, as shown in B7. If gNB1 is involved, the AMF generates an NG broadcast establishment message to gNB1, as shown in B8. gNB1 runs admission control, as shown in B9.

[0157] Then, gNB1 sends an NG broadcast session establishment response message to notify AMF of the success, as shown in B10, and AMF conveys the information by sending a Namf_MBSBroadcast_ContextStatsuNotify request message including the NG broadcast establishment response transmission to MB-SMF, as shown in B11.

[0158] Figure 6 The diagram illustrates an example of the second embodiment of the handling of the RAN timer by the AMF in the case of a session establishment failure. As described above, by replacing the "NG broadcast release request" in the above call flow with "NG broadcast establishment failure", the same second embodiment diagram for the "establishment failure" case can be easily derived, such as Figure 6 shown.

[0159] Specifically, in process 1, gNB1 receives the NG Broadcast Setup Request message from AMF, as shown in C1. However, gNB1 encounters congestion, so it cannot allocate the necessary resources for the MBS session, as shown in C2. Therefore, in process 2, gNB1 sends a Broadcast Setup Failure message to AMF, which contains a "wait timer before retry", as shown in C3. Then, the rest of the process is the same as Figure 5 That is, C4 to C11 are similar to Figure 4 B4 to B11 shown correspond.

[0160] Third embodiment

[0161] A third embodiment is described below, according to which RAN timer processing is performed by the MB-SMF. The differences with respect to the second embodiment are mainly described below.

[0162] First, the case of pre-clearing the session is described, in which the RAN node pre-clears the broadcast session due to lack of resources and sends a broadcast release request to notify the AMF of the request to release the MBS session.

[0163] The RAN node sends a NG Broadcast Release Required message to the AMF, followed by a NG Broadcast Release Response message. The RAN node includes a "Wait Timer Before Retry" timer (new) for a given broadcast session to inform the AMF.

[0164] The MB-SMF is also notified via one of the following two options:

[0165] Option 1: When receiving the "wait timer before retry" timer from the RAN node, the AMF sends a Namf_MBSBroadcast ContextStatusNotify request message to the MB-SMF, which includes the RAN node ID, an indication that the MBS session has been pre-cleared by the NG RAN node and a timer (this indication may be implicitly signaled by the presence of the timer).

[0166] Option 2: The RAN node also includes the "Wait timer before retry" timer into the NG Broadcast Release Response Transport IE, which is communicated by the AMF to the MB-SMF in the Namf_MBSBroadcast ContextStatusNotify request message.

[0167] After receiving the Namf_MBSBroadcast__ContextStatusNotify request message from the AMF, the MB-SMF stores the RAN Node ID and the associated wait timer before retrying.

[0168] When the RAN timer in the MB-SMF expires, the MB-SMF sends a broadcast session update message (or a start message if the MBS session has been terminated in all NG-RAN nodes) including the RAN node ID, the latest N2 container and the latest service area to the AMF. After receiving the broadcast session update message (or start message), the AMF analyzes the service area. If the RAN node ID is included in the service area, the AMF sends an NGAP broadcast session establishment message including the N2 container to the RAN node.

[0169] Furthermore, according to the third embodiment, a situation of session establishment failure may occur in which the RAN node fails to establish a broadcast session due to lack of resources.

[0170] The handling of the establishment session failure case can be inferred from the pre-cleared session case by replacing the message used by the RAN to notify the CN:

[0171] For option 1, "NG broadcast release request" is replaced by "NG broadcast session establishment failure".

[0172] For option 2, "NG Broadcast Release Response Transmission" is replaced by "NG Broadcast Setup Failure Transmission".

[0173] In the following, by reference Figure 7 The flowchart shown in FIG. 1 describes in more detail an example for the third embodiment, according to which the RAN timer processing is performed by the MB-SMF. In this example, the case of pre-clearing the session is described, and the above-mentioned option 1 is applied, that is, the AMF communicates the "wait timer before retry" to the MB-SMF.

[0174] Process 1: gNB1 encounters congestion and decides to preempt the MBS session, as shown in D1. It sends a NG Broadcast Release Request message, which includes a "wait timer before retry" (new), as shown in D2.

[0175] Procedure 2: After receiving the NG Broadcast Release Requirement message, the AMF sends the NG Broadcast Release Request message. After receiving the NG Broadcast Release Response message from gNB1, as shown in D3, the AMF generates a Namf_MBSBroadcast__ContextStatusNotify request to notify the MB-SMF of the gNB1 release, which includes the "wait timer before retry" (new) to the MB-SMF, as shown in D4.

[0176] Procedure 3: During the waiting timer, the AMF receives a request from the MB-SMF to update the MBS session, as shown in D5. The AMF stores the received N2 container and service area. However, as long as the waiting timer is running, the AMF does not take any action (new) on gNB1 even if these modifications are involved, as shown in D6.

[0177] Process 4: Upon expiration of the waiting timer, as shown in D7, the MB-SMF generates a broadcast session update (or start) message (new) to the AMF, which includes gNB1 as the target, as shown in D8. Upon receiving the broadcast start including gNB1, the AMF analyzes whether gNB1 is included in the service area, as shown in D9. If gNB1 is included in the service area, the AMF generates an NG broadcast establishment message to gNB1, as shown in D10. Thereafter, gNB1 runs admission control, as shown in D11. The following process is similar to the above, that is, D12 and D13 correspond to C10 and C11, respectively.

[0178] A further example of the third embodiment is described below, namely the case where session establishment fails while RAN timer handling is performed by the MB-SMF and Option 1 is applied.

[0179] As described above, by replacing the "NG broadcast release request" in the above call flow with "NG broadcast establishment failure", the same third embodiment diagram for the "establishment failure" case can be easily derived, such as Figure 8 As shown in the flowchart shown.

[0180] Specifically, in process 1, the gNB receives a NG broadcast setup request message from the AMF, as shown in E1. However, gNB1 encounters congestion and thus cannot allocate the necessary resources for the MBS session, as shown in E2. Therefore, in process 2, the gNB sends a broadcast setup failure message including a "wait timer before retry" to the AMF, as shown in E3. Thereafter, the AMF sends a Namf_MBSBroadcast__ContextStatusNotify request including a "wait timer before retry" to the MB-SMF, as shown in E4.

[0181] The rest of the process Figure 7 That is, E5 to E13 correspond to D5 to D13, respectively.

[0182] Another example of the third embodiment is described below, that is, describing the case of pre-clearing the session while the RAN timer processing is performed by the MB-SMF, but option 2 is applied. Fig. 9 The flowchart shown describes this.

[0183] Process 1: gNB1 encounters congestion and decides to preempt the MBS session, as shown in F1. It sends an NG Broadcast Release Request, which includes a "wait timer before retry" (new), as shown in F2.

[0184] Process 2: After receiving the NG Broadcast Release Request message, the AMF sends a NG Broadcast Release Request message. gNB1 generates a NG Broadcast Release Response message, including a Wait Timer Before Retry (new) in the Broadcast Release Response Transport information element. After receiving the NG Broadcast Release Response message from gNB1, as shown in F3, the AMF generates N_mbsmf_update_notify to notify the MB-SMF of the gNB1 release, wherein the message includes the NG Broadcast Release Response Transport, which in turn includes the wait timer included by gNB1, namely the "Wait Timer Before Retry", as shown in F4. MB-SMF stores the received Wait Timer Before Retry associated with gNB1 in the N2 container (new).

[0185] Procedure 3: During the waiting timer, the AMF receives a request to update the MBS session from the MB-SMF, as shown in F5. The AMF stores the received N2 container and service area. However, as long as the waiting timer is running, the AMF does not take any action (new) on gNB1 even if these modifications are involved, as shown in F6.

[0186] Procedure 4: Upon expiration of the waiting timer, the MB-SMF generates a broadcast session update (or broadcast session start) message (new) to the AMF, which includes gNB1 as the target, as shown in F8. After receiving the broadcast session update (or start) including gNB1, the AMF analyzes whether gNB1 is included in the service area, as shown in F9. If gNB1 is included in the service area, the AMF generates a NG broadcast setup message to gNB1, as shown in F10. Thereafter, gNB1 runs admission control, as shown in F11.

[0187] The rest of the process Figure 8 The same is shown; that is, F12 and F13 correspond to E12 and E13 respectively.

[0188] A fourth embodiment is described below, according to which a broadcast session is suspended and resumed at the MB-SMF in the case of performing a pre-clear session.

[0189] The RAN (RAN node, e.g. gNB) suspends the MBS broadcast session and

[0190] a) If multicast N3mb is used, the RAN leaves the transport network multicast (e.g. IGMP leave). The RAN node suspends the broadcast MRB(s) by updating the MCCH; or

[0191] b) If unicast N3mb is used, the RAN sends a broadcast session suspension request to the MB-SMF via the AMF. The MB-SMF updates the N4 session to the MB-UPF to remove the DL tunnel. The RAN node suspends (multiple) broadcast MRBs by updating the MCCH.

[0192] When the MBS broadcast session is suspended, the MB-SMF sends updates to the RAN nodes as usual, for example updating the MBS service area by adding / removing cells.

[0193] When resources become available again for an MBS broadcast session, the RAN performs the following:

[0194] a) If multicast N3mb is used, the RAN joins the transport network multicast (eg IMGP join). The RAN recovers the broadcast MBR(s) by updating the MCCH and starts broadcasting the MTCH.

[0195] b) If unicast N3mb is used, the RAN sends a broadcast session resume request including N3mb DL tunnel information to MB-SMF via AMF. MB-SMF updates the N4 session and adds a DL tunnel at MB-UPF. MB-SMF responds to the request (i.e., Type 1 procedure on NGAP). RAN resumes (multiple) broadcast MBRs by updating MCCH and starts broadcasting MTCH.

[0196] A more detailed example of the fourth embodiment is described below by referring to the case of pre-clearing the session, in which the pausing and resuming of the broadcast session at the MB-SMF is performed. Specifically, Fig.10 The implementation of the fourth embodiment is shown when multicast N3mb is used.

[0197] G1: The gNB experiences congestion and needs to preempt lower priority MBS broadcast sessions.

[0198] G2: The gNB suspends the MBS broadcast session. The configuration for receiving the MBS broadcast session is removed from the content of the MCCH message, and the updated MCCH is broadcast. If there are no other MBS broadcast sessions in the cell, the gNB can completely stop broadcasting the MCCH in the cell.

[0199] G3: The gNB leaves the multicast group used in the transport network on the N3mb interface between the gNB and MB-UPF.

[0200] G4 and G5: When radio resources become available again in at least one cell of the MBS session, the gNB resumes the MBS broadcast session by adding the configuration for receiving the MBS broadcast session to the MCCH and broadcasting the updated MCCH.

[0201] G6: The gNB joins the multicast group on the N3mb interface again.

[0202] G7: User data is sent in the MBS broadcast session.

[0203] It should be noted that in LTE, it is possible to suspend an MBMS session locally by the eNB, but LTE does not specify that the eNB should leave the multicast group on the M1 interface. This means that the eNB will still receive data for the MBMS session, but the data will be discarded and will not be broadcast.

[0204] Fig.11 An implementation of the fourth embodiment is shown when unicast transmission over N3mb is used.

[0205] H1: The gNB experiences congestion and needs to preempt lower priority MBS broadcast sessions.

[0206] H2: The gNB suspends the MBS broadcast session. The configuration for receiving the MBS broadcast session is removed from the content of the MCCH message and the updated MCCH is broadcast. If there are no other MBS broadcast sessions in the cell, the gNB can completely stop broadcasting the MCCH in that cell.

[0207] H3: The gNB sends a NGAP broadcast suspend request to the AMF (Note: the NGAP broadcast release required message may be considered as an alternative, with a flag indicating that the session is not released by the gNB but only suspended), indicating the MBS session ID of the suspended MBS broadcast session. By including one or more QFIs of the suspended QoS flows, only some QoS flows may be suspended instead of the entire MBS session. The gNB shall include the downlink tunnel information (i.e. DL TNL information) of the unicast N3mb tunnel, which is used by the MB-SMF and MB-UPF to update the N4mb session to either completely release the tunnel or to modify the forwarding action for the tunnel (i.e. the suspended QoS flow is not forwarded). Alternatively, the MB-SMF may identify the correct N3mb tunnel from the RAN ID provided by the AMF in the notification, see procedure 4.

[0208] H4: AMF notifies MB-SMF and forwards the NGAP broadcast suspension request. AMF includes the gNB identifier (i.e. RAN ID) in the message to MB-SMF.

[0209] H5: MB-SMF updates the N4mb session at MB-UPF, which instructs MB-UPF to release the unicast N3mb tunnel when the MBS broadcast session is completely suspended, or to stop forwarding data for the suspended QoS flow.

[0210] H6: MB-UPF updates N4mb session.

[0211] H7: AMF responds with an NGAP Broadcast Pause Response.

[0212] H8 and H9: When radio resources in at least one cell of the MBS session become available again, the gNB resumes the MBS broadcast session by adding the configuration for receiving the MBS broadcast session to the MCCH and broadcasting the updated MCCH.

[0213] H10: The gNB sends an NGAP Broadcast Resume Request to the AMF indicating the MBS Session ID of the resumed MBS broadcast session. The gNB may resume only some QoS flows. In this case, the request shall include one or more QFIs of the resumed QoS flows. The gNB shall include the DL TNL information if the MBS broadcast session was completely suspended or if the gNB wants to change the DL TNL information as part of the resumption procedure.

[0214] H11: AMF notifies MB-SMF and forwards the NGAP broadcast recovery request. AMF includes the gNB identifier (i.e. RAN ID) in the message to MB-SMF and forwards the received DL TNL information to MB-SMF for tunnel recovery at MB-UPF.

[0215] H12: MB-SMF updates the N4mb session at the MB-UPF, which instructs the MB-UPF to establish a unicast N3mb tunnel (if the MBS broadcast session is completely suspended) or start forwarding data for the previously suspended QoS flow.

[0216] H13: MB-UPF updates the N4mb session and starts sending QoS flows or establishing an N3mB tunnel.

[0217] H14: AMF responds with NGAP broadcast recovery response.

[0218] H15: User data is sent in the MBS broadcast session.

[0219] Therefore, according to the above-described exemplary embodiments, a RAN node or similar element may join an MBS session even if the RAN node must clear resources in advance during the MBS session or cannot start the MBS session because resources for the MBS session cannot be allocated.

[0220] The above-described exemplary embodiments are merely examples and may be modified.

[0221] For example, according to some of the above embodiments, a specific message sent from AMF to MB-SMF is described, such as Namf_MBSBroadcast__ContextStatusNotify request. However, other suitable messages are also applicable, in which new parameters (such as "wait timer before retry") can be sent from the RAN node to the AMF, and / or from the AMF to the MB-SMF.

[0222] Furthermore, the parameter "wait timer before retry" is only an example. For example, for the wait timer, an existing value may also be used, such as the "wait time" IE specified in TR 38.413.

[0223] In the following, an embodiment is described in which the influence of TR 38.413 is illustrated.

[0224] Fig.12 An example of an unsuccessful operation for a broadcast session establishment is shown.

[0225] The AMF sends a broadcast session establishment request in I1 to request the NG-RAN node to establish a broadcast session by providing resources.

[0226] If the NG-RAN node cannot provide resources for all flows in an MBS session in any of its cells, it shall send a Broadcast Session Establishment Failure message as shown in I2.

[0227] If the Broadcast Session Establishment Failure message includes a Wait Time IE (or a Wait Timer before Retry), the AMF node shall wait for at least the indicated time before re-initiating the Broadcast Session Establishment procedure towards the same NG-RAN node.

[0228] Fig.13 A case of successful operation of the broadcast session release request is shown.

[0229] The NG-RAN node initiates the procedure by sending a Broadcast Session Release Request message to the AMF, as shown in J.

[0230] Upon receipt of the Broadcast Session Release Required message, the AMF shall realize that the NG-RAN node has insufficient resources to provide broadcast services over the radio and start releasing the MBS contexts corresponding to the previously established MBS sessions. If the Broadcast Session Release Required message includes a Wait Time IE (or a Wait Timer before retrying), the AMF node shall wait for at least the indicated time before re-initiating the Broadcast Session Establishment procedure towards the same NG-RAN node.

[0231] The names of network elements, protocols and methods are based on current standards. In other versions or other technologies, the names of these network elements and / or protocols and / or methods may be different, as long as they provide corresponding functions.

[0232] In general, example embodiments may be implemented by computer software stored in memory (memory resources, memory circuitry) 12, 22 and executable by processor (processing resources, processing circuitry) 11, 21 or hardware, or by a combination of software and / or firmware and hardware.

[0233] As used in this application, the term "circuitry" may refer to all of the following:

[0234] (a) hardware circuit implementation only (such as implementation in analog and / or digital circuitry only), and

[0235] (b) a combination of circuitry and software (and / or firmware) such as (as applicable):

[0236] (i) a combination of processor(s), or (ii) portions of processor / software (including digital signal processor(s), software, and memory(s) that work together to enable a device (such as a mobile phone or server) to perform various functions), and

[0237] (c) Circuitry, such as microprocessor(s) or portion(s) of microprocessor(s), that requires software or firmware to operate, even if the software or firmware is not physically present.

[0238] This definition of circuitry applies to all uses of the term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of only a processor (or multiple processors) or a portion of a processor and its accompanying software and / or firmware. For example, if applicable to a particular claim element, the term circuitry also covers a baseband integrated circuit or an application processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other network device.

[0239] The terms "connected," "coupled," or any variations thereof, refer to any direct or indirect connection or coupling between two or more elements, and may include one or more intermediate elements present between two elements being "connected" or "coupled" together. The coupling or connection between elements may be physical, logical, or a combination thereof. As employed herein, two elements may be considered to be "connected" or "coupled" together by using one or more wires, cables, and printed electrical connections, as well as by using electromagnetic energy, such as, as non-limiting examples, electromagnetic energy having wavelengths in the radio frequency region, microwave region, and optical (both visible and invisible) region.

[0240] The memory (memory resources, memory circuit system) 12, 22 can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, and non-transitory computer-readable media. The processor (processing resource, processing circuit system) 11, 21 can be of any type suitable for the local technical environment, and as non-limiting examples, can include one or more of the following: a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture.

[0241] It should be understood that the above description illustrates the present invention and should not be construed as limiting the present invention. Various modifications and applications may be made by those skilled in the art without departing from the true spirit and scope of the present invention defined by the appended claims.

Claims

1. A multicast / broadcast control unit, comprising: at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus to at least perform: sending a request to at least one radio access network node for allocation of resources for a multicast / broadcast session; receiving an error message from at least one radio access network node, the error message indicating that the resources for the multicast / broadcast session cannot be allocated or cannot be maintained; as well as After a predetermined time has elapsed, a request for allocating resources for the multicast / broadcast session is resent to the at least one radio access network node that has sent the error message.

2. The multicast / broadcast control unit according to claim 1, wherein the predetermined time is preset by an internal timer of the device.

3. The multicast / broadcast control unit according to claim 1 or 2, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to further execute: Information about the multicast / broadcast session is stored.

4. The multicast / broadcast control unit according to any one of claims 1 to 3, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to further execute: storing any updates received to said previously stored information regarding said multicast / broadcast session, and After the predetermined time has elapsed, the multicast / broadcast session is initiated using the most recently updated information for a retransmission attempt.

5. The multicast / broadcast control unit of claim 4, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to further perform: Information about the multicast / broadcast session is received from a multicast-broadcast session management function.

6. The multicast / broadcast control unit according to any one of claims 1 to 5, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to further execute: Prior to resending the request for allocating resources for the multicast / broadcast session to the at least one radio access network node, it is determined whether the at least one radio access network node is located in a service area designated for the multicast / broadcast session.

7. An apparatus for a radio access network, comprising: at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus to at least perform: receiving a request from a multicast / broadcast control unit for allocating resources for a multicast / broadcast session, When resources for the multicast / broadcast session cannot be allocated or resources must be released during the multicast / broadcast session, sending an error message to the multicast / broadcast control unit, the error message indicating that the resources cannot be allocated or cannot be maintained, and In response to receiving an additional request for allocating resources for the multicast / broadcast session, allocating resources for the multicast / broadcast session is retried.

8. A method for a multicast / broadcast control unit, comprising: sending a request to at least one radio access network node for allocating resources for the multicast / broadcast session, receiving an error message from at least one radio access network node, the error message indicating that the resource cannot be allocated or cannot be maintained, and After a predetermined time has elapsed, a request for allocating resources for the multicast / broadcast session is resent to the at least one radio access network node that has sent the error message.

9. The method according to claim 8, wherein the predetermined time is preset by an internal timer of the multicast / broadcast control unit.

10. The method according to claim 8 or 9, further comprising: Information about the multicast / broadcast session is stored.

11. The method according to claim 10, further comprising: storing any updates received to said previously stored information regarding said multicast / broadcast session, and After the predetermined time has elapsed, the multicast / broadcast session is initiated using the most recently updated information for a retransmission attempt.

12. The method according to claim 11, wherein the method further comprises: Information about the multicast / broadcast session is received from a multicast-broadcast session management function.

13. The method according to any one of claims 8 to 12, further comprising: Prior to resending the request for allocating resources for the multicast / broadcast session to the at least one radio access network node, it is determined whether the at least one radio access network node is located in a service area designated for the multicast / broadcast session.

14. A method for a radio access network node, the method comprising: receiving a request from a multicast / broadcast control unit for allocating resources for a multicast / broadcast session, When resources for the multicast / broadcast session cannot be allocated or resources must be released during the multicast / broadcast session, sending an error message to the multicast / broadcast control unit, the error message indicating that the resources for the multicast / broadcast session cannot be allocated or cannot be maintained, and In response to receiving an additional request for allocating resources for the multicast / broadcast session, allocating resources for the multicast / broadcast session is retried.

15. A computer program product comprising code means for executing the method according to any one of claims 8 to 14 when run on a processing means or module.

16. The computer program product according to claim 15, wherein the computer program product is embodied on a computer-readable medium, and / or the computer program product can be directly loaded into the internal memory of the computer, and / or can be sent via a network by at least one of an upload, download and push process.

17. A non-transitory computer readable medium comprising instructions which, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 8 to 14.

Images