Method and apparatus for providing local mbs in a wireless communication system

CN115699989BActive Publication Date: 2026-09-08SAMSUNG ELECTRONICS CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202180041193.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2021-03-26
Filing Date
2021-08-10
Publication Date
2026-09-08
Estimated Expiration
2041-08-10

AI Technical Summary

Benefits of technology

[0029] This invention provides a scheme for effectively switching between local MBS services and global MBS services when providing dedicated MBS services in a local area.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115699989B_ABST
    Figure CN115699989B_ABST
Patent Text Reader

Abstract

The disclosure relates to a 5G or pre-5G communication system for supporting a higher data transmission rate than a 4G communication system such as an LTE system. According to an embodiment, a method for receiving a multicast service by a UE in a wireless communication system includes receiving, from an application function (AF), a multicast service announcement message including first information related to a local multicast and broadcast service (MBS), identifying that the UE is located in a local MBS area, and transmitting, to an access and mobility management function (AMF), a multicast session join request message for joining a multicast session for the local MBS, the multicast session join request message including second information corresponding to the first information.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] To send the same data to multiple UEs located in a specific area of ​​a mobile communication network, data can be sent to each UE via unicast. In some cases, for resource efficiency, it is necessary to provide data services to multiple UEs located in the mobile communication network via multicast / broadcast.

[0002] In this context, a solution is needed for efficient switching between local MBS services and global MBS services when dedicated MBS services are provided in local areas. Background Technology

[0003] To meet the surge in demand for wireless data traffic since the introduction of 4G communication systems, efforts are underway to develop enhanced 5G or pre-5G communication systems. For this reason, 5G or pre-5G communication systems are referred to as super-4G network communication systems or post-LTE systems.

[0004] For higher data transmission rates, 5G communication systems are considered to be implemented in the ultra-high frequency band (millimeter wave) (such as 60 GHz). To mitigate path loss in the ultra-high frequency band and increase the reach of radio waves, the following technologies are considered for 5G communication systems: beamforming, massive MIMO, full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive MIMO.

[0005] Also under development are various technologies for enabling 5G communication systems to have enhanced networks, such as evolved or advanced small cells, cloud radio access networks (cloud RAN), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, mobile networks, cooperative communication, coordinated multipoint (CoMP), and interference cancellation.

[0006] There are also various other schemes being developed for 5G systems, including, for example, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) as advanced coding and modulation (ACM) schemes, and filter bank multicarrier (FBMC), non-orthogonal multiple access (NOMA) and sparse code multiple access (SCMA) as advanced access schemes. Summary of the Invention

[0007] Technical issues

[0008] To send the same data to multiple UEs located in a specific area of ​​a mobile communication network, data can be sent to each UE via unicast. In some cases, for resource efficiency, it is necessary to provide data services to multiple UEs located in the mobile communication network via multicast / broadcast.

[0009] For example, there is a need for a method to send data via multicast / broadcast to provide TV / audio services, vehicle-to-everything (V2X) services, or large-scale consumer Internet of Things (CIoT) services to multiple UEs in a specific area.

[0010] Technical solution

[0011] In order to send data via multicast / broadcast, a network function (NF) or NF service needs to be defined and can support related multicast / broadcast services (MBS), such as exposing, discovering or selecting the corresponding NF or NF service.

[0012] In this scenario, when providing dedicated MBS services in local areas, a solution is needed for efficient switching between local and global MBS services.

[0013] According to an embodiment, a method for a user equipment (UE) to receive multicast services in a wireless communication system includes: receiving a multicast service announcement message from an application function (AF) that includes first information related to local multicast and broadcast services (MBS), identifying that the UE is located in a local MBS area, and sending a multicast session join request message to an access and mobility management function (AMF) for joining a multicast session for the local MBS, the multicast session join request message including second information corresponding to the first information.

[0014] According to an embodiment, the first information associated with the local MBS may include at least one of the following: Temporary Mobility Group Identity (TMGI) for the UE, information indicating whether the local MBS is available, service area information for the local MBS, ID of the local AF, Fully Qualified Domain Name (FQDN) of the local AF, or address information for the local multicast and broadcast service user plane (MBSU).

[0015] According to an embodiment, the multicast service announcement message may further include at least one of the following: the ID of the MBS service session provided to the UE, service area information for the global MBS, the ID of the global AF, the FQDN of the global AF, or the address information for the global MBSU.

[0016] According to an embodiment, the second information included in the multicast session join request message may include at least one of the following: TMGI for the UE, ID of the MBS service session to which the UE wants to join, information indicating the service for the local MBS, ID of the local AF, or FQDN of the local AF.

[0017] According to an embodiment, the media anchor for a multicast session targeting a local MBSU can be switched from a global MBSU to a local MBSU based on second information included in the multicast session join request message.

[0018] According to an embodiment, a method for providing multicast services by an AF in a wireless communication system includes: identifying first information related to a local MBS to provide the local MBS to a UE; and sending a multicast service announcement message to the UE including the first information related to the local MBS.

[0019] When the UE is located in a local MBS area, it can send a multicast session join request message to the Access and Mobility Management Function (AMF) for the UE to join a multicast session for the local MBS.

[0020] According to an embodiment, a UE configured to receive multicast services in a wireless communication system includes a transceiver and a controller, the controller being operatively coupled to the transceiver and configured to control the transceiver to receive from the AF a multicast service announcement message including first information related to a local MBS, identify that the UE is located in a local MBS area, and send to the AMF a multicast session join request message for joining a multicast session in the local MBS, the multicast session join request message including second information corresponding to the first information.

[0021] According to an embodiment, an AF configured to provide multicast services in a wireless communication system includes a transceiver and a controller, the controller being operatively coupled to the transceiver and configured to control the transceiver to identify first information related to local multicast and broadcast services (MBS) to provide local MBS to a user equipment (UE), and to send a multicast service announcement message to the UE including the first information related to local MBS.

[0022] When the UE is located in a local MBS area, it can send a multicast session join request message to the Access and Mobility Management Function (AMF) for the UE to join a multicast session for the local MBS.

[0023] According to an embodiment, the control operation of the MB-SMF can be changed according to the MBS service (multicast service or broadcast service) requested by the AF or content provider, which can be differentiated according to the service.

[0024] As is apparent from the foregoing description, embodiments of this disclosure can provide MBS services capable of effectively switching between local MBS services and global MBS services in a 5G system (5GS).

[0025] Before proceeding with the detailed description below, it may be advantageous to define certain words and phrases used throughout this patent document: the terms “comprising” and “containing” and their derivatives mean unrestricted inclusion; the term “or” is inclusive, meaning and / or; the phrases “associated with” and “associated with” and their derivatives can mean including, being included in, interconnected with, containing, contained within, connected to or connected with, coupled to or coupled with, able to communicate with, cooperate with, intertwine, juxtapose, proximate, bound to or bound with, having, possessing the properties of, etc.; and the term “controller” means any device, system, or part thereof that controls at least one operation, such device may be implemented in hardware, firmware, or software, or some combination thereof. It should be noted that the functionality associated with any particular controller can be centralized or distributed, local or remote.

[0026] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each computer program being formed by computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, associated data, or portions thereof suitable for implementation in appropriate computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drives, compact optical discs (CDs), digital video optical discs (DVDs), or any other type of storage. "Non-transitory" computer-readable media does not include wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable media includes media that can permanently store data and media that can store data and later rewrite it, such as rewritable optical discs or erasable memory devices.

[0027] Definitions of certain words and phrases are provided throughout this patent document, and those skilled in the art should understand that, in many (if not most) cases, such definitions apply to the prior and future use of the words and phrases defined in this way.

[0028] Technical effect

[0029] This invention provides a scheme for effectively switching between local MBS services and global MBS services when providing dedicated MBS services in a local area. Attached Figure Description

[0030] A more complete and better understanding of this disclosure and its many accompanying aspects will be readily available and readily understood when considered in conjunction with the accompanying drawings, and by referring to the following detailed description, in which:

[0031] Figure 1 A 5GS structure for MBS according to an embodiment is shown;

[0032] Figure 2a and Figure 2b The process of switching from a global MBS service to a local MBS service according to an embodiment is illustrated;

[0033] Figure 3a and Figure 3b The process of switching from a local MBS service to a global MBS service according to an embodiment is illustrated;

[0034] Figure 4 A block diagram of the internal structure of the UE according to an embodiment is shown;

[0035] Figure 5 A block diagram illustrating the structure of a network entity according to an embodiment is shown;

[0036] Figure 6 A flowchart of a method for receiving multicast services by a UE according to an embodiment is shown; and

[0037] Figure 7a and Figure 7b A flowchart illustrating a method for creating a session for 5GS MBS services according to an embodiment is shown. Detailed Implementation

[0038] The following discussion Figures 1 to 7b The various embodiments used to describe the principles of this disclosure in this patent document are merely illustrative and should not be construed as limiting the scope of this disclosure in any way. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or device.

[0039] The operating principles of this disclosure are described below with reference to the accompanying drawings. Details of known functions or configurations may be omitted when it is determined that the subject matter of this disclosure is unclear. The terminology used herein is defined with reference to the functions described in this disclosure and may be replaced with other terms depending on the intent or practice of the user or operator. Therefore, these terms should be defined based on the entire disclosure.

[0040] As used herein, for ease of description, terms for identifying access nodes, denoteing network entities, denoteing messages, denoteing inter-network entity interfaces, and denoteing various identification information are provided as examples. Therefore, this disclosure is not limited to these terms, and these terms may be replaced by other terms denoteing objects with equivalent technical meanings.

[0041] For ease of description, this disclosure uses the terms and names defined in the 5G system standards. However, this disclosure is not limited to such terms and names and may be equally applied to systems conforming to other standards.

[0042] In this document, the term "global" is the opposite of the term "local," indicating that it is not limited to a specific area, such as a local MBS service area. As used herein, global MBS service, global MBS service area, global AF, global MBSU, global MB-UPF, global service, and global multicast session are specified by the term "global" to represent the opposite concepts of local MBS service, local MBS service area, local AF, local MBSU, local MB-UPF, local service, and local MBS service (i.e., indicating that they are not used in a local area), and are used to refer to MBS service, MBS service area, AF, MBSU, MB-UPF, service, and multicast session in general.

[0043] Preferably, when a user equipment (UE) switches to local MBS service, the MBS group ID (e.g., TMGI) and multicast service session ID are not changed. Otherwise (i.e., if the MBS group ID and multicast service session ID are changed when switching to local MBS service), a continuous update procedure for the UE and a location-based complex detection procedure or multi-session ID setting procedure are required.

[0044] Furthermore, when the MBS group ID is shared among multiple AFs, some AFs can provide local services to their local AFs, but other AFs do not provide local services (where AFs can be distinguished by multicast service session IDs).

[0045] For example, some multicast services support some local MBS services (e.g., some local AFs exist), but other multicast services do not support local MBS services (e.g., no other MBS content is provided for the local service area, and no local AFs exist).

[0046] Therefore, regardless of whether the UE uses the local MBS service, an MBS group ID and a multicast service session ID are assigned to the multicast group.

[0047] For multicast services that support local MBS services, when a UE moves to a local MBS service area and requests support for local MBS services, localized nodes (e.g., local MB-UPF, local MBSU, or local AF) can be used to represent (non-local) MB-UPF / MBSU / AF local MBS services, depending on the UE's location and the UE's request to subscribe to the local MBS service.

[0048] Figure 1 The structure of a cellular system for MBS service according to an embodiment is shown.

[0049] refer to Figure 1 The cellular system may include UE 10, NG Radio Access Network / NG Multi-Cell / Multicast Coordination Entity (NG-RAN / NG-MCE) 11, Access and Mobility Management Function (AMF) 12, Local Multicast / Broadcast User Plane Function (MB-UPF) 13, Multicast / Broadcast Session Management Function (MB-SMF) 14, Policy Control Function (PCF) 15, MB-UPF 16, Network Exposure Function (NEF) 17-1, Multicast / Broadcast Service Function (MBSF) 17-2, Multicast / Broadcast Service User Plane (MBSU) 17-3, Local MBSU 17-4, Global Application Function (AF) 18-1, Local AF 18-2, Unified Data Management (UDM) 19-1, and AUSF 19-2.

[0050] To support MBS services in traditional 5GS, cellular systems for MBS can be configured with the following network functions and services.

[0051] AF18-1 and 18-2 can be implemented as, for example, V2X application servers, CIoT application servers, MCPTT applications, content providers, TV or audio service providers, or streaming video service providers.

[0052] MBSF 17-2 is a network function that manages sessions for MBS services and controls the traffic for MBS services if AF 18-1 or 18-2 requests MBS services. MBSU 17-3 is the MBS service media anchor in 5GS, which receives media from content providers and processes media traffic based on the control of MBSF 17-2.

[0053] The interface between MBSF 17-2 and MBSU 17-3 is referred to as the Nxxx interface. According to embodiments, MBSU 17-3 and MBSF 17-2 can be integrated into a single entity or an NF.

[0054] MBSF 17-2 can be integrated into NEF 17-1 or another NF.

[0055] MBS service sessions are managed and service traffic is generated via MBSF 17-2 and MBSU 17-3. When service traffic is delivered to the UE via multicast / broadcast, MBS PDU sessions can be allocated to manage the traffic.

[0056] The control functions or services used to create MBS contexts for MBS PDU sessions, manage MBS PDU sessions, and deliver traffic of MBS PDU sessions to NG-RAN 11 via IP multicast are collectively referred to as the Multimedia Broadcast Multicast Service Gateway Control Plane (MBMS-GW-C) service.

[0057] The MBMS-GW-C service can be integrated into an existing SMF that manages unicast PDU sessions and can be configured as an SMF with MBS PDU session control capabilities, or it can be configured as a standalone NF. An NF that supports the MBMS-GW-C service and also has the functionality of an existing SMF may be referred to as MB-SMF 14 in this document.

[0058] The service that transmits traffic received from MB-UPF 16 via IP multicast to NG-RAN 11, which performs multicast / broadcast according to the MBS context for the MBS PDU session, is collectively referred to as the Multimedia Broadcast-Multicast Service Gateway-User Plane (MBMS-GW-U) service.

[0059] The MBMS-GW-U service can be integrated into an existing UPF that handles unicast PDU sessions and can be configured as a UPF with the ability to deliver MBS traffic to the appropriate NG-RAN via IP multicast, or it can be configured as a separate NF.

[0060] An NF that supports MBMS-GW-U services and also has the functionality of an existing UPF can be referred to as MB-UPF16 in this document.

[0061] The MBMS-GW-C service uses the N4-MBS interface to control the MBMS-GW-U service.

[0062] In describing the various embodiments of this disclosure, for convenience, MBMS-GW-C and MBMS-GW-U are primarily described as the terms “SMF” and “UPF”, or as the terms “MB-SMF” and “MB-UPF”, respectively; however, their use may be indicated together where necessary (e.g., whether they are used only for unicast, only for multicast / broadcast, or both) to avoid confusion.

[0063] MBS traffic is delivered from MBMS-GW-U (or UPF or MB-UPF) to NG-RAN. For example, MBS traffic is transmitted to NG-RAN using IP multicast. In this case, the tunnel between MBMS-GW-U (or UPF or MB-UPF) and NG-RAN is referred to as the M1 tunnel, shared delivery tunnel, or shared N3 tunnel.

[0064] To establish the M1 tunnel, MBMS-GW-C (or SMF or MB-SMF) sends control messages to NG-RAN via AMF.

[0065] For both local and (global) MBS services, all or some of the AF, MBSU, or MB-UPF can be located near a specific local area to serve MBS services within that specific local area. These can be referred to as local AF, local MBSU, and local MB-UPF.

[0066] Local MBSU 17-4 and (global) MBSU can be controlled via MBSF, and local MB-UPF 13 and (global) MB-UPF can be controlled via MB-SMF.

[0067] In another deployment scenario, according to an embodiment, for local MBS services, all or some of the MBSF or MB-SMF, as well as the AF, MBSU, or MB-UPF, can be located near a specific local area for use in MBS services within that specific local area. These are referred to as local MBSF and local MB-SMF.

[0068] Figure 2a and Figure 2b The process for initiating an MBS session on a 5G network and switching from a global MBS service to a local MBS service, according to an embodiment, is illustrated.

[0069] refer to Figure 2a and Figure 2b The cellular system may include UE 20, NG radio access network (NG-RAN) 21, AMF 22, local MB-UPF 23, MB-SMF 24, PCF 25, MB-UPF 26, network exposure function / multicast / broadcast service function (NEF / MBSF) 27 and global or local application function (AF) 28.

[0070] refer to Figure 2a and Figure 2b The scenario described describes a localized entity in which local MB-UPF 23, local MBSU, and local AF28 are used for localized MBS services.

[0071] refer to Figure 2aIn operation 200, UE 20, NG-RAN 21, and AMF 22 can perform registration and PDU session establishment procedures. These procedures can be performed, for example, via app signaling.

[0072] In Operation 201, AF 28 or a content provider may request MBS service and simultaneously deliver information regarding the MBS service to MBSF 27 in order to provide MBS service via 5GS.

[0073] Information for MBS services may include a service ID indicating the type of MBS service (e.g., TV service, video service, radio service, IoT service, V2X service, or public safety service) or information that includes more detailed service information (e.g., a service ID indicating an IoT service for a specific company's subscribers, an x-channel TV service, a police network service within a public safety service, or a firefighter network service within a public safety service).

[0074] Information for MBS services may also include information about the MBS service area in which MBS services are provided (e.g., all or part of the area information for a physical map or a list of cell IDs or a list of tracking area identifiers (TAIs).

[0075] Information for MBS services may also include a list of multicast group IDs (e.g., a list of TMGIs or a range of corresponding Temporary Mobile Group Identifiers (TMGIs)) that serve as a list of UE groups capable of receiving the service.

[0076] Information regarding MBS services may also include characteristics of traffic generated by MBS services (e.g., 5QI, resource type (e.g., all or some of GBR, delay-critical GBR, or non-GBR), maximum bit rate, guaranteed bit rate, maximum delay tolerance, maximum packet loss rate, priority level, and maximum data burst size) as QoS information.

[0077] Information regarding MBS services may also include information about local MBS services within a specific local area. For example, information about a local MBS service area may include all or part of the area information for the actual map, cell ID list, and TAI list, or it may include service information for local MBS services within a local service area.

[0078] In operation 201, the MBSF 27, which receives the request, can send the information received in operation 201 and the characteristic information of the traffic generated due to the MBS service obtained in operation 202 to the PCF 25, and can receive authorization for the service in operation 203. In other words, in operation 202, the MBSF / NEF 27 can send a policy authorization request to the PCF 25. In operation 203, the MBSF / NEF 27 can receive a policy authorization response from the PCF 25 as a response to the policy authorization request. Furthermore, the MBSF 27 can additionally identify authorization for the MBS service for the multicast group ID from the UDM.

[0079] If the MBS service is determined to be authorized, in operation 204, MBSF 27 can establish an MBS service session, assign an MBS service session ID, determine the ID of the group (e.g., TMGI value) of the UE using the service, select an MBSU corresponding to the MBS service area, and obtain address information for the MBSU. Furthermore, the multicast group ID information and the address or ID of the MBSF that assigns and manages the MBS service session ID can be stored in the UDM.

[0080] According to an embodiment, when a separate local MBSU is configured for a location corresponding to a local MBS service, MBSF 27 can obtain address information (e.g., a list of TAIs or a list of cell IDs) for the local MBSU corresponding to each local MBS service area.

[0081] In operation 205, NEF / MBSF 27 may transmit an MBS service response to AF 28 containing information determined (or obtained) via operations 202 to 204. For example, at least one of the following may be transmitted to AF 28 via operation 205: the address of the MBSU corresponding to the determined TMGI and MBS service area, the address information of the local MBSU corresponding to each local MBS service area, or the MBS service session ID information.

[0082] In operation 206, AF 28 may transmit information for UE 20 to receive multicast services via an announcement message (multicast service announcement message or multicast service declaration message).

[0083] The notification message may include at least one of the following: the UE's multicast group ID (e.g., TMGI), the ID of the MBS service session to be received by the UE, (global) MBS service area information, DNN information, the ID (or FQDN or IP address) of the (global) AF, or the FQDN (or IP address) of the (global) MBSU.

[0084] In addition, if local MBS service is possible for AF or MBS service sessions, the announcement message may include indications to indicate that local MBS service is possible, and the announcement message may include information to be used in the local MBS service area.

[0085] For example, the notification message may include at least one of the following: (local) MBS service area information, (local) AF ID (or FQDN or IP address), or (local) MBSU FQDN (or IP address).

[0086] When different local AFs or local MBSUs serving a local MBS service area are configured by cell or by TA, the announcement message may include the ID, FQDN, or IP address of the (local) AF, or the FQDN or IP address of the (local) MBSU for each cell or TA.

[0087] As another method, UE 20 can obtain information to be used in the local MBS service area. When it is detected that UE 20 has relocated in the local MBS service area, UE 20 can send an MBS service information request to the global or local AF 28, which includes the location of UE 20's current location and an indication of the local MBS service.

[0088] For example, an MBS service information request message may include Global Positioning System (GPS) information for UE 20 and information for the TA or cell that is connected to UE 20.

[0089] Upon receiving an MBS service information request message, AF 28 can send information to UE 20 regarding the local MBS service corresponding to the location information.

[0090] For example, information for a local MBS service corresponding to location information may include at least one of the following: TMGI, ID of the MBS service session to be received by the UE, (local) MBS service area information, ID (or FQDN or IP address) of the (local) AF, or FQDN (or IP address) of the (local) MBSU.

[0091] According to an embodiment, if the MBS service session makes the MBS service available only in the local MBS service area, then the information can be included only in the information for the local MBS service, and if the MBS service is available in both the global MBS service area and the local MBS service area, then the MBS service session ID can be shared between the local service and the global service.

[0092] In operation 207, UE 20 may send a NAS message to AMF 22 to join a multicast session, and AMF 22 may select an appropriate MB-SMF 24 and transmit the join request message for the multicast session received from UE 20 to the selected MB-SMF 24.

[0093] The join request message for a multicast session, which is a NAS message sent from UE 20 to AMF 22, may include at least one of the following: the ID of the multicast group to which UE 20 belongs (e.g., TMGI), the MBS service session ID as information for the MBS service session to be joined, the DNN information as information for AMF 22 to select MB-SMF 24, or the corresponding AF ID.

[0094] NAS messages can be implemented as standalone NAS messages, PDU session establishment request messages, or PDU session modification request messages.

[0095] Upon receiving a join message, MB-SMF 24 can request and obtain SM subscription data from the UDM to determine whether the UE can receive the MBS service via the multicast group ID. MB-SMF 24 can also request and obtain SM subscription data from the UDM to determine whether the UE can receive the MBS service session ID via the multicast group ID. Furthermore, MB-SMF 24 can calculate the ID or address of the MBSF managing the MBS service session ID from the UDM using the multicast group ID.

[0096] If an MB session for the MBS service session has not yet been established, in operation 208, MB-SMF 24 may send a message to NEF / MBSF 27 requesting to join the multicast session (a notification to join the service).

[0097] The join request message (notification of joining service) may include at least one of the following: the ID of the multicast group to which UE 20 belongs (e.g., TMGI), the MBS service session ID as information for the MBS service session to be joined, or the corresponding AF ID.

[0098] Even if an MB session for the MBS service session has already been established, in operation 208, the MB-SMF 24 that receives the join message can also notify the UE 20 that it has requested the NEF / MBSF 27 to join the multicast session.

[0099] MB-SMF 24, PCF 25, and NEF / MBSF 27 can execute programs for global services (operations 209 to 212).

[0100] The MBSF 27 that receives the join message can determine whether the join request is accepted and whether the UE can use the MBS service based on its own information or from the UDM or AF.

[0101] When it is determined that the UE can use MBS services, in operation 209, MBSF 27 can request MB-SMF 24 to establish an MB session, and in operation 210, MB-SMF 24 can receive service authorization from PCF 25.

[0102] MB-SMF 24 can request and obtain SM subscription data from UDM to determine whether the UE can receive MBS service via multicast group ID. MB-SMF 24 can also request and obtain SM subscription data from UDM to determine whether the UE can receive MBS service session ID via multicast group ID.

[0103] In operation 211, MB-SMF 24 can select MB-UPF 26 to establish a shared delivery tunnel for the MB session and establish N4. In operation 212, MB-SMF 24 can send an MB session establishment response message to NEF / MBSF27, including information about the MB session ID and the obtained tunnel endpoint information for MB-UPF 26, and establish an MB session for the (global) multicast service.

[0104] refer to Figure 2b If no shared delivery tunnel is set up for the MB session, i.e., the shared N3 tunnel between NG-RAN21 and MB-UPF 26, then in operation 213, a shared delivery tunnel can be generated between NG-RAN21 and MB-UPF 26.

[0105] In other words, MB-SMF 24 can transmit an SM N2 message containing tunnel endpoint information for MB-UPF 26 for the shared delivery tunnel to NG-RAN 21 via AMF 22, establish resources for shared delivery to NG-RAN 21, and request MB-SMF 24 to join the IP multicast from MB-UPF 26 to NG-RAN 21 for the MB session. Therefore, MB-SMF 24 can receive information from MB-UPF 26 and establish a shared delivery tunnel between NG-RAN 21 and MB-UPF 26.

[0106] In response to the join request from UE 20 in operation 207, the NAS message and the N2 SM message or N2 MM message for UE 20 can be transmitted to NG-RAN 21 via operations 213a and 213b adjacent to operation 213, and NG-RAN 21 can manage the context of the MB session for shared delivery and the SM context of the PDU session for UE 20.

[0107] Therefore, NG-RAN 21 can calculate (or determine) which UE should be forwarded to for MBS traffic transmitted via shared delivery.

[0108] NG-RAN 21 can transmit AS messages containing NAS messages to UE 20. The NAS message may include, for example, TMGI information and the result of joining, and the AS message may include information about the RAN resources to be used by UE 20.

[0109] If, in operation 214, UE 20 knows that it is located in the local MBS service area through, for example, the cell ID value or TA value obtained from NG-RAN 21, then in operation 215, UE 20 may send a NAS message to AMF 22 to request to join a multicast session for the local MBS service in order to receive the local MBS service, and AMF 22 may transmit the multicast session join request message received from UE 20 to MB-SMF 24.

[0110] The NAS message sent from UE 20 to AF 28 for requesting to join a multicast session may include a local MBS indication for a local MBS service, and may include the ID of the multicast group to which UE 20 belongs (e.g., TMGI), the MBS service session ID as information for the MBS service session to be joined, DNN information as information for AMF 22 to select MB-SMF 24, or at least one of the corresponding ID or FQDN.

[0111] If the AF ID or FQDN from the AF indicates that the request from UE 20 is for joining a local MBS service, then the local MBS indication can be excluded because the AF corresponding to the local MBS service is different from the AF for the global MBS service. Instead of a separate NAS message, a PDU session establishment request message or a PDU session modification request message can be used.

[0112] Upon receiving the join message, MB-SMF 24 can request and obtain SM subscription data from the UDM to determine whether the UE can receive local MBS services via the multicast group ID.

[0113] MB-SMF 24 can request and obtain SM subscription data from UDM to determine whether the UE can receive the MBS service session ID via the local MBS service using the multicast group ID. Furthermore, MB-SMF 24 can calculate the ID or address of the MBSF managing the MBS service session ID from UDM using the multicast group ID.

[0114] If an MB session for a local MBS service has not yet been established for the MBS service session, in operation 216, MB-SMF 24 can send a message to request NEF / MBSF 27 to join the multicast session.

[0115] The join request message may include a local MBS indication of the local MBS service, and may include the ID of the multicast group to which UE 20 belongs (e.g., TMGI), the MBS service session ID as information for the MBS service session to be joined, and all or some of the corresponding AF IDs. Even if an MB session for the MBS service session has already been established, in operation 216, the MB-SMF 24 that receives the join message may also notify UE 20 that it has requested NEF / MBSF 27 to join the multicast session.

[0116] If local MBS service is possible for an MBS service session, then in operation 217, NEF / MBSF 27 and AF 28 can switch the media anchor used for the MBS service session from the global MBSU to the local MBSU. If no MBS service session is created between the local MBSU and the local AF in this step, MBSF 27 can update it with a changed local MBSU address for AF 22.

[0117] In operation 218, NEF / MBSF 27 requests MB-SMF 24 to establish an MB session for the local MBS service, and in operation 219, MB-SMF 24 can perform a service authorization procedure with PCF 25. MB-SMF 24 can request and obtain SM subscription data from UDM to determine whether the UE can receive the local MBS service via the multicast group ID. MB-SMF 24 can also request and obtain SM subscription data from UDM to determine whether the UE can receive the MBS service session ID via the local MBS service via the multicast group ID.

[0118] In operation 220, MB-SMF 24 can select MB-UPF and establish N4 to establish a shared delivery tunnel for the MB session. In operation 221, MB-SMF 24 can send the obtained MB-UPF tunnel endpoint information and MB session ID information to NEF / MBSF 27 through the MB session establishment response message, and can establish an MB session for the (local) multicast service.

[0119] If a shared delivery tunnel, i.e. a shared N3 tunnel between NG-RAN 21 and (local) MB-UPF 23, has not yet been set up for an MB session serving local MBS, a shared delivery tunnel can be created in operation 222.

[0120] In other words, MB-SMF 24 can transmit an SM N2 message containing tunnel endpoint information for MB-UPF 26 for the shared delivery tunnel to NG-RAN 21 via AMF 22, establish resources for shared delivery to NG-RAN 21, and request MB-SMF 24 to join the IP multicast from MB-UPF 26 to NG-RAN 21 for the MB session. Therefore, MB-SMF 24 can receive information from MB-UPF 26 and establish a shared delivery tunnel between NG-RAN 21 and MB-UPF 26.

[0121] A NAS or AS message in response to the join request from UE 20 in operation 215 may be transmitted to UE 20 in operation 222. If the response message is a NAS message, it may include information such as local MBS indication and TMGI, as well as the result of the join; and if it is an AS message, it may include information about the RAN resources to be used by UE 20.

[0122] To check whether UE 20 is in the local MBS area, AMF 22 or NG-RAN 21 can update MB-SMF 24 with location information for UE 20. For example, when UE 20 leaves the local MBS area, it can notify MB-SMF 24.

[0123] Even after using the local MBSU as the media anchor for local MBS service in operation 217, global MBS service can continue to serve other UEs via the global MBSU. However, since it is not necessary to maintain a shared delivery tunnel with global MB-UPF 26 and a shared delivery tunnel with local MB-UPF 23 for the same MBS service session for the same NG-RAN, it is not necessary to maintain a shared delivery tunnel between NG-RAN and global MB-UPF for the MBS service session.

[0124] In operation 223a, MBSF 27 can suspend the join status of the global MBS service for UE 20. Alternatively, in order to stop the MB session for the global MBS service from forwarding traffic from global MB-UPF 26 to NG-RAN 21, in operation 223b, MB-SMF 24 can suspend NG-RAN 21 join IP multicast, exclude NG-RAN 21 when forwarding traffic for the global MBS service from global MB-UPF 26, or switch the MB session to an inactive state or deactivate the MB session.

[0125] Figure 3a and Figure 3b The procedure for initiating an MBS session on a 5G network and switching from a local MBS service to a global MBS service, according to an embodiment, is illustrated.

[0126] Examples are described in conjunction with embodiments in which local MB-UPF, local MBSU, and local AF are used as localized entities for local MBS services.

[0127] Figure 3a and Figure 3b Some operations or procedures and Figure 2a and Figure 2b Some operations or procedures are basically the same, so they will not be described repeatedly.

[0128] refer to Figure 3a and Figure 3b The cellular system may include UE 30, NG-RAN 31, AMF 32, Multicast / Broadcast User Plane Function (MB-UPF) 33, MB-SMF 34, PCF 35, Local MB-UPF 36, NEF / MBSF 37, and Global or Local AF 38.

[0129] Figure 3a The procedures shown for initiating an MBS session (operations 301 to 306) are essentially performed through the same procedures described above in conjunction with Figure 2. In other words, for MBS service, AF 38 requests NEF / MBSF 37 to create MBS service and sends a service advertisement message to UE 30 (operations 301 to 306).

[0130] In operation 307, UE 30 identifies itself in the local MBS area, and in operation 308, UE 30 can send a join request for using the local MBS service. This request is transmitted to NEF / MBSF 37 to establish an MB session for the local MBS service via local MBSU, local MB-UPF 36, and local AF 38 (operations 309 to 313). Therefore, a tunnel for shared delivery is established (operation 314).

[0131] In response to the join request from UE 20 in operation 308, the NAS message and the N2 SM message or N2 MM message for UE 30 can be transmitted to NG-RAN 31 via operations 314a and 314b adjacent to operation 314, and NG-RAN 31 can manage the context of the MB session for shared delivery and the SM context of the PDU session for UE 30.

[0132] Therefore, NG-RAN 31 can calculate (or determine) which UE should be forwarded to for MBS traffic transmitted via shared delivery.

[0133] NG-RAN 31 can transmit AS messages containing NAS messages to UE 30. The NAS message may include, for example, TMGI information and the result of joining, and the AS message may include information about the RAN resources to be used by UE 30.

[0134] To check whether UE 30 is in the local MBS area, AMF 32 or NG-RAN 31 can maintain and update MB-SMF 34 with location information for UE 30. For example, when UE 30 leaves the local MBS area, AMF 32 or NG-RAN 31 can provide a notification to MB-SMF 34.

[0135] If UE 30, which is receiving local MBS services, moves out of the local MBS area (operation 315), then UE 30 may no longer receive local MBS services, and if UE 30 is in the global MBS area, then UE 30 may continue to receive global MBS services.

[0136] If the NG-RAN 31 to which UE 30 has moved does not provide traffic for the MBS service session to the multicast group ID (e.g., TMGI) corresponding to UE 30, then in operation 316, UE 30 may send a NAS message to AMF 32 to join the multicast session, and AMF 32 may transmit the message received from UE 30 for requesting to join the multicast session to MB-SMF 34.

[0137] A join request message for a multicast session, which is a NAS message sent from UE 30 to AMF 32, may include the ID of the multicast group to which UE 30 belongs (e.g., TMGI), the MBS service session ID as information for the MBS service session to be joined, DNN information, and all or some of the corresponding AF ID. The NAS message may be implemented as a separate NAS message, a PDU session establishment request message, or a PDU session modification request message.

[0138] Conversely, if the NG-RAN 31 to which UE 30 has moved is already providing traffic for the MBS service session to the multicast group ID (e.g., TMGI) corresponding to UE 30, then UE 30 may not need to send a separate join message.

[0139] Alternatively, if MB-SMF 34 receives a notification from AMF 32 or NG-RAN 31 that UE 30 has left the local MBS area, even though no separate join message is received from UE 30, then in operation 317, MB-SMF 34 may send a message to NEF / MBSF 37 instructing it to leave the local area and join the global multicast session (notification of leaving the local service area).

[0140] The notification message (notification beyond the local service area) may include the ID of the multicast group to which the UE 30 belongs (e.g., TMGI), the MBS service session ID as information for the MBS service session to be joined, and all or some of the corresponding AF IDs.

[0141] If no MB session is set up for the MBS service session, in operation 317, the MB-SMF 34 that receives the join message can send a notification message to the NEF / MBSF 37 indicating that it should leave the local area and join the global multicast session (notification of leaving the local service area).

[0142] The notification message (notification beyond the local service area) may include the ID of the multicast group to which the UE belongs (e.g., TMGI), the MBS service session ID as information for the MBS service session to be joined, and all or some of the corresponding AF IDs.

[0143] Even if an MB session for an MBS service session has already been established, in operation 317, the MB-SMF 34 that receives the join message can also transmit a notification to indicate that the UE 30 has requested the NEF / MBSF 37 to join the multicast session.

[0144] In operation 318, MBSF 37, which receives the join message, can request MB-SMF 34 to establish an MB session. In operation 319, MB-SMF 34 can perform a service authorization procedure with PCF 35. Then, in operation 320, MB-SMF 34 can select MB-UPF 33 and establish N4 to establish a shared delivery tunnel for the MB session.

[0145] In operation 321, MB-SMF 34 can send an MB session establishment response message to NEF / MBSF 37, including information about the MB session ID and the tunnel endpoint information obtained for MB-UPF 33, and establish an MB session for the global multicast service.

[0146] If a shared delivery tunnel, i.e. a shared N3 tunnel between NG-RAN 31 and MB-UPF33, has not yet been set up for the MB session, a shared delivery tunnel can be created in operation 322.

[0147] In operations 322a and 322b, MB-SMF 34 can transmit SM N2 messages containing tunnel endpoint information for MB-UPF 33 for the shared delivery tunnel to NG-RAN 31 via AMF 32.

[0148] In operation 322c, NG-RAN 31 can establish resources for shared delivery (RAN resource establishment). In operations 322d to 322g, MB-SMF 34 can be requested to join an IP multicast from MB-UPF 33 to NG-RAN 31 for an MB session. Therefore, MB-SMF 34 can transmit information to MB-UPF 33, thereby establishing a shared delivery tunnel between NG-RAN 31 and MB-UPF 33.

[0149] Using the above method, UE 30 can receive MBS services in the local MBS area, and switch to global MBS services if it leaves the local MBS area.

[0150] Figure 4 A block diagram of the internal structure of the UE according to an embodiment is shown.

[0151] The above combination Figures 1 to 3b The described UE can correspond to Figure 4 UE. Reference Figure 4 The UE may include a transceiver 410, a memory 420, and a controller 430 (also referred to as a processor 430). The transceiver 410, controller 430, and memory 420 of the UE can operate according to the communication method described above. However, the components of the UE are not limited to these. For example, the UE may include more or fewer components than those described above. The transceiver 410, controller 430, and memory 420 may be implemented as a single chip. The controller 430 may include one or more processors.

[0152] Transceiver 410 is collectively referred to as a transmitter and receiver of a UE, and can transmit and receive signals to / from a base station, network entity, server, or another UE. The signals transmitted and received to / from a base station, network entity, server, or another UE may include control information and data. For this purpose, transceiver 410 may include a radio frequency (RF) transmitter for up-converting and amplifying the transmitted signals, and an RF receiver for low-noise amplification of the received signals and down-converting the frequency of the received signals. However, this is merely an example of transceiver 410, and the components of transceiver 410 are not limited to RF transmitters and RF receivers.

[0153] The transceiver 410 can receive signals via a radio channel, output signals to the controller 430, and transmit signals output from the controller 430 via a radio channel.

[0154] The memory 420 can store programs and data required for UE operation. The memory 420 can store control information or data included in signals received by the UE. The memory 420 can include storage media such as ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media. The memory 420 can be embedded in the controller 430, rather than being provided separately.

[0155] The controller 430 can control a series of processes of the UE to enable operation according to the above embodiments. For example, the controller 430 can receive and process control signals and data signals through the transceiver 410. The controller 430 can also transmit the processed control signals and data signals through the transceiver 410. Multiple controllers 430 may be provided. The controller 430 can control components of the UE by executing a program stored in the memory 420.

[0156] Figure 5 A block diagram illustrating the structure of a network entity according to an embodiment is shown.

[0157] refer to Figures 1 to 3b Each network entity described may include Figure 5 Components. Figure 1 Each of the following shown can include: NG-RAN / NG-MCE 11, AMF 12, Local MB-UPF 13, MB-SMF 14, PCF 15, MB-UPF 16, NEF 17-1, MBSF 17-2, MBSU 17-3, Local MBSU 17-4, Global AF 18-1, Local AF 18-2, UDM 19-1, and AUSF 19-2. Figure 5 Components.

[0158] Figure 2a and Figure 2b Each of the following shown can include: NG-RAN 21, AMF 22, local MB-UPF 23, MB-SMF 24, PCF 25, MB-UPF 26, NEF / MBSF 27, and global or local AF 28. Figure 5 Components.

[0159] Figure 3a and Figure 3b Each of the following shown can include: NG-RAN 31, AMF 32, MB-UPF 33, MB-SMF 34, PCF 35, local MB-UPF 36, NEF / MBSF 37, and global or local AF 38. Figure 5 Components.

[0160] refer to Figure 5 The network entity according to the embodiment may include a transceiver 510, a memory 520, and a controller 530. The transceiver 510, controller 530, and memory 520 of the network entity can operate according to the communication method of the network entity described above.

[0161] However, the components of a network entity are not limited to these. For example, a network entity may include more or fewer components than those described above. Transceiver 510, controller 530, and memory 520 may be implemented as a single chip. Controller 530 may include one or more processors.

[0162] Transceiver 510 is collectively referred to as a transmitter and receiver, and can transmit and receive signals to / from a base station, UE, network entity, or server. The signals transmitted and received to / from the base station, UE, network entity, or server may include control information and data. For this purpose, transceiver 510 may include a radio frequency (RF) transmitter for up-converting and amplifying the transmitted signals, and an RF receiver for low-noise amplification of the received signals and down-converting the frequency of the received signals. However, this is merely an example of transceiver 510, and the components of transceiver 510 are not limited to RF transmitters and RF receivers.

[0163] The transceiver 510 can receive signals via a radio channel, output signals to the controller 530, and transmit signals output from the controller 530 via a radio channel.

[0164] Memory 520 can store programs and data required for the operation of the network entity or server. Memory 520 can store control information or data included in signals received by the network entity or server. Memory 520 can include storage media such as ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media. Memory 520 can be embedded in controller 530, rather than being provided separately.

[0165] Controller 530 can control a series of operations to allow network entities or servers to operate as described in the above embodiments. For example, controller 530 can receive and process control and data signals via transceiver 510. Controller 530 can also transmit the processed control and data signals via transceiver 510. Multiple controllers 530 may be provided. Controller 530 can control components of the network entity by executing a program stored in memory 520.

[0166] Figure 6 A flowchart of a method for receiving multicast services by a UE according to an embodiment is shown.

[0167] refer to Figure 6 In operation 600, the user equipment (UE) can receive a multicast service announcement message from the application function (AF) that includes first information related to local multicast and broadcast services (MBS) in order to receive multicast services.

[0168] In operation 610, the UE can identify whether the UE is located in a local MBS area.

[0169] If the UE is located in a local MBS area, the UE can send a multicast session join request message to the Access and Mobility Management Function (AMF), MB-SMF, or MBSF to join a multicast session for the local MBS. The multicast session join request message includes second information corresponding to the first information.

[0170] According to an embodiment, the first information associated with the local MBS may include at least one of the following: Temporary Mobility Group Identity (TMGI) for the UE, information indicating whether the local MBS is available, service area information for the local MBS, ID of the local AF, Fully Qualified Domain Name (FQDN) of the local AF, or address information for the local multicast and broadcast service user plane (MBSU).

[0171] According to an embodiment, the multicast service announcement message may further include at least one of the following: the ID of the MBS service session provided to the UE, service area information for the global MBS, the ID of the global AF, the FQDN of the global AF, or the address information for the global MBSU.

[0172] According to an embodiment, the second information included in the multicast session join request message may include at least one of the following: TMGI for the UE, ID of the MBS service session to which the UE wants to join, information indicating the service for the local MBS, ID of the local AF, or FQDN of the local AF.

[0173] According to an embodiment, the media anchor for a multicast session targeting a local MBSU can be switched from a global MBSU to a local MBSU based on second information included in the multicast session join request message.

[0174] Figure 7a and Figure 7b This is a flowchart illustrating a method for creating a session for an MBS service for 5GS according to an embodiment. Figure 7a and Figure 7b The procedure for creating MBS sessions for multicast and broadcast services is shown.

[0175] refer to Figure 7a and Figure 7b The cellular system may include UE 70, NG-RAN 71, AMF 72, Session Management Function (SMF) 73, MB-SMF 74, PCF 75, MB-UPF 76, NEF / MBSF 77 and Application Function (AF) 78.

[0176] refer to Figure 7a In Operation 701, the AF 78 or the content provider may send a request (TMGI allocation request) to the NEF / MBSF 77 to allocate TMGIs for a set of UEs to be used to specify the use of the service before requesting the initiation of MBS service, in order to provide MBS service via 5GS. In Operation 702, the NEF / MBSF 77 may perform authorization for the TMGI allocation request.

[0177] In operation 702, upon receiving a TMGI allocation request, NEF / MBSF 77 can check whether the request is allowed. If the TMGI allocation request is allowed in operation 702, then in operation 703, NEF / MBSF 77 can request MB-SMF 74 to allocate a TMGI. The request message (TMGI allocation request) in operations 701 and 703 can include an existing TMGI value or the IP multicast address of the source to be served. NEF / MBSF 77 or MB-SMF 74 can allocate a new TMGI value suitable for the request, and in operations 704 and 705, the allocated TMGI value can be transmitted to NEF / MBSF 77 or AF 78.

[0178] In operation 706, AF 78 can transmit an MBS service advertisement to the UE, thereby providing allocated TMGI information and MBS service type information regarding whether the MBS service is a multicast or broadcast service. In operation 707, AF 78 can send a request for the MBS service while simultaneously delivering information for the MBS service to NEF / MBSF 77. The information for the MBS service may include information about the MBS service area where the MBS service is provided (e.g., information about all or some areas for a physical map, a list of cell IDs, or a list of TAIs). According to an embodiment, the information for the MBS service may include TMGIs as a group of UEs capable of receiving the service. According to an embodiment, the information for the MBS service may also include characteristics of the traffic generated by the MBS service (e.g., 5QI, resource type (e.g., all or some of GBR, delay-critical GBR, or non-GBR), maximum bit rate, guaranteed bit rate, maximum delay tolerance, maximum packet loss rate, priority level, and maximum data burst size) as QoS information.

[0179] According to an embodiment, the information for the MBS service may also include the type of service, i.e., a multicast service or a broadcast service. According to an embodiment, if a TMGI has not been allocated due to failure to perform operations 701 to 705, the information for the MBS service may also include an instruction to request the allocation of a TMGI.

[0180] In operation 708a, the MBSF 77 can send characteristic information about traffic generated due to MBS service to the PCF 75 and use it for authorization of future services. The NEF / MBSF 77 can select the MB-SMF 74 to serve the MBS session via the NRF. In this case, the MB-SMF 74 can request the NRF to find the appropriate MB-SMF 74 by transmitting the TMGI or MBS session ID and MBS service area information to the NRF.

[0181] In operation 708b, NEF / MBSF 77 can send an MBS session initiation request message to the selected MB-SMF 74. The MBS session initiation request message can include TMGI information and the MBS service type, thereby informing the MB-SMF 74 whether the service assigned to the TMGI is a multicast or broadcast service. Furthermore, when a request for TMGI allocation is received from AF 78, the MBS session initiation request message can enable NEF / MBSF 77 to allocate the TMGI, or it can include an instruction requesting the MB-SMF to allocate the TMGI.

[0182] When a TMGI is requested, the MB-SMF 74, which has already received the message in Operation 708b, can allocate the appropriate TMGI and generate a context for servicing the MBS session. In Operation 709, the MB-SMF 74 can provide the NRF with the MB-SMF's address or ID and the MBS session ID, i.e., the TMGI information, thereby registering / updating the MB-SMF's profile.

[0183] In operation 710, MB-SMF 74 can identify authorization for the MBS service to PCF 75. When it is determined that the MBS service is authorized, the user plane of the MBS service session can be set in operation 711, that is, the tunnel ID and address / port information for MB-UPF 76 to receive MBS traffic can be provided to MB-SMF 74.

[0184] In operations 712 and 713, MB-SMF 74 can transmit information generated for MBS session service to NEF / MBSF 77 or AF 78. For example, in operations 712 and 713, TMGI, address / port information, and tunnel ID for MB-UPF 76 to receive traffic can be transmitted. Upon receiving the message from operation 712, NEF / MBSF 77 can transmit the TMGI, address / port information, and tunnel ID for MB-UPF to receive traffic to MBSU or Multicast-Broadcast Service Traffic Function (MBSTF), thereby setting up a tunnel for transmitting MBS traffic to MB-UPF 76. In operation 713, MBSU or MBSTF can provide MBSF with the tunnel ID and address / port information for receiving MBS traffic, and NEF / MBSF 77 can transmit this information, along with the TMGI information, to AF 78.

[0185] If an MBS session is initiated, in operation 714, AF 78 can transmit information for receiving MBS services to UE 70 via an announcement message (MBS service announcement message). The announcement message may include at least one of the following: TMGI, ID of the MBS service session to be received by the UE, MBS service area information, DNN information, S-NSSAI information, AF ID (or FQDN or IP address), MBSU FQDN (or IP address), or MBS service type.

[0186] refer to Figure 7bIn operation 715, MB-SMF 74 can determine subsequent operations based on the MBS service type received in operation 708b. In operation 715, when the MBS service type is broadcast service, MB-SMF 74 can select an appropriate AMF based on the MBS service area received in operation 708a. In operation 716a, MB-SMF 74 can send a request to the selected AMF to establish a shared tunnel, and AMF 72 can send this request to NG-RAN 71 in the MBS service area. This request may include, for example, TMGI information, MB-SMF ID information, and QoS information. In operation 717, NG-RAN 71, receiving the request, can transmit endpoint information for the shared tunnel used to receive MBS service traffic to MB-SMF 74 via AMF 72, and MB-SMF 74 can thus generate a shared tunnel with MB-UPF 76 between NG-RAN 71 and MB-UPF 76.

[0187] In operation 715, if the MBS service type is a multicast service, a wait is performed until any UE sends a request to join the MBS service. In operation 716b, when UE 70 sends a request to join an MBS session via SMF 73, SMF 73 refers to information for the requested TMGI and requests the NRF to discover the MB-SMF 74 providing the TMGI, and can request the discovered MB-SMF 74 to join or create a shared tunnel according to the join request. In operation 716b, MB-SMF 74 can send a request to SMF 73 to establish a shared tunnel, and SMF 73 can send this request to NG-RAN 71. This request may include, for example, TMGI information, MB-SMF ID information, and QoS information. In operation 717, the NG-RAN 71 receiving the request can transmit endpoint information for the shared tunnel used to receive MBS service traffic to the MB-SMF 74 via the AMF 72, and the MB-SMF 74 can thus generate a shared tunnel with the MB-UPF 76 between the NG-RAN 71 and the MB-UPF 76.

[0188] The methods described in the embodiments of this disclosure or in the claims can be implemented in hardware, software, or a combination of hardware and software.

[0189] When implemented as software, a computer-readable storage medium may be provided to store one or more programs (software modules). The one or more programs stored in the computer-readable storage medium are configured to be executed by one or more processors in an electronic device. The one or more programs include instructions to enable the electronic device to perform methods according to embodiments described in the specification or claims of this disclosure.

[0190] The program (software module or software) may be stored in random access memory, non-volatile memory (including flash memory, ROM, electrically erasable programmable read-only memory (EEPROM), disk storage devices, optical disc ROM, digital versatile optical disc (DVD)), or other types of optical storage devices or magnetic tape. Alternatively, the program may be stored in a memory consisting of all or some of the above. Each constituent memory may include multiple memories.

[0191] The program can be stored in an attachable storage device accessible via a communication network, such as the Internet, intranet, local area network (LAN), wide area network (WLAN), or storage area network (SAN), or a combination thereof. The storage device can be connected to a device executing embodiments of this disclosure via an external port. A separate storage device on the communication network can be connected to a device executing embodiments of this disclosure.

[0192] In the specific embodiments described above, depending on the proposed specific embodiments, the components included in this disclosure are represented in either a singular or plural form. However, the singular or plural form is chosen to suit the context suggested for ease of description, and this disclosure is not limited to singular or plural components. As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise.

[0193] Although specific embodiments of the present disclosure have been described above, various changes can be made thereto without departing from the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the above embodiments, but should be defined by the appended claims and their equivalents.

[0194] Although this disclosure has been described with reference to various embodiments, various changes and modifications will be apparent to those skilled in the art. This disclosure is intended to cover such changes and modifications that fall within the scope of the appended claims.

Claims

1. A method for executing a multicast and broadcast session management function (MB-SMF) in a wireless communication system, the method comprising: The Network Exposure Function / Multicast and Broadcast Service Function (NEF / MBSF) receives a request message from the Application Function (AF) for assigning a Temporary Mobile Group Identity (TMGI). Send a response message including the TMGI to the AF via NEF / MBSF; Receive multicast and broadcast service MBS information from AF via NEF / MBSF, the MBS information including the service type indicating whether the service is a broadcast service or a multicast service; Based on the service type, the service is determined to be the broadcast service; as well as Send a resource establishment request for the MBS session to the Access and Mobility Management Function (AMF).

2. The method according to claim 1, further comprising: The AMF is selected based on the MBS service area.

3. The method according to claim 1, further comprising: Receive endpoint information from the next-generation radio access network (NG-RAN) for the shared tunnel used to receive MBS service traffic through the AMF.

4. The method according to claim 2, wherein, The resource establishment request for the MBS session is forwarded from the AMF to the Next Generation Radio Access Network (NG-RAN).

5. A multicast and broadcast session management function (MB-SMF) in a wireless communication system, the MB-SMF comprising: transceiver; as well as A controller, coupled to the transceiver and configured to control: The Network Exposure Function / Multicast and Broadcast Service Function (NEF / MBSF) receives a request message from the Application Function (AF) for assigning a Temporary Mobile Group Identity (TMGI). A response message including the TMGI is sent to the AF via NEF / MBSF. Multicast and broadcast service MBS information is received from the AF via NEF / MBSF. The MBS information includes a service type indicating whether the service is a broadcast service or a multicast service. Based on the service type, it is determined that the service is the broadcast service. Send a resource establishment request for the MBS session to the Access and Mobility Management Function (AMF).

6. The MB-SMF according to claim 5, wherein, The controller is configured to perform control to: The AMF is selected based on the MBS service area.

7. The MB-SMF according to claim 5, wherein, The controller is configured to perform control to: Receive endpoint information from the next-generation radio access network (NG-RAN) for the shared tunnel used to receive MBS service traffic through the AMF.

8. The MB-SMF according to claim 6, wherein, The resource establishment request for the MBS session is forwarded from the AMF to the Next Generation Radio Access Network (NG-RAN).

9. A method for performing a multicast and broadcast session management function (MB-SMF) in a wireless communication system, the method comprising: The Network Exposure Function / Multicast and Broadcast Service Function (NEF / MBSF) receives a request message from the Application Function (AF) for assigning a Temporary Mobile Group Identity (TMGI). Send a response message including the TMGI to the AF via NEF / MBSF; Receive multicast and broadcast service MBS information from AF via NEF / MBSF, the MBS information including the service type indicating whether the service is a broadcast service or a multicast service; Based on the service type, the service is determined to be the multicast service; as well as When the Session Management Function (SMF) discovers the MB-SMF in response to an MBS session join request from a User Equipment (UE), it receives a first request associated with the MBS session join request from the SMF.

10. The method of claim 9, further comprising: Receive endpoint information from the next-generation radio access network (NG-RAN) for the shared tunnel used to receive MBS service traffic via the Access and Mobility Management Function (AMF).

11. The method according to claim 9, wherein, Also includes: Resources for MBS traffic delivery are established using the multicast and broadcast user plane function MB-UPF and the next-generation radio access network NG-RAN.

12. A multicast and broadcast session management function (MB-SMF) in a wireless communication system, the MB-SMF comprising: transceiver; as well as A controller, coupled to the transceiver and configured to control: The Network Exposure Function / Multicast and Broadcast Service Function (NEF / MBSF) receives a request message from the Application Function (AF) for assigning a Temporary Mobile Group Identity (TMGI). A response message including the TMGI is sent to the AF via NEF / MBSF. Multicast and broadcast service MBS information is received from the AF via NEF / MBSF. The MBS information includes a service type indicating whether the service is a broadcast service or a multicast service. Based on the service type, it is determined that the service is the multicast service, and When the Session Management Function (SMF) discovers the MB-SMF in response to an MBS session join request from a User Equipment (UE), it receives a first request associated with the MBS session join request from the SMF.

13. The MB-SMF according to claim 12, wherein, The controller is configured to perform control to: Receive endpoint information from the next-generation radio access network (NG-RAN) for the shared tunnel used to receive MBS service traffic via the Access and Mobility Management Function (AMF).

14. The MB-SMF according to claim 12, wherein, The controller is configured to perform control to: Resources for MBS traffic delivery are established using the multicast and broadcast user plane function MB-UPF and the next-generation radio access network NG-RAN.