WO2022152625A1 - Découverte de service de smf de 5mbs pour mb-smf - Google Patents
Découverte de service de smf de 5mbs pour mb-smf Download PDFInfo
- Publication number
- WO2022152625A1 WO2022152625A1 PCT/EP2022/050251 EP2022050251W WO2022152625A1 WO 2022152625 A1 WO2022152625 A1 WO 2022152625A1 EP 2022050251 W EP2022050251 W EP 2022050251W WO 2022152625 A1 WO2022152625 A1 WO 2022152625A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- smf
- session
- multicast
- request
- sending
- Prior art date
Links
- 238000000034 method Methods 0.000 claims abstract description 135
- 230000004044 response Effects 0.000 claims abstract description 53
- 230000010267 cellular communication Effects 0.000 claims abstract description 23
- 230000006870 function Effects 0.000 description 85
- 230000004048 modification Effects 0.000 description 44
- 238000012986 modification Methods 0.000 description 44
- 238000007726 management method Methods 0.000 description 22
- 238000004891 communication Methods 0.000 description 20
- 238000012545 processing Methods 0.000 description 17
- 230000005540 biological transmission Effects 0.000 description 14
- 238000012546 transfer Methods 0.000 description 13
- 238000013475 authorization Methods 0.000 description 12
- 238000010586 diagram Methods 0.000 description 10
- 101150102131 smf-1 gene Proteins 0.000 description 10
- 239000013256 coordination polymer Substances 0.000 description 9
- 230000011664 signaling Effects 0.000 description 8
- 238000001514 detection method Methods 0.000 description 6
- 230000003993 interaction Effects 0.000 description 5
- 238000004590 computer program Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- 101150119040 Nsmf gene Proteins 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 238000012384 transportation and delivery Methods 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000013523 data management Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 229940102240 option 2 Drugs 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 101100240462 Homo sapiens RASAL2 gene Proteins 0.000 description 1
- 241001071864 Lethrinus laticaudis Species 0.000 description 1
- 102100035410 Ras GTPase-activating protein nGAP Human genes 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
Definitions
- the present disclosure relates to Multicast/Broadcast service in a wireless communication system.
- MBMS Multicast/Broadcast Multimedia Subsystem
- 3GPP TS 23.246 v16.1 .0 Third Generation Partnership Project
- 4G Fourth Generation
- eMBMS evolved MBMS
- EPS Evolved Packet System
- Release 13 and Release 14 the MBMS system was updated to support new services such as Public Safety, Cellular Internet of Things (CloT), and Vehicle to Anything (V2X).
- Multicast / Broadcast services are so far not supported in 5G NR.
- Mission Critical Services e.g., Mission Critical Push To Talk (MCPTT), Mission Critical Data (MCData), and Mission Critical Video (MCVideo), as well as VTX services, will show an enhanced and much better performance on 5G NR.
- MCPTT Mission Critical Push To Talk
- MCData Mission Critical Data
- MCVideo Mission Critical Video
- Session start (or configuration) triggered by the Application Function (AF) or 5G Core (5GC) entities. It may also include Temporary Mobile Group Identity (TMGI) allocation procedure.
- AF Application Function
- 5GC 5G Core
- TMGI Temporary Mobile Group Identity
- the session is managed by Multicast/Broadcast Session Management Function (MB-SMF).
- MB-SMF Multicast/Broadcast Session Management Function
- Session join from a User Equipment UE
- the handling entity Access and Mobility Management Function (AMF) or Session Management Function (SMF)
- AMF Access and Mobility Management Function
- SMF Session Management Function
- the Session Join procedure is used by UEs to inform the 3 GPP network of the UE interest in an MB Session.
- the Session Join procedure the distribution area of the multicast session is adjusted if needed.
- the Session Join procedure together with other procedures, e.g. Session Leave procedure and Handover procedure, enables the dynamic and efficient use of radio resources.
- the UE registers and a PDU Session is established.
- the UE and the AF uses the PDU Session e.g. to signal and establish a group on application level (see TS 23.468 [5]).
- a PDU session is used for application level signalling in steps 0 and 5, it is managed independently from the MB Session. That is, the PDU Session does for example not need to be maintained while the UE is receiving multicast content.
- AF sends Allocate TMGI Request () message to NEF/MBSF to request allocation of a TMGI to identify a new group.
- TMGIs may be pre-allocated in the AF and the 5GC.
- the preallocated TMGI shall be included in the Allocate TMGI Request (TMGI) message.
- the AF may include a new indication DisablelndividualDelivery to indicate if 5 GC Individual MBS traffic delivery should not be applied for a specific MB Session e.g. due to application characteristics.
- NEF/MBSF selects based on local configuration an MB-SMF (if there are multiple) to handle the group and sends an Allocate TMGI Request 0 message to the MB-SMF.
- the MBSF makes the TMGI allocation, stores in the MB Session Context and includes the allocated TMGI in the message to the MB-SMF.
- the MBSF may have a pre-configured TMGI range for each MB-SMF. The TMGI range should also be configured/registered in the NRF to allow AMFs to discover which MB-SMF is controlling an MB Session identified by a TMGI.
- TMGIs may be pre-allocated in the AF and the 5GC e.g. based on SLA.
- the pre-allocated TMGI shall be included in the Allocate TMGI Request (TMGI) message.
- TMGI Allocate TMGI Request
- the MB SMF or optionally the MBSF shall after local checks (e.g. that it is allowed for p re-allocation and has not already been used) use the provided TMGI if present, and proceed as normal (i.e. store it in the MB Session Context, etc.).
- NEF/MBSF pass the indication DisablelndividualDelivery (if received) to the MB-SMF.
- MB-SMF allocates a TMGI (optionally pre-allocated TMGI may be used, see step 2), a Lower Layer Multicast IP Address (LL MC address) for N3, and N6 tunnel information and stores the information in a new MB Session Context set to 'inactive' state.
- MB-SMF returns the TMGI and the N6 tunnel information to the NEF/MBSF. If MB-SMF makes the TMGI allocation, it may e.g. allocate a TMGI from a pre -configured TMGI range.
- the NEF/MBSF might use multiple MB-SMFs (and MB-UPFs).
- N3 LL MC address is used for 5GS internal transport, it is considered sufficient to allocate the N3 LL MC address at Session Start i.e. when resources for the MB Session is allocated in different nodes. A one-to-one relationship between N3 LL MC Address and MB Session is used.
- the NEF/MBSF establishes a new MB Session Context set to 'inactive' state, stores received information and responds to the AF by sending a Allocate TMGI Response (TMGI) message.
- TMGI Allocate TMGI Response
- MB Session Announcement (see e.g., TS 23.468 [5]).
- the AF informs the members in the group of various group info e.g. TMGI, HL MC Address.
- the HL MC address may be allocated by the AF for the group/TMGI.
- UE indicates its interest to join an MB Session by sending an UL NAS MB Session Join Request (TMGI) message.
- TMGI NAS MB Session Join Request
- NG-RAN forwards the NAS message to the AMF.
- the AMF stores the TMGI in its UE Context.
- the UE always joins the MB Session as such.
- the UE may choose to process and present all or a selected set of media streams.
- the AMF selects an MB SMF for the TMGI by querying the NRF.
- a MB Session Request (TMGI, AMF ID) message is sent to the MB SMF to announce the AMF's interest in the MB Session.
- the MB-SMF has returned a MB Session Response () message
- the AMF creates a MB Session Context in 'inactive' state for the TMGI.
- the AMF may decide to apply 5GC Individual MBS traffic delivery when the MBS Session is started later.
- the AMF can know if NG-RAN supports 5MB S based on the configuration.
- the AMF determines that 5GC Individual MBS traffic delivery should not be applied to the MBS session, and NG-RAN does not support 5MB S, the AMF will reject the UE Session Join request. In this case, N2 MB Session Join message in step 8 will be skipped.
- the AMF stores the TMGI and the NG RAN ID of the originating node of the N2 message in step 6 in the AMF MB Session Context.
- the AMF creates a DL NAS MB Session Join Response () message and piggy backs that on an N2 MB Session Join (NGAP ID, TMGI) message.
- the NG-RAN stores the TMGI in the UE context in NG-RAN.
- the Multicast context and Multicast flow setup/modification uses an enhanced PDU session modification procedure for unicast traffic defined in TS 23.502 [8],
- the content provider may send a request to register and reserve resources for a multicast group to the NEF and communicate the related multicast address as detailed in clause 6.3.2.2.2.
- the content provider may invoke the services provided by the NEF to provision the multicast information.
- the multicast information is used to identify (e.g., IP Address of multicast data) and reserve resources for the multicast.
- the NEF selects MB-SMF controlling an MB-UPF serving as ingress point for the multicast data and creates a multicast context and stores related information including the SMF ID in the UDR.
- the MB- SMF may request the MB-UPF to allocate an IP address and Port for ingress multicast traffic, which is then provided to the content provider via NEF.
- the UE registers in the PLMN (see clause 4.2.2.2 of TS 23.502 [8]) and request the establishment of a PDU session (see clause 4.3.2.2 of TS 23.502 [8]).
- the UE also indicates its capability to receive multicast data over the radio.
- the AMF obtains information from the UDM whether the UE can join multicast sessions as part of the SMF Selection Subscription data. If so, for direct discovery, the AMF selects an SMF capable of handling multicast sessions based on locally configured data or a corresponding SMF capability stored in the NRF and also indicates the UE's capability to receive multicast data over the radio to the SMF.
- the content provider announces the availability of multicast using higher layers (e.g., application layer).
- the announcement includes at least the multicast address of a multicast group that UE can join.
- the UE joins the multicast group. 4b.
- the reception of the join message triggers the UPF to notify the SMF.
- the UPF can be optimized to send the notification only when the UE's status with regard to the multicast group the UE has joined changes, i.e., when the UE joins or leaves a group.
- the SMF initiates PDU session modification procedure upon the reception of the notification from the UPF.
- the UE sends the PDU Session Establishment/Modification Request either upon a request from higher layers or upon a detection by lower layers of UE joining a multicast group (i.e., detection of IGMP or MLR and detection of the change of content of these messages).
- the PDU Session Modification Request shall include information about multicast group, which UE wants to join, such as multicast addresses listed in the IGMP and MLR messages. This information is needed for configuration of the UPF with appropriate packet filters.
- the AMF invokes Nsmf PDUSession UpdateSMContext (SM Context ID, N1 SM container (PDU Session Modification Request with the multicast information)).
- Nsmf PDUSession UpdateSMContext SM Context ID, N1 SM container (PDU Session Modification Request with the multicast information)
- the SMF may interact with the PCF to check whether the UE is authorized to join the multicast session as described in Figure 6.3.2.2.5-1.
- SMF checks at the UDR whether a multicast context for the multicast group (address) exists in the system. If the multicast context for the multicast group does not exist, then SMF creates it when the first UE joins the multicast group, stores the multicast context including itself as multicast controlling SMF in the UDR, and configures the UPF to handle the multicast data distribution (SMF and MB-SMF, and UPF and MB-UPF in this flow are then identical).
- a multicast context for the multicast group address
- the MB-UPF may also have to join the multicast tree towards the content provider; the MB-SMF should request the MB-UPF to join the multicast tree when configuring the MB-UPF, see e.g. Step 15 and 26. If a multicast context already exists in the UDR, the SMF retrieves the related information, including information related to MB-SMF controlling the multicast ingress point.
- SMF If SMF has no information about the multicast context for the indicated multicast group, SMF interacts with MB SMF to retrieve QoS information of the multicast QoS flow(s).
- steps 10 to 23 apply
- SMF requests the AMF to transfer a message to the RAN node using the Namf_NlN2MessageTransfer service (N2 SM information (PDU Session ID, Multicast Context ID, MB-SMF ID, multicast QoS flow information), N1 SM container (PDU Session Modification Command (PDU Session ID, multicast information (Multicast Context ID, multicast QoS flow information, multicast address)) to the RAN node using the Namf_NlN2MessageTransfer service (N2 SM information (PDU Session ID, Multicast Context ID, MB-SMF ID, multicast QoS flow information), N1 SM container (PDU Session Modification Command (PDU Session ID, multicast information (Multicast Context ID, multicast QoS flow information, multicast address)) to
- the SMF maps the received QoS information of the multicast QoS flow into unicast QoS flow information of the PDU Session, and includes the information of the unicast QoS flows and the information about the association between those unicast QoS flows and the multicast QoS flows in the N2 SM information. If dedicated unicast QoS flows are required, the information includes the one about those dedicated unicast QoS flows. SMF also includes information about those unicast QoS flows in the N1 SM container.
- the N2 session modification request is sent to the RAN.
- the request is sent in the UE context using the PDU Session Resource Modify Request message enhanced with multicast related information, which includes a multicast group identity (e.g., multicast address), Multicast Session context ID, and multicast flow information such as multicast QoS Flow ID and associating QoS information.
- the RAN uses the multicast group identity to determine that the session modification procedures corresponds to one multicast group. In other words, the RAN learns what UEs are receiving the same multicast data from the multicast group identity.
- the RAN configures resources to serve this multicast group.
- the N1 SM container (PDU Session Modification Command) is provided to the UE.
- the RAN performs the necessary access network resource modification such as configuration of PTP or PTM bearers.
- RAN node checks whether the user plane for the multicast group/context distribution is already established towards the RAN node. If RAN supports MBS, RAN configures the UE for receiving the multicast data via multicast session.
- steps 14 to 18 are executed.
- RAN nodes selects the AMF to reach MB-SMF and signals a request towards AMF [MB-SMF ID, Multicast context/group ID], If the RAN node is configured to use a unicast transport for multicast distribution sessions, it allocates a downlink tunnel ID (an IP address and a GTP-U TEID) for the reception of the multicast distribution session and indicates the downlink tunnel information in the request.
- AMF ID an IP address and a GTP-U TEID
- AMF forwards the request towards the MB-SMF
- MB-SMF configures MB-UPF to transmit the multicast distribution session towards RAN (using the received IP address and a GTP-U TEID).
- MB-SMF sends a multicast distribution session response to AMF. For multicast transport of the multicast distribution, it indicates in the downlink tunnel information the transport multicast address for the multicast session.
- AMF forwards multicast distribution session response to RAN node.
- the RAN sends the session modification response, which does not include the unicast tunnel information.
- the AMF transfers the session modification response received in step 18 to the SMF.
- the SMF determines that the shared tunnel is used for multicast packet transferring and the interaction with UPF is not needed.
- MB-UPF receives multicast PDUs.
- MB-UPF sends multicast PDUs in the N3/N9 tunnel associated to the multicast distribution session to the RAN. There is only one tunnel per multicast distribution session and RAN node, i.e., all associated PDU sessions share this tunnel.
- the RAN selects PTM or PTP radio bearers to deliver the multicast PDUs to UEs that joined the multicast group.
- the RAN performs the transmission using the selected bearer.
- steps 25 to 38 apply
- steps 25 to 28 are executed.
- SMF request UPF to allocate a downlink tunnel endpoint (an IP address and a GTP-U TEID).
- SMF signals a request for the multicast session distribution towards MB-SMF [Multicast context/group ID, downlink tunnel info].
- MB-SMF configures MB-UPF to transmit the multicast distribution session towards UPF (using the received IP address and GTP-U TEID).
- MB-SMF sends a multicast distribution session response to SMF.
- SMF For multicast transport of the multicast distribution, it also indicates in the downlink tunnel information the transport multicast address for the multicast session.
- steps 25 to 28 can also be triggered after the step 34, i.e. when the SMF determines that RAN does not support MBS.
- SMF configures UPF to receive the multicast distribution session and forward the data within unicast transport. If SMF1 decides to establish dedicated QoS flow for the unicast transfer of the multicast data, steps 30 to 34 apply.
- the SMF1 derives the QoS Rules for the unicast transfer of multicast data based on QoS parameters for multicast transmission received in step 25.
- SMF1 maps the multicast QFI to a unicast QFI of the PDU Session; other QoS parameters of unicast QoS Rules are same as the one for multicast transmission.
- the SMF1 requests the AMF to transfer a message to the RAN node using the Namf_NlN2MessageTransfer service (N1 SM container (PDU Session Modification Command (PDU Session ID, unicast QoS rule(s)).
- N1 SM container PDU Session Modification Command (PDU Session ID, unicast QoS rule(s)).
- the N2 session modification request is sent to the RAN.
- the N1 SM container (PDU Session Modification Command) is provided to the UE.
- the RAN sends the session modification response.
- the AMF transfers the session modification response received in step 30 to the SMF1 via the Nsmf PDUSession UpdateSMContext service.
- MB-UPF receives multicast PDUs.
- MB-UPF sends multicast PDUs in the N3/N9 tunnel associated to the multicast distribution session to UPF. There is only one tunnel per multicast distribution session and destination UPF, i.e., all associated PDU sessions share this tunnel.
- UPF forwards the multicast data via unicast.
- the RAN forwards the multicast data via unicast.
- the MSF can manage an MBS service, and apply related NEF procedures to configure a multicast group.
- AF of content provider may register at NEF that it provides contents for a multicast group (identified by multicast group ID which may be IP multicast address).
- Multicast information may further include media type information (e.g., audio, video ... ), QoS requirements, UE authorization information (e.g. a GPSI or an External Group Id or a UE ID to identify UEs authorized to join the multicast service), service area identifying the service scope, and start and end time of MBS.
- the AF may also request the allocation of an ingress transport address where to send tunnelled multicast data.
- NEF checks authorization of content provider. NEF selects MB-SMF as ingress control node, possibly based on location area.
- NEF requests storage of multicast session context at UDR and provides multicast group ID and selected MB-SMF ID. 5. NEF requests MB-SMF to reserve ingress resources for a multicast distribution session and provides Multicast group ID. It also indicates if the allocation of an ingress transport address is requested.
- the MB-SMF sends SM MBS Policy Association Request to MB-PCF with the Multicast group ID, AF Identifier, and the QoS requirements.
- the MB-PCF registers at the BSF that it handles the multicast session. It provides an identifier that the policy association is for multicast and the multicast group ID, it own PCF ID and optionally its PCF set ID.
- the MB-PCF may query the UDR for policy input related to the multicast session.
- the MB-PCF responds with SM MBS Policy Association Response with policies for the Multicast group ID.
- the PCF derives the required QoS parameters based on the information provided by the NEF and determines whether this QoS is allowed (according to the PCF configuration for this AF), and notifies the result to the MB-SMF.
- the PCF notifies the MB-SMF whether the transmission resources corresponding to the QoS request are established or not.
- MB-SMF responds to the NEF in step 12 with a Result value indicating the failure cause, and NEF further notifies AF in step 13.
- MB-SMF selects the MB-UPF and requests it to reserve user plane ingress resources. If multicast transport of the multicast data towards RAN nodes is to be used, the MB-SMF also request the MB-UPF to reserve for the outgoing data a tunnel endpoint and the related identifiers (source IP address, source specific multicast address and GTP Tunnel ID) and to forward data received at the user plane ingress resource using that tunnel endpoint.
- MB-UPF selects an ingress address (IP address and port) and a tunnel endpoint for the outgoing data and provides it to MB-SMF
- MB-SMF indicates the possibly allocated ingress address to the NEF. It also indicates the success or failure of reserving transmission resources.
- the NEF indicates the possibly allocated ingress address to the AF.
- the problem is that the UDR is intended for a database role and thus does not have interface towards the SMF.
- the UDR As defined in 3GPP Technical Specification (TS) 23.501 , the UDR is supposed to store subscription data, policy data, and structured data for exposure and application data.
- the MB-SMF ID is the identity of the MB Session management entity, which does not belong to any of the data that is supposed to be stored by the UDR as defined in 3GPP TS 23.501 . Thus, the MB-SMF ID is not supposed to be stored in the UDR. Summary
- a method performed in a core network of a cellular communications system comprises, at a MB-SMF, receiving a request from a network exposure function (NEF) for a multicast session, allocating a MB session ID for the multicast session, and sending a response to the NEF comprising the MB session ID for the multicast session.
- the method further comprises, at the MB-SMF, sending a message to a network repository function (NRF), the message comprising the information that associates the MB session ID to the MB-SMF.
- NRF network repository function
- the method further comprises, at the NRF, receiving the message from the MB-SMF and storing the MB session ID in association with information that identifies the MB-SMF. In one embodiment, the method further comprises, at the NRF, receiving, from a SMF, a discovery request comprising the MB session ID and sending, to the SMF, a discovery response comprising the information that identifies the MB-SMF.
- the method further comprises at the MB-SMF, sending a message to a Binding Session Function (BSF), the message comprising the information that associates the MB session ID to the MB-SMF.
- BSF Binding Session Function
- the method further comprises, at the BSF, receiving the message from the MB-SMF and storing the MB session ID in association with information that identifies the MB-SMF.
- the method further comprises, at the BSF, receiving, from a SMF, a discovery request comprising the MB session ID and sending, to the SMF, a discovery response comprising the information that identifies the MB-SMF.
- the method further comprises, at the MB-SMF, sending a policy association request to a multicast/broadcast policy control function (MB-PCF), the policy association request comprising the MB session ID, and receiving a policy association response from the MB-PCF.
- the method further comprises, at the MB-PCF, receiving the policy association request from the MB-SMF, sending a register request to the BSF comprising the MB session ID, and sending the policy association response to the MB-SMF.
- MB-PCF multicast/broadcast policy control function
- the MB-SMF is one of two or more MB-SMFs in a MB-SMF pool, and the method further comprises synchronization information about the multicast session across the two or more MB-SMFs in the MB-SMF pool.
- the MB-SMF is one of two or more MB-SMFs in a MB-SMF pool
- the method further comprises synchronization information about the multicast session across the two or more MB-SMFs in the MB-SMF pool during session creation and also when a MB session context of the MB session is linked with a SMF.
- the method further comprises, at a second MB-SMF in the same MB-SMF pool as the MB-SMF, receiving, from a SMF, a MB session context query comprising the MB session ID, sending a query to the MB-SMF, receiving a response to the query comprising a MB session context for the multicast session, and sending the MB session context to the SMF.
- the method further comprises, at a second MB-SMF, receiving, from a SMF, a MB session context query comprising the MB session ID, sending a query to the MB-SMF, receiving a response to the query from the MB-SMF, and sending, to the SMF, a rejection of the MB session context query and a request to redirect to the MB-SMF.
- the method further comprises, at a second MB-SMF, receiving, from a SMF, a MB session context query comprising the MB session ID, sending a query to the MB-SMF, receiving a response to the query from the MB-SMF, and forwarding the MB session context query to the MB-SMF.
- the method further comprises, at a second MB-SMF, receiving, from a SMF, a MB session context query comprising the MB session ID and sending, to the SMF, a rejection of the MB session context query and a request to redirect to the MB-SMF.
- the method further comprises, at a second MB-SMF, receiving, from a SMF, a MB session context query comprising the MB session ID and forwarding the MB session context query to the MB-SMF.
- a method performed by a MB-SMF in a core network of a cellular communications system comprises receiving a request from a NEF for a multicast session, allocating a MB session ID for the multicast session, and sending a response to the NEF comprising the MB session ID for the multicast session.
- the method further comprises sending a message to an NRF, the message comprising the information that associates the MB session ID to the MB-SMF.
- the method further comprises sending a message to a BSF, the message comprising the information that associates the MB session ID to the MB-SMF.
- a method performed by network function in a core network of a cellular communications system comprises receiving a message from a MB-SMF, the message comprising MB session ID of multicast session, and storing the MB session ID in association with information that identifies the MB-SMF.
- the network function is an NRF.
- the network function is a BSF.
- the method further comprises receiving, from a SMF, a discovery request comprising the MB session ID and sending, to the SMF, a discovery response comprising the information that identifies the MB-SMF.
- a method performed in a core network of a cellular communications system comprises, at a MB-SMF, receiving a request from a NEF for a multicast session, the request comprising a multicast group ID, and sending a response to the NEF comprising a MB session ID for the multicast session, wherein the multicast group ID is used as the MB session ID.
- a method performed by a SMF in a core network of a cellular communications system comprises during a multicast session join procedure that is performed to join a particular user equipment (UE) to a particular multicast session, obtaining information that identifies a MB-SMF associated to the particular multicast session from either a NRF, BSF, or NEF, and using the information that identifies the MB-SMF for the multicast session join procedure.
- UE user equipment
- a network node that implements any of a MB-SMF, NRF, BSF, etc. are also disclosed herein.
- Figure 1 is a reproduction of Figure 6.2.2.1 -1 from Third Generation Partnership Project (3GPP) Technical Report (TR) 23.757 V1.2.0;
- 3GPP Third Generation Partnership Project
- TR Technical Report
- Figures 2A through 2C are a reproduction of Figure 6.3.2.1 -1 from 3GPP TR 23.757 V1 .2.0;
- Figure 3 is a reproduction of Figure 6.3.2.2.2-1 from 3GPP TR 23.757 V1 .2.0;
- Figure 4 illustrates one example of a cellular communications system in which embodiments of the present disclosure may be implemented
- Figures 5 and 6 illustrate example embodiments in which the cellular communication system of Figure 4 is a Fifth Generation (5G) System (5GS);
- 5G Fifth Generation
- 5GS Fifth Generation
- FIG. 7 illustrates a Multicast/Broadcast (MB) session create procedure in a 5GS in accordance with one embodiment of the present disclosure
- FIGS 8A through 8C illustrate an MBS session join procedure in the 5GS in accordance with one embodiment of the present disclosure
- Figure 9 illustrates one example of a procedure for synchronizing MB-SMF instances in a MB-SMF pool in accordance with one embodiment of the present disclosure
- Figure 10 illustrates one example of a procedure for arriving at the correct MB-SMF based on MB-SMF awareness of other MB-SMF(s) in the same MB-SMF pool in accordance with one embodiment of the present disclosure
- Figure 11 illustrates one example of a procedure that enables an SMF to obtain the MB-SMF ID of the correct MB-SMF (e.g., during a join session procedure) from a Network Exposure Function (NEF) in accordance with one embodiment of the present disclosure;
- NEF Network Exposure Function
- Figure 12 is a schematic block diagram of a network node according to some embodiments of the present disclosure.
- Figure 13 is a schematic block diagram that illustrates a virtualized embodiment of the network node of Figure 12 according to some embodiments of the present disclosure
- Figure 14 is a schematic block diagram of the network node of Figure 12 according to some other embodiments of the present disclosure.
- FIG. 15 is a schematic block diagram of a User Equipment device (UE) according to some embodiments of the present disclosure.
- Figure 16 is a schematic block diagram of the UE of Figure 15 according to some other embodiments of the present disclosure.
- Radio Node As used herein, a “radio node” is either a radio access node or a wireless communication device.
- Radio Access Node As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals.
- RAN Radio Access Network
- a radio access node examples include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.
- a base station e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B
- a “core network node” is any type of node in a core network or any node that implements a core network function.
- Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like.
- MME Mobility Management Entity
- P-GW Packet Data Network Gateway
- SCEF Service Capability Exposure Function
- HSS Home Subscriber Server
- a core network node examples include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.
- AMF Access and Mobility Function
- UPF User Plane Function
- SMF Session Management Function
- AUSF Authentication Server Function
- NSSF Network Slice Selection Function
- NEF Network Exposure Function
- NRF Network Exposure Function
- NRF Network Exposure Function
- PCF Policy Control Function
- UDM Unified Data Management
- a “communication device” is any type of device that has access to an access network.
- Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC).
- the communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.
- One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network).
- a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device.
- UE User Equipment
- MTC Machine Type Communication
- LoT Internet of Things
- Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC.
- the wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.
- Network Node As used herein, a “network node” is any node that is either part of the RAN or the core network of a cellular communications network/system.
- NF instance e.g., MB-SMF instance
- MBS Multicast Broadcast Service
- MB Multicast Broadcast
- Embodiments of systems and methods are disclosed herein that address the aforementioned problem associated with the existing SMF-centric solution for finding the proper MB-SMF for an MBS session joined by a UE.
- the MB-SMF when performing session start (session configuration), allocates a MB Session ID (e.g., TMGI) as a unified session identifier inside of the 5GS.
- a MB Session ID e.g., TMGI
- the MB Session ID range is configured or registered by the MB-SMF towards the NRF.
- the SMF queries the NRF to get the MB-SMF ID of the proper MB-SMF.
- MB-SMFs and the associated MB Session ID ranges are configured in SMFs.
- MB-SMF pools and the associated MB Session ID ranges are configured in SMFs.
- MB-SMFs and the associated MB Session ID ranges are registered towards NRF.
- SMF performs the NF Discovery Request towards NRF to get the right MB-SMF.
- MB-SMF pools and the associated MB Session ID ranges are registered towards NRF.
- SMF performs the NF Discovery Request towards NRF to get the MB-SMF pool and then selects one MB-SMF instance.
- MB-SMF register a MB Session ID towards NRF when the MB Session ID is allocated. SMF performs the NF Discovery Request towards NRF to get the correct MB-SMF.
- MB-SMF register a MB Session ID towards NRF when the MB Session ID is allocated. SMF performs the NF Discovery Request towards NRF to get the MB-SMF pool and then selects one MB-SMF instance.
- the SMF may get the MB-SMF ID via the NEF, the UDM, the BSF, or the NRF.
- the embodiments described herein relate to how the SMF gets the MB-SMF ID, possibly via the NRF, the BSF, the NEF, or the UDM.
- the embodiments described herein can also be used to enable the AMF to get MB-SMF ID, e.g., in the case of an AMF-centric solution, via the NRF, the NEF, the BSF, or the UDM.
- Embodiments of the solutions described herein may enable the SMF to get the proper MB-SMF instance based on an NRF query, instead of using UDR as a shared storage.
- Embodiments of the solutions described herein may ensure the MB Session ID, which is allocated by the MB-SMF, is a manageable, unique session identifier to be used in the 5GS.
- Embodiments of the solutions described herein may enable multiple MB-SMFs to be deployed in the network. Without multiple MB-SMF deployment possibility, the MB-SMF will be the bottleneck of the 5G MBS (5MBS), and the capacity will be limited. Based on embodiments of the proposed solutions, the SMF (or AMF) is able to use the proper MB-SMF when a UE is going to join the MBS session. In addition, the MB-SMF pool concept provides scalability of the MB-SMF in 5GC.
- Embodiments of the solutions described herein may also let the SMF get the MB-SMF ID via the BSF, the NEF, or UDM, if MB Session ID is not allocated by the MB-SMF.
- Embodiments of the solutions described herein may also apply to how the AMF gets the MB-SMF ID via the NEF, the BSF, or the UDM.
- FIG. 4 illustrates one example of a cellular communications system 400 in which embodiments of the present disclosure may be implemented.
- the cellular communications system 400 is a 5G System (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC).
- the RAN includes base stations 402-1 and 402-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (i.e. , LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 404-1 and 404-2.
- the base stations 402-1 and 402-2 are generally referred to herein collectively as base stations 402 and individually as base station 402.
- the (macro) cells 404-1 and 404-2 are generally referred to herein collectively as (macro) cells 404 and individually as (macro) cell 404.
- the RAN may also include a number of low power nodes 406-1 through 406-4 controlling corresponding small cells 408-1 through 408-4.
- the low power nodes 406-1 through 406-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like.
- RRHs Remote Radio Heads
- one or more of the small cells 408-1 through 408-4 may alternatively be provided by the base stations 402.
- the low power nodes 406-1 through 406-4 are generally referred to herein collectively as low power nodes 406 and individually as low power node 406.
- the small cells 408-1 through 408-4 are generally referred to herein collectively as small cells 408 and individually as small cell 408.
- the cellular communications system 400 also includes a core network 410, which in the 5GS is referred to as the 5G Core (5GC).
- the base stations 402 (and optionally the low power nodes 406) are connected to the core network 410.
- the base stations 402 and the low power nodes 406 provide service to wireless communication devices 412-1 through 412-5 in the corresponding cells 404 and 408.
- the wireless communication devices 412-1 through 412-5 are generally referred to herein collectively as wireless communication devices 412 and individually as wireless communication device 412.
- the wireless communication devices 412 are oftentimes UEs, but the present disclosure is not limited thereto.
- Figure 5 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface.
- Figure 5 can be viewed as one particular implementation of the system 400 of Figure 4.
- NFs Network Functions
- the 5G network architecture shown in Figure 5 comprises a plurality of UEs 412 connected to either a RAN 402 or an Access Network (AN) as well as an AMF 500.
- the R(AN) 402 comprises base stations, e.g. such as eNBs or gNBs or similar.
- the 5GC NFs shown in Figure 5 include a NSSF 502, an AUSF 504, a UDM 506, the AMF 500, a SMF 508, a PCF 510, and an Application Function (AF) 512.
- the N1 reference point is defined to carry signaling between the UE 412 and AMF 500.
- the reference points for connecting between the AN 402 and AMF 500 and between the AN 402 and UPF 514 are defined as N2 and N3, respectively.
- N4 is used by the SMF 508 and UPF 514 so that the UPF 514 can be set using the control signal generated by the SMF 508, and the UPF 514 can report its state to the SMF 508.
- N9 is the reference point for the connection between different UPFs 514, and N14 is the reference point connecting between different AMFs 500, respectively.
- N15 and N7 are defined since the PCF 510 applies policy to the AMF 500 and SMF 508, respectively.
- N12 is required for the AMF 500 to perform authentication of the UE 412.
- N8 and N10 are defined because the subscription data of the UE 412 is required for the AMF 500 and SMF 508.
- the 5GC network aims at separating UP and CP.
- the UP carries user traffic while the CP carries signaling in the network.
- the UPF 514 is in the UP and all other NFs, i.e., the AMF 500, SMF 508, PCF 510, AF 512, NSSF 502, AUSF 504, and UDM 506, are in the CP.
- Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.
- RTT Round Trip Time
- the core 5G network architecture is composed of modularized functions.
- the AMF 500 and SMF 508 are independent functions in the CP. Separated AMF 500 and SMF 508 allow independent evolution and scaling.
- Other CP functions like the PCF 510 and AUSF 504 can be separated as shown in Figure 5.
- Modularized function design enables the 5GC network to support various services flexibly.
- Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF.
- a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity.
- the UP supports interactions such as forwarding operations between different UPFs.
- Figure 6 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 5.
- the NFs described above with reference to Figure 5 correspond to the NFs shown in Figure 6.
- the service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface.
- the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 500 and Nsmf for the service based interface of the SMF 508, etc.
- NEF 600, the NRF 602, and the Binding Support Function (BSF) 604 in Figure 6 are not shown in Figure 5 discussed above. However, it should be clarified that all NFs depicted in Figure 5 can interact with the NEF 600, the NRF 602, and the BSF 604 of Figure 6 as necessary, though not explicitly indicated in Figure 5.
- BSF Binding Support Function
- the AMF 500 provides UE-based authentication, authorization, mobility management, etc.
- a UE 412 even using multiple access technologies is basically connected to a single AMF 500 because the AMF 500 is independent of the access technologies.
- the SMF 508 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 514 for data transfer. If a UE 412 has multiple sessions, different SMFs 508 may be allocated to each session to manage them individually and possibly provide different functionalities per session.
- the AF 512 provides information on the packet flow to the PCF 510 responsible for policy control in order to support QoS.
- the PCF 510 determines policies about mobility and session management to make the AMF 500 and SMF 508 operate properly.
- the AUSF 504 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 506 stores subscription data of the UE 412.
- the Data Network (DN) not part of the 5GC network, provides Internet access or operator services and similar.
- An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.
- Figure 7 illustrates a MB Session Creation (Session Configuration) procedure in 5MBS in accordance with one embodiment of the present disclosure.
- the MB Session ID is the generic concept of the session identifier of MB Session. Typically, it can be TMGI in implementation; however, it is not limited thereto.
- the steps of MB session creation procedure of Figure 7 are described below.
- An AF 512 of a content provider may register at the NEF 600 that it provides contents for a multicast group (identified by multicast group ID which may be an Internet Protocol (IP) multicast address, but it not limited thereto).
- Multicast information provided from the AF 512 to the NEF 600 may further include, e.g., media type information (e.g., audio, video%), Quality of Service (QoS) requirements, UE authorization information (e.g., a GPSI or an External Group Id or a UE ID to identify UEs authorized to join the multicast service), service area identifying the service scope, and/or start and end time of MBS.
- the AF 512 may also request the allocation of an ingress transport address where to send tunneled multicast data.
- Step 2 The NEF 600 checks authorization of the content provider.
- the NEF 600 also selects a MB-SMF 508-MB as an ingress control node, possibly based on location area.
- a MB-SMF 508-MB is added to the reference number of a NF to differentiate a MB NF from other NFs of the same basic type (e.g., reference number 508-MB is used for a MB-SMF as compared to the reference number 508 used for a SMF).
- Step 5 The NEF 600 requests the MB-SMF 508-MB to reserve ingress resources for a multicast distribution session and provides the Multicast group ID. It also indicates if the allocation of an ingress transport address is requested.
- Step 5a The MB-SMF 508-MB allocates a MB Session ID (e.g., a TMGI) for the MB Session.
- a MB Session ID e.g., a TMGI
- Step 6 The MB-SMF 508-MB sends a Session Management (SM) MBS Policy Association Request to a MB-PCF 510-MB with information including, e.g., the MB Session ID, Multicast group ID, AF Identifier, and the QoS requirements.
- Step 7 The MB-PCF 510-MB registers at the BSF 604 that it handles the multicast session. It provides an identifier that the policy association is for multicast and the MB Session ID, its own PCF ID, and optionally its PCF set ID.
- SM Session Management
- Step 9 The MB-PCF 510-MB responds with a SM MBS Policy Association Response with policies for the Multicast group ID.
- the MB-PCF 510-MB determines whether the request is authorized and notifies the NEF 600 if the request is not authorized.
- the MB-PCF 510-MB derives the required QoS parameters based on the information provided by the NEF 600 , determines whether this QoS is allowed (according to the PCF configuration for this AF 512), and notifies the result to the MB-SMF 508-MB.
- the MB-PCF 510-MB notifies the MB-SMF 508-MB whether the transmission resources corresponding to the QoS request are established or not.
- MB-SMF 508-MB responds to the NEF 600 in step 12 with a Result value indicating the failure cause, and the NEF 600 further notifies the AF 512 in step 13.
- Step 9a As an optional step, the MB-SMF 508-MB may register its allocated MB Session ID towards the NRF 602.
- the NRF 602 it is possible for the NRF 602 to have a MB Session ID range configured for a MB-SMF or a MB- SMF pool.
- the MB-SMF 508-MB may register the MB Session ID range of it or its pool prior to the UE joining the MBS session.
- Step 9b As an optional step, the MB-SMF 508-MB may register its allocated MB Session ID towards the BSF 604.
- the MB-SMF 508-MB it is possible for the MB-SMF 508-MB to register the MB Session ID or its pool prior to the UE joining the MBS session.
- Step 10 The MB-SMF 508-MB selects a MB-UPF 514-MB and requests it to reserve user plane ingress resources. If multicast transport of the multicast data towards RAN nodes (e.g., base stations 402) is to be used, the MB-SMF 508-MB also requests the MB-UPF 514-MB to reserve for the outgoing data a tunnel endpoint and the related identifiers (source IP address, source specific multicast address and GTP Tunnel ID) and to forward data received at the user plane ingress resource using that tunnel endpoint.
- RAN nodes e.g., base stations 402
- Step 11 If requested, the MB-UPF 514-MB selects an ingress address (IP address and port) and a tunnel endpoint for the outgoing data and provides it to the MB-SMF 508-MB.
- Step 12 The MB-SMF 508-MB indicates the possibly allocated ingress address to the NEF 600. It also indicates the success or failure of reserving transmission resources.
- Step 13 The NEF 600 indicates the possibly allocated ingress address to the AF 512.
- FIGS 8A through 8C illustrates an MBS Session Join procedure in 5MBS in accordance with one example embodiment of the present disclosure.
- the steps of the procedure of Figures 8A through 8C are as follows. Optional steps are represented by dashed lines/boxes.
- Step 1 The content provider may send a request to register and reserve resources for a multicast group to the NEF 600 and communicate the related multicast address as detailed in 3GPP TR 23.757, clause 6.3.2.2.2.
- the content provider may invoke the services provided by the NEF 600 to provision the multicast information.
- the multicast information is used to identify (e.g., IP Address of multicast data) and reserve resources for the multicast.
- the NEF 600 selects a MB-SMF 508-MB controlling an MB-UPF 514-MB serving as ingress point for the multicast data and creates a multicast context and stores related information including the SMF ID in the UDR.
- the MB-SMF 508-SM may request the MB-UPF 514-MB to allocate an IP address and Port for ingress multicast traffic, which is then provided to the content provider via NEF 600.
- Step 2 The UE 412 registers in the PLMN (see clause 4.2.2.2 of TS 23.502) and requests the establishment of a PDU session (see clause 4.3.2.2 of TS 23.502).
- the UE 412 also indicates its capability to receive multicast data over the radio.
- the AMF 500 obtains information from the UDM 506 about whether the UE 412 can join multicast sessions as part of the SMF Selection Subscription data. If so, for direct discovery, the AMF 500 selects an SMF 508 capable of handling multicast sessions based on locally configured data or a corresponding SMF capability stored in the NRF 602 and also indicates the UE's capability to receive multicast data over the radio to the SMF 508.
- Step 3 The content provider announces the availability of multicast using higher layers (e.g., application layer).
- the announcement includes at least the multicast address of a multicast group that the UE 412 can join.
- Step 4a The UE 412 joins the multicast group.
- Step 4b The reception of the join message triggers the UPF 514 to notify the SMF 508.
- the UPF 514 can be optimized to send the notification only when the UE's status with regard to the multicast group the UE has joined changes, i.e., when the UE 412 joins or leaves a group.
- the SMF initiates PDU session modification procedure upon the reception of the notification from the UPF.
- Step 5 Alternative 2: control plane signaling:
- Step 5a The UE 42 sends the PDU Session Establishment/Modification Request either upon a request from higher layers or upon a detection by lower layers of UE joining a multicast group (i.e., detection of IGMP or MLR and detection of the change of content of these messages).
- the PDU Session Modification Request shall include information about multicast group, which UE 412 wants to join, such as multicast addresses listed in the IGMP and MLR messages. This information is needed for configuration of the UPF 514 with appropriate packet filters.
- Step 5b The AMF 500 invokes Nsmf_PDUSession_UpdateSMContext (SM Context ID, N1 SM container (PDU Session Modification Request with the multicast information)).
- Nsmf_PDUSession_UpdateSMContext SM Context ID, N1 SM container (PDU Session Modification Request with the multicast information)
- Step 6 The SMF 508 may interact with the PCF 510 to check whether the UE is authorized to join the multicast session as described in Figure 6.3.2.2.5-1 of TR 23.757.
- Step 7 If SMF 508 has no information about the multicast context for MB session, SMF 508 may query NRF 602 or BSF 604 to get the MB-SMF ID (or MB-SMF pool) based on the MB Session ID provided.
- SMF 508 can get MB-SMF (e.g., MB-SMF ID) from its local configuration.
- MB-SMF e.g., MB-SMF ID
- Step 8-9 If SMF 508 has no information about the multicast context for the indicated multicast group, SMF 508 interacts with MB-SMF 508-MB to retrieve QoS information of the multicast QoS flow(s). In this step, MB-SMF 508-MB needs not only provide the QoS information, but also link the SMF 508 with the MB Session Context.
- Step 10 SMF requests the AMF to transfer a message to the RAN node using the Namf_N1 N2MessageTransfer service (N2 SM information (PDU Session ID, Multicast Context ID, MB-SMF ID, multicast QoS flow information), N1 SM container (PDU Session Modification Command (PDU Session ID, multicast information (Multicast Context ID, multicast QoS flow information, multicast address)) to create a multicast context in the RAN, if it does not exist already; and inform about the relation between the multicast context and the UE's PDU session.
- N2 SM information PDU Session ID, Multicast Context ID, MB-SMF ID, multicast QoS flow information
- N1 SM container PDU Session Modification Command (PDU Session ID, multicast information (Multicast Context ID, multicast QoS flow information, multicast address)) to create a multicast context in the RAN, if it does not exist already; and inform
- the SMF maps the received QoS information of the multicast QoS flow into unicast QoS flow information of the PDU Session, and includes the information of the unicast QoS flows and the information about the association between those unicast QoS flows and the multicast QoS flows in the N2 SM information. If dedicated unicast QoS flows are required, the information includes the one about those dedicated unicast QoS flows. SMF also includes information about those unicast QoS flows in the N1 SM container.
- the N2 session modification request is sent to the RAN.
- the request is sent in the UE context using the PDU Session Resource Modify Request message enhanced with multicast related information, which includes a multicast group identity (e.g., multicast address), Multicast Session context ID, and multicast flow information such as multicast QoS Flow ID and associating QoS information.
- the RAN uses the multicast group identity to determine that the session modification procedures correspond to one multicast group. In other words, the RAN learns what UEs are receiving the same multicast data from the multicast group identity.
- the RAN configures resources to serve this multicast group.
- Step 12 The N1 SM container (PDU Session Modification Command) is provided to the UE.
- Step 13 The RAN performs the necessary access network resource modification such as configuration of PTP or PTM bearers.
- RAN node checks whether the user plane for the multicast group/context distribution is already established towards the RAN node. If RAN supports MBS, RAN configures the UE for receiving the multicast data via multicast session.
- steps 14 to 18 are executed.
- Step 14 RAN nodes selects the AMF to reach MB-SMF and signals a request towards AMF [MB- SMF ID, Multicast context/group ID], If the RAN node is configured to use a unicast transport for multicast distribution sessions, it allocates a downlink tunnel ID (an IP address and a GTP-U TEID) for the reception of the multicast distribution session and indicates the downlink tunnel information in the request.
- AMF MB- SMF ID, Multicast context/group ID
- Step 15 AMF forwards the request towards the MB-SMF
- Step 16 For unicast transport of the multicast distribution session, MB-SMF configures MB-UPF to transmit the multicast distribution session towards RAN (using the received IP address and a GTP-U TEID).
- Step 17 MB-SMF sends a multicast distribution session response to AMF.
- AMF For multicast transport of the multicast distribution, it indicates in the downlink tunnel information the transport multicast address for the multicast session.
- Step 18 AMF forwards multicast distribution session response to RAN node.
- Step 19 The RAN sends the session modification response, which does not include the unicast tunnel information.
- Step 20 The AMF transfers the session modification response received in step 18 to the SMF.
- the SMF determines that the shared tunnel is used for multicast packet transferring and the interaction with UPF is not needed.
- Step 21 MB-UPF receives multicast PDUs.
- Step 22 MB-UPF sends multicast PDUs in the N3/N9 tunnel associated to the multicast distribution session to the RAN. There is only one tunnel per multicast distribution session and RAN node, i.e., all associated PDU sessions share this tunnel.
- Step 23 The RAN selects PTM or PTP radio bearers to deliver the multicast PDUs to UEs that joined the multicast group.
- Step 24 The RAN performs the transmission using the selected bearer.
- steps 25 to 38 apply
- steps 25 to 28 are executed.
- Step 25 If unicast transport for the multicast data between UPF and MB-UPF is to be used, SMF request UPF to allocate a downlink tunnel endpoint (an IP address and a GTP-U TEID).
- Step 26 SMF signals a request for the multicast session distribution towards MB-SMF [Multicast context/group ID, downlink tunnel info].
- Step 27 MB-SMF configures MB-UPF to transmit the multicast distribution session towards UPF (using the received IP address and GTP-U TEID).
- Step 28 MB-SMF sends a multicast distribution session response to SMF.
- SMF For multicast transport of the multicast distribution, it also indicates in the downlink tunnel information the transport multicast address for the multicast session.
- steps 25 to 28 can also be triggered after the step 34, i.e. when the SMF determines that RAN does not support MBS.
- Step 29 SMF configures UPF to receive the multicast distribution session and forward the data within unicast transport.
- steps 30 to 34 apply.
- Step 30 The SMF1 derives the QoS Rules for the unicast transfer of multicast data based on QoS parameters for multicast transmission received in step 25.
- SMF1 maps the multicast QFI to a unicast QFI of the PDU Session; other QoS parameters of unicast QoS Rules are same as the one for multicast transmission.
- the SMF1 requests the AMF to transfer a message to the RAN node using the Namf_N1 N2MessageTransfer service (N1 SM container (PDU Session Modification Command (PDU Session ID, unicast QoS rule(s)).
- N1 SM container PDU Session Modification Command (PDU Session ID, unicast QoS rule(s)).
- Step 31 The N2 session modification request is sent to the RAN.
- Step 32 The N1 SM container (PDU Session Modification Command) is provided to the UE.
- Step 33 The RAN sends the session modification response.
- Step 34 The AMF transfers the session modification response received in step 30 to the SMF1 via the Nsmf_PDUSession_UpdateSMContext service.
- Step 35 MB-UPF receives multicast PDUs.
- Step 36 MB-UPF sends multicast PDUs in the N3/N9 tunnel associated to the multicast distribution session to UPF. There is only one tunnel per multicast distribution session and destination UPF, i.e. , all associated PDU sessions share this tunnel.
- Step 37 UPF forwards the multicast data via unicast.
- Step 38 The RAN forwards the multicast data via unicast.
- MB-SMF needs to synchronize its pool members not only when session creation, but also when it links MB Session context with the SMF. In another word, MB-SMFs are always synchronized. In this solution, no matter which MB-SMF is selected by SMF, it can always perform the request handling.
- MB-SMF1 perform session creation and synchronize the information with MB-SMF2.
- SMF send request to MB-SMF2.
- MB-SMF2 link the MB Session context with the SMF and synchronize the information with MB-SMF1
- MB-SMF performs request forwarding, redirect or rejection to enable the request to be handled by the proper MB-SMF.
- the solutions are described as the figure below. Assume MB-SMF1 and MB-SMF2 are within the same MB-SMF pool. MB-SMF1 is the one who create MB Session and MB-SMF2 is the one who handle the MB Session Join Request.
- FIG. 9 illustrates a procedure in this regard in accordance with one embodiment of the present disclosure. The steps of this procedure are as follows.
- Step 1 UE perform MB Session Join towards SMF via AMF. It is possible that the MB Session Join request is implemented as PDU session modification or PDU session creation request.
- Step 2 SMF performs MB-SMF selection based on local configuration or by querying the NRF. Assume the SMF selects MB-SMF2, which is different from the AS selected one.
- Step 3 SMF perform MB Session Context Query towards MB-SMF2 providing MB Session ID.
- Step 4 MB-SMF does not have the MB Session Context for the MB Session ID, it queries its pool member who is the owner of the session (i.e., who has created the session). In this example, the MB-SMF1 has the info.
- Option-1 (implicit request forward):
- Step 5A MB-SMF1 link the SMF with the MB Session Context directly and return MB Session Context to MB-SMF2
- Step 5B MB-SMF2 return the MB Session Context and the right owner (MB-SMF1) to SMF
- Step 6A MB-SMF1 respond to MB-SMF2 that it is the right owner
- Step 6B MB-SMF2 reject the request and ask SMF to send the request to MB-SMF1
- Step 6C SMF send MB Session Context Query towards MB-SMF1
- Step 6D MB-SMF1 link the SMF with the MB Session Context and return MB Session Context to SMF
- Step 7A MB-SMF1 respond to MB-SMF2 that it is the right owner
- Step 7B MB-SMF2 forward the request to MB-SMF1
- Step 7C MB-SMF1 link the SMF with the MB Session Context and return MB Session Context and the right owner (its instance) to SMF
- MB-SMFs perform the synchronization so that each MB-SMF has the session context information. But in handling the request SMF, it is always the owner to deal with it. Compared with chapter 1.3.2, step 4 is not necessary, as MB-SMF2 already knows MB-SMF1 is the owner
- Option-2 is applicable, and step 6A is not necessary Option-3 is applicable, and step 7A is not necessary This is illustrated in Figure 10.
- the NEF has the association of MB-SMF ID and MBS Session ID, here the MBS Session ID may or may not be allocated by MB-SMF;
- NEF Id is pre-configured in the UDM as subscription data
- the SMF gets subscription data (including NEF ID) from the UDM;
- the SMF When the first UE join an MBS Session, the SMF then check the NEF if any MB-SMF Id is associated with the MBS Session. For example, rather than performing step 7 of Figure 8, the SMF may query the NEF to determine whether any MB-SMF ID is associated with the MBS session.
- Figure 11 illustrates a procedure in accordance with one example embodiment of a solution in which an SMF gets the MB-SMF ID from the NEF.
- NEF After NEF interacts with MB-SMF, NEF has the association of MB-SMF ID and MBS Session ID, and then NEF provides the association to the UDM(s).
- the assumption here is that AF knows the list of UEs that are authorized to join the MBS Session so that the NEF can find the UDMs handling the UEs.
- the SMF gets subscription data (including MB-SMF ID and MBS Session ID) from the UDM.
- the SMF may obtain the subscription data including the MB-SMF ID and MBS session ID from the UDM during PDU session establishment in step 2 of Figure 8A. As such, step 7 of Figure 8A may not be performed.
- FIG 12 is a schematic block diagram of a network node 1200 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes.
- the network node 1200 may be, for example, a network node that implements a core network function (e.g., a MB-SMF or MB-SMF instance, AMF 500, MB-SMF, SMF, PCF, MB-PCF, UPF, MB-PCF, etc.) or a base station 402 or 406.
- a core network function e.g., a MB-SMF or MB-SMF instance, AMF 500, MB-SMF, SMF, PCF, MB-PCF, UPF, MB-PCF, etc.
- the network node 1200 includes a control system 1202 that includes one or more processors 1204 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 1206, and a network interface 1208.
- the one or more processors 1204 are also referred to herein as processing circuitry.
- the network node 1200 is a radio access node (e.g., a base station 402 or low power node 406), the network node 1200 may also include one or more radio units 1210 that each includes one or more transmitters 1212 and one or more receivers 1214 coupled to one or more antennas 1216.
- the radio units 1210 may be referred to or be part of radio interface circuitry.
- the radio unit(s) 1210 is external to the control system 1202 and connected to the control system 1202 via, e.g., a wired connection (e.g., an optical cable).
- a wired connection e.g., an optical cable
- the radio unit(s) 1210 and potentially the antenna(s) 1216 are integrated together with the control system 1202.
- the one or more processors 1204 operate to provide one or more functions of the network node 1200 as described herein (e.g., one or more functions of a NF (e.g., AMF, PCF, SMF, UPF, MB-PCF, MB-SMF, MB-UPF, NEF, NRF, UDM, etc., as described herein).
- a NF e.g., AMF, PCF, SMF, UPF, MB-PCF, MB-SMF, MB-UPF, NEF, NRF, UDM, etc.
- the function(s) are implemented in software that is stored, e.g., in the memory 1206 and executed by the one or more processors 1204.
- FIG. 13 is a schematic block diagram that illustrates a virtualized embodiment of the network node 1200 according to some embodiments of the present disclosure.
- a “virtualized” network node is an implementation of the network node 1200 in which at least a portion of the functionality of the network node 1200 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)).
- the network node 1200 includes one or more processing nodes 1300 coupled to or included as part of a network(s) 1302.
- Each processing node 1300 includes one or more processors 1304 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1306, and a network interface 1308. If the network node 1200 is a radio access node, the network node 1200 may include the control system 1202 and/or the one or more radio units 1210, as described above.
- functions 1310 of the network node 1200 described herein are implemented at the one or more processing nodes 1300 or distributed across the one or more processing nodes 1300 and the control system 1202 and/or the radio unit(s) 1210 in any desired manner.
- some or all of the functions 1310 of the network node 1200 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1300.
- a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 1200 or a node (e.g., a processing node 1300) implementing one or more of the functions 1310 of the network node 1200 in a virtual environment according to any of the embodiments described herein (e.g., AMF, PCF, SMF, UPF, MB-PCF, MB-SMF, MB-UPF, NEF, NRF, UDM, etc., as described herein) is provided.
- a carrier comprising the aforementioned computer program product is provided.
- the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
- FIG 14 is a schematic block diagram of the network node 1200 according to some other embodiments of the present disclosure.
- the network node 1200 includes one or more modules 1400, each of which is implemented in software.
- the module(s) 1400 provide the functionality of the network node 1200 described herein (e.g., AMF, PCF, SMF, UPF, MB-PCF, MB-SMF, MB-UPF, NEF, NRF, UDM, etc., as described herein).
- This discussion is equally applicable to the processing node 1300 of Figure 13 where the modules 1400 may be implemented at one of the processing nodes 1300 or distributed across multiple processing nodes 1300 and/or distributed across the processing node(s) 1300 and the control system 1202.
- FIG. 15 is a schematic block diagram of a UE 412 according to some embodiments of the present disclosure.
- the UE 412 includes one or more processors 1502 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1504, and one or more transceivers 1506 each including one or more transmitters 1508 and one or more receivers 1510 coupled to one or more antennas 1512.
- the transceiver(s) 1506 includes radio-front end circuitry connected to the antenna(s) 1512 that is configured to condition signals communicated between the antenna(s) 1512 and the processor(s) 1502, as will be appreciated by on of ordinary skill in the art.
- the processors 1502 are also referred to herein as processing circuitry.
- the transceivers 1506 are also referred to herein as radio circuitry.
- the functionality of the UE 412 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1504 and executed by the processor(s) 1502.
- the UE 412 may include additional components not illustrated in Figure 15 such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the UE 412 and/or allowing output of information from the UE 412), a power supply (e.g., a battery and associated power circuitry), etc.
- a power supply e.g., a battery and associated power circuitry
- a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the UE 412 according to any of the embodiments described herein is provided.
- a carrier comprising the aforementioned computer program product is provided.
- the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
- FIG 16 is a schematic block diagram of the UE 412 according to some other embodiments of the present disclosure.
- the UE 412 includes one or more modules 1600, each of which is implemented in software.
- the module(s) 1600 provide the functionality of the UE 412 described herein.
- MB-SMF multicast/broadcast session management function
- MB-SMF 508-MB: o receiving (Fig. 7, step 5) a request from a network exposure function, NEF, (600) for a multicast session; o allocating (Fig. 7, step 5a) a MB session ID for the multicast session; and o sending (Fig. 7, step 12) a response to the NEF (600) comprising the MB session ID for the multicast session.
- the method of embodiment 1 further comprising: at the MB-SMF (508-MB): o sending (Fig. 7, step 9a) a message to a network repository function, NRF, (602), the message comprising the information that associates the MB session ID to the MB-SMF (508-MB).
- the method further comprises synchronization information about the multicast session across the two or more MB-SMFs in the MB-SMF pool during session creation and also when a MB session context of the MB session is linked with a SMF.
- a second MB-SMF o receiving (Fig. 9, step 3), from a SMF (508), a MB session context query comprising the MB session ID; o sending (Fig. 9, step 4) a query to the MB-SMF (508-MB); o receiving (Fig. 9, step 5A) a response to the query comprising a MB session context for the multicast session; and o sending (Fig. 9, step 5B) the MB session context to the SMF (508).
- a second MB-SMF o receiving (Fig. 9, step 3), from a SMF (508), a MB session context query comprising the MB session ID; o sending (Fig. 9, step 4) a query to the MB-SMF (508-MB); o receiving (Fig. 9, step 6A) a response to the query from the MB-SMF (508-MB); and o sending (Fig. 9, step 6B), to the SMF (508), a rejection of the MB session context query and a request to redirect to the MB-SMF (508-MB).
- a second MB-SMF o receiving (Fig. 9, step 3), from a SMF (508), a MB session context query comprising the MB session ID; o sending (Fig. 9, step 4) a query to the MB-SMF (508-MB); o receiving (Fig. 9, step 7A) a response to the query from the MB-SMF (508-MB); and o forwarding (Fig. 9, step 6B) the MB session context query to the MB-SMF (508-MB).
- a second MB-SMF o receiving (Fig. 10, step 3), from a SMF (508), a MB session context query comprising the MB session ID; and o sending (Fig. 10, step 6B), to the SMF (508), a rejection of the MB session context query and a request to redirect to the MB-SMF (508-MB).
- a second MB-SMF o receiving (Fig. 10, step 3), from a SMF (508), a MB session context query comprising the MB session ID; and o forwarding (Fig. 9, step 6B) the MB session context query to the MB-SMF (508-MB).
- MB-SMF MB-SMF
- 508-MB o receiving (Fig. 11 , step 5) a request from a network exposure function, NEF, (600) for a multicast session, the request comprising a multicast group ID; o sending (Fig. 11 , step 12) a response to the NEF (600) comprising a MB session ID for the multicast session, wherein the multicast group ID is used as the MB session ID.
- SMF session management function
- a network node (1200) adapted to perform the steps of the second MB-SMF (MB-SMF2) or the second MB-SMF (508-MB) according to any one of embodiment 13 to 16.
- a network node (1200) adapted to perform the steps of the NRF or BSF according to any one of embodiment 20 to 23.
- a network node (1200) adapted to perform the steps of the method of embodiment 26.
- any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses.
- Each virtual apparatus may comprise a number of these functional units.
- These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like.
- the processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc.
- Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein.
- the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Sont divulgués ici des systèmes et des procédés qui se rapportent à la découverte de fonction de gestion de session (SMF) de multidiffusion/radiodiffusion (MB) (MB-SMF). Selon un mode de réalisation, un procédé mis en œuvre dans un réseau central d'un système de communication cellulaire consiste à, au niveau d'une MB-SMF, recevoir une demande en provenance d'une fonction d'exposition de réseau (NEF) d'une session de multidiffusion, à attribuer un ID de session de MB pour la session de multidiffusion, et à envoyer une réponse à la NEF comprenant l'ID de session de MB pour la session de multidiffusion. Selon un mode de réalisation, le procédé consiste en outre à, au niveau de la MB-SMF, envoyer un message à une fonction de dépôt de réseau (NRF), le message comprenant les informations qui associent l'ID de session de MB à la MB-SMF. De cette manière, l'association de l'ID de session de MB à la MB-SMF est connue de la NRF, qui peut ensuite être interrogée pour une découverte de MB-SMF, par exemple, au cours d'une procédure de connexion à une session.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNPCT/CN2021/072059 | 2021-01-15 | ||
CN2021072059 | 2021-01-15 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2022152625A1 true WO2022152625A1 (fr) | 2022-07-21 |
Family
ID=80035054
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2022/050251 WO2022152625A1 (fr) | 2021-01-15 | 2022-01-07 | Découverte de service de smf de 5mbs pour mb-smf |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2022152625A1 (fr) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2607267A (en) * | 2021-04-06 | 2022-12-07 | Nokia Technologies Oy | Storing multicast information |
-
2022
- 2022-01-07 WO PCT/EP2022/050251 patent/WO2022152625A1/fr active Application Filing
Non-Patent Citations (2)
Title |
---|
ERICSSON: "KI #1 Evaluation on AMF-centric vs SMF-centric multicast solutions", vol. SA WG2, no. E (e-meeting) Elbonia ;20201116 - 20201120, 9 November 2020 (2020-11-09), XP051953247, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_142e_Electronic/Docs/S2-2008931.zip S2-2008931_23757_KI#1_EvalAMFvsSMFcentricMulticast_r1.pptx> [retrieved on 20201109] * |
ERICSSON: "KI#1: Update to Sol#2", vol. SA WG2, no. E-Meeting; 20200819 - 20200901, 2 September 2020 (2020-09-02), XP051928711, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_140e_Electronic/Docs/S2-2006045.zip S2-2006045was4968_23757_5MBS_updateSol#2toKI#1.doc> [retrieved on 20200902] * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2607267A (en) * | 2021-04-06 | 2022-12-07 | Nokia Technologies Oy | Storing multicast information |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11937337B2 (en) | Methods and apparatuses for alternative data over non-access stratum, donas, data delivery in a roaming scenario | |
US10455406B2 (en) | Method and apparatus for generating packet data network connection of user equipment | |
EP4042830B1 (fr) | Libération en masse de plusieurs sessions pdu | |
WO2022171122A1 (fr) | Procédé de mise en œuvre d'une commutation de service de diffusion/multidiffusion, et dispositifs associés | |
WO2022170766A1 (fr) | Procédé de mise en œuvre d'un transfert de service de diffusion/multidiffusion, et dispositif associé | |
US20230086661A1 (en) | 5mbs amf service discovery for mb-smf | |
US20220151004A1 (en) | Avoiding transmission of unnecessary 5gsm message | |
US20230096763A1 (en) | Ran-5gc interactions for session join, session start, session leave, session stop, and session delete for 5g multicast broadcast services | |
US20230403547A1 (en) | NOTIFICATION OF DISASTER CONDITION AND ALTERNATIVE PLMNs | |
US20230337087A1 (en) | Re-anchoring with smf re-selection | |
CN113785552A (zh) | 会话管理功能选择 | |
WO2022152616A2 (fr) | Procédés et appareils pour modifier une tranche de réseau | |
WO2022069989A1 (fr) | Garantie de commande de réseau d'accès simultané à des tranches de réseau avec une sensibilité à l'application | |
WO2022152625A1 (fr) | Découverte de service de smf de 5mbs pour mb-smf | |
WO2022157069A1 (fr) | Nid pour id de session mb pour 5mbs | |
US20230269573A1 (en) | Systems and methods for ue context management in sidelink relay scenarios | |
KR20240018427A (ko) | 멀티캐스트 브로드캐스트 서비스 세션 확립 방법, 및 그 시스템과 장치 | |
WO2017000591A1 (fr) | Procédé d'envoi d'informations et terminal | |
US20240073254A1 (en) | Simultaneous calling in 5g | |
US20240147191A1 (en) | Method and apparatus for 5mbs nation-wide service | |
US20230156653A1 (en) | Network requested registration procedure initiation | |
US20230319621A1 (en) | VoWiFi SPLIT PDU SESSION HANDOVER | |
WO2022229883A1 (fr) | Implication d'amf 5mbs dans l'efficacité de signalisation | |
WO2022161815A1 (fr) | Commande de ran pour mbs local et service mbs géodépendant | |
WO2022214395A1 (fr) | Amélioration de la sélection d'upf par nrf |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22700734 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 22700734 Country of ref document: EP Kind code of ref document: A1 |