WO2022155139A1 - Gestion de connexions de réseau à base de paquets pendant un transfert intercellulaire - Google Patents

Gestion de connexions de réseau à base de paquets pendant un transfert intercellulaire Download PDF

Info

Publication number
WO2022155139A1
WO2022155139A1 PCT/US2022/011996 US2022011996W WO2022155139A1 WO 2022155139 A1 WO2022155139 A1 WO 2022155139A1 US 2022011996 W US2022011996 W US 2022011996W WO 2022155139 A1 WO2022155139 A1 WO 2022155139A1
Authority
WO
WIPO (PCT)
Prior art keywords
handover
message
procedure
request
ran
Prior art date
Application number
PCT/US2022/011996
Other languages
English (en)
Inventor
Chih-Hsiang Wu
Original Assignee
Google Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google Llc filed Critical Google Llc
Publication of WO2022155139A1 publication Critical patent/WO2022155139A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup

Definitions

  • This disclosure relates generally to wireless communications and, more particularly, to managing connections with a packet-based network during a handover for a user equipment (UE) communication with a radio access network (RAN).
  • UE user equipment
  • RAN radio access network
  • the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as transfer of user-plane data, ciphering, integrity protection, etc.
  • the PDCP layer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) radio interface (see 3GPP specification TS 36.323) and New Radio (NR) (see 3GPP specification TS 38.323) provides sequencing of protocol data units (PDUs) in the uplink direction (from a user device, also known as a user equipment (UE), to a base station) as well as in the downlink direction (from the base station to the UE).
  • EUTRA Evolved Universal Terrestrial Radio Access
  • NR New Radio
  • the PDCP sublayer provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer.
  • the PDCP sublayer also provides services for data radio bearers (DRBs) to a Service Data Adaptation Protocol (SDAP) sublayer or a protocol layer such as an Internet Protocol (IP) layer, an Ethernet protocol layer, and an Internet Control Message Protocol (ICMP) layer.
  • SDAP Service Data Adaptation Protocol
  • IP Internet Protocol
  • ICMP Internet Control Message Protocol
  • the UE and a base station can use SRBs to exchange RRC messages as well as non-access stratum (NAS) messages, and can use DRBs to transport data on a user plane.
  • NAS non-access stratum
  • the UE in some scenarios can concurrently utilize resources of multiple nodes (e.g., base stations or components of a distributed base station or disaggregated base station) of a radio access network (RAN), interconnected by a backhaul.
  • a radio access network RAN
  • RATs radio access technologies
  • this type of connectivity is referred to as Multi-Radio Dual Connectivity (MR-DC).
  • MN master node
  • MSG master cell group
  • SCG secondary cell group
  • the MCG covers a primary cell (PCell) and zero, one, or more secondary cells (SCells), and the SCG covers a primary secondary cell (PSCell) and zero, one, or more SCells.
  • the UE communicates with the MN (via the MCG) and the SN (via the SCG). In other scenarios, the UE utilizes resources of one base station at a time, i.e., single connectivity (SC).
  • SC single connectivity
  • the UE in SC only communicates with the MN (via the MCG).
  • One base station and/or the UE determines that the UE should establish a radio connection with another base station. For example, one base station can determine to hand the UE over to the second base station, and initiate a handover procedure.
  • the UE in other scenarios can concurrently utilize resources of a RAN node (e.g., a single base station or a component of a distributed base station or a disaggregated base station), interconnected by a backhaul.
  • SRB1 resources carry RRC messages, which in some cases include NAS messages over the dedicated control channel (DCCH), and SRB2 resources support RRC messages that include logged measurement information or NAS messages, also over the DCCH but with lower priority than SRB1 resources.
  • SRB1 and SRB2 resources allow the UE and the MN to exchange RRC messages related to the MN and embed RRC messages related to the SN, and also can be referred to as MCG SRBs.
  • SRB3 resources allow the UE and the SN to exchange RRC messages related to the SN, and can be referred to as SCG SRBs.
  • Split SRBs allow the UE to exchange RRC messages directly with the MN via lower layer resources of the MN and the SN.
  • DRBs terminated at the MN and using the lower-layer resources of only the MN can be referred as MCG DRBs
  • DRBs terminated at the SN and using the lower- layer resources of only the SN can be referred to as SCG DRBs
  • DRBs terminated at the MN or SN but using the lower-layer resources of both the MN and the SN can be referred to as split DRBs.
  • DRBs terminated at the MN but using the lower-layer resources of only the SN can be referred to as MN-terminated SCG DRBs.
  • DRBs terminated at the SN but using the lower-layer resources of only the MN can be referred to as SN-terminated MCG DRBs.
  • UEs can perform handover procedures to switch from one cell to another, whether in single connectivity (SC) or DC operation. These procedures involve messaging (e.g., RRC signaling and preparation) among RAN nodes and the UE.
  • the UE may handover from a cell of a serving base station to a target cell of a target base station, or from a cell of a first distributed unit (DU) of a serving base station to a target cell of a second DU of the same base station, depending on the scenario.
  • DU distributed unit
  • UEs can perform PSCell change procedures to change PSCells. These procedures involve messaging (e.g., RRC signaling and preparation) among RAN nodes and the UE.
  • the UE may perform a PSCell change from a PSCell of a serving SN to a target PSCell of a target SN, or from a PSCell of a source DU of a base station to a PSCell of a target DU of the same base station, depending on the scenario. Further, the UE may perform a handover or PSCell change within a cell for synchronous reconfiguration.
  • a UE supporting NR and LTE supports voice over LTE (VoLTE) and does not support voice over NR (VoNR).
  • the UE supporting NR and LTE supports VoLTE and VoNR and a NR network may not support VoNR.
  • the UE makes a mobile originating (MO) IMS voice call with an IMS network via a serving base station in the NR network
  • the NR network redirects or hands over the UE to an LTE network.
  • the IMS network initiates a mobile terminating (MT) IMS voice call with the UE 102 via the NR network
  • the serving base station the NR network redirects or hands over the UE to an LTE network.
  • the UE and IMS network can establish the MO or MT IMS voice call with one another via the LTE network.
  • the techniques of redirecting or handing over the UE from NR to LTE for an IMS voice call are called EPS fallback or RAT fallback.
  • a RAN and/or a CN implement the techniques of this disclosure to manage a packet-based call (e.g., IMS voice and/or video) during a handover of a UE from a source node to a target node.
  • the nodes can be different base stations or different distributed units (DUs) of a distributed base station, for example.
  • the UE or the RAN can perform handover preparation, so that the UE can transition from the source node to the target node.
  • the IMS service then can request resources for the IMS session from the source base station.
  • the RAN and/or the CN of this disclosure continue the initiation procedure after receiving the request for resources.
  • the CN in some implementations sends a new request for resources to the target node.
  • the source node determines that the target node does support the requested IMS service over the corresponding RAT, and cancels the handover. In this manner, the source node prompts the UE to connect via another cell, in which the corresponding RAT supports the requested IMS service.
  • One example embodiment of these techniques is a method in a radio access network (RAN) for managing a packet-based call during a handover of a UE.
  • the method includes performing, by processing hardware, an initiation procedure for a session of a packet-based service, the initiation procedure including an exchange of one or more messages between the UE and a packet-based service network via a source node of the RAN; prior to completion of the initiation procedure, performing a handover preparation procedure for handing the UE over to a target node of the RAN; receiving, by the processing hardware from a core network (CN) and after the handover preparation procedure, a request for resources for the session; and continuing, by the processing hardware, the initiation procedure after receiving the request for resources.
  • CN core network
  • RAN radio access network
  • Another example embodiment of these techniques is a method in a core network (CN) for processing a packet-based call during a handover of a UE from a source node of a radio access network (RAN).
  • the method includes facilitating, by processing hardware, an initiation procedure for a session of a packet-based service, the initiation procedure including an exchange of one or more messages between the UE and a packet-based service network via the source node and the CN; transmitting, by the processing hardware to the source node, a first request for resources for the session; receiving, by the processing hardware from the source node, a response for the first request, the response including an indication that a handover of the UE from the source node has been triggered; and transmitting, by the processing hardware to the target node, a second request for resources for the session.
  • CN core network
  • Another example embodiment of these techniques is a core network (CN) comprising processing hardware and configured to implement a method according to the above method.
  • FIG. 1A is a block diagram of an example system in which one or more base stations and/or a user equipment (UE) can implement the techniques of this disclosure for managing packet-based communications during a handover between the UE and a radio access network (RAN);
  • UE user equipment
  • RAN radio access network
  • Fig. IB is a block diagram of an example base station including a central unit (CU) and a distributed unit (DU) that can operate in the system of Fig. 1A;
  • CU central unit
  • DU distributed unit
  • FIG. 2 is a block diagram of an example protocol stack according to which the UE of Figs. 1A-B can communicate with base stations;
  • Fig. 3A illustrates an example message sequence in which a source base station receives a request for resources for a packet-based service after initiating an IMS service and preparing a handover to a first target base station, and cancels the handover so as to cause the UE to establish a new radio connection with a second target base station;
  • Fig. 3B illustrates a scenario similar to that of Fig. 3A, but with the handover preparation performed via a core network (CN) and the source base station cancelling the handover via the CN;
  • CN core network
  • Fig. 3C illustrates a scenario similar to that of Fig. 3A, but with the source base station preparing a second handover procedure with the CN for a second target base station, after cancelling the first handover;
  • Fig. 3D illustrates a scenario similar to that of Fig. 3B, but with the source base station preparing a second handover procedure with the CN for a second target base station after cancelling the first handover;
  • Fig. 3E illustrates an example message sequence in which a source base station receives a request for resources for a packet-based service after initiating an IMS service and preparing a handover to a first target base station, and the target base station after the first handover receives a new request for resources from the CN;
  • FIG. 3F illustrates a scenario similar to that of Fig. 3E, but with the handover preparation performed via the CN;
  • FIG. 3G illustrates a scenario similar to that of Fig. 3E, but with the target base station preparing a second handover procedure with the CN for a second target base station, after the first handover;
  • Fig. 3H illustrates a scenario similar to that of Fig. 3F, but with the target base station preparing a second handover procedure with the CN for a second target base station, after the first handover;
  • Fig. 4 is a flow diagram of an example method for continuing initiation of an IMS service by causing the UE to move to a carrier frequency of another RAT, which can be implemented in the RAN of Fig. 1 A;
  • Fig. 5 is a flow diagram of an example method for rejecting a request for resources from a CN during a handover procedure, which can be implemented in the RAN of Fig. 1 A;
  • Fig. 6 is a flow diagram of an example method in which the RAN determines whether it should move the UE to another carrier frequency based on whether the CN requests resources for a packet-based service or a flow with a certain QoS class indicator (QCI);
  • QCI QoS class indicator
  • Fig. 7 is a flow diagram of an example method in which the RAN determines whether it should move the UE to another carrier frequency based on whether the UE supports a packet-based service or a flow with a certain QCI;
  • Fig. 8 is a flow diagram of an example method in which the RAN determines whether it should move the UE to another carrier frequency based on the latest signal measurements associated with the UE;
  • Fig. 9 is a flow diagram of an example method for processing a packet-based call during a handover of a UE, which can be implemented in the CN of Fig. 1 A;
  • Fig. 10 is a flow diagram of an example method similar to that of Fig. 5, but in which a central unit (CU) communicates with a UE via a first distributed unit (DU) and prepares and executes a handover to a second DU;
  • CU central unit
  • DU distributed unit
  • Fig. 11 is a flow diagram of an example method similar to that of Fig. 4, but in which a CU communicates with a UE via a first DU and prepares a handover to a second DU before cancelling the handover in response to a request for resources;
  • Fig. 12 is a flow diagram of an example method similar to that of Fig. 6, but in which a CU communicates with a UE via a first DU and prepares a handover to a second DU;
  • FIG. 13 is a flow diagram of an example method similar to Fig. 7, but in which a CU communicates with a UE via a first DU and prepares a handover to a second DU;
  • FIG. 14 is a flow diagram of an example method similar to Fig. 8, but in which a CU communicates with a UE via a first DU and prepares a handover to a second DU;
  • Fig. 15 is an example method for processing a packet-based call during a handover of a UE, which can be implemented in a suitable RAN;
  • Fig. 16 is an example method for processing a packet-based call during a handover of a UE, which can be implemented in a suitable CN.
  • Fig. 1A depicts an example wireless communication system 100 in which communication devices can implement these techniques.
  • the wireless communication system 100 includes a UE 102, a base station 104 (source BS 104), a base station 106A (operating in the handover scenarios discussed below as the target BS 106A or, in some cases, the first target BS 106A), a base station 106B (operating in the handover scenarios discussed below as the second target BS 106B), and a core network (CN) 110.
  • the UE 102 initially connects to the base station 104.
  • the base stations 104, 106A, and 106B can operate in a RAN 105 connected to the CN 110.
  • the CN 110 can be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC), 160, for example.
  • EPC evolved packet core
  • 5G fifth generation
  • the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116.
  • SGW Serving Gateway
  • MME Mobility Management Entity
  • PGW Packet Data Network Gateway
  • the SGW 112 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc.
  • MME Mobility Management Entity
  • the MME 114 is configured to manage authentication, registration, paging, and other related functions.
  • the PGW 116 provides connectivity from the UE to external packet data networks including Internet network and/or an Internet Protocol (IP) Multimedia Subsystem (IMS) network by being the point of exit and entry of traffic for the UE.
  • IP Internet Protocol
  • IMS Internet Multimedia Subsystem
  • the 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management Function (AMF) 164, and/or Session Management Function (SMF) 166.
  • UPF User Plane Function
  • AMF Access and Mobility Management Function
  • SMF Session Management Function
  • the UPF 162 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc.
  • the AMF 164 is configured to manage authentication, registration, paging, and other related functions
  • the SMF 166 is configured to manage PDU sessions.
  • the base station 104 supports a cell 124
  • the base station 106A supports a cell 126A
  • the base station 106B supports a cell 126B.
  • the base station 104 can additionally support a cell 122
  • the base station 106A can additionally support a cell 128A.
  • the cells 124 and 126A can partially overlap, so that the UE 102 can communicate in DC with the base station 104 and the base station 106 A operating as a master node (MN) and a secondary node (SN), respectively.
  • MN master node
  • SN secondary node
  • the MN 104 and the SN 106A can support an X2 or Xn interface.
  • the CN 110 can connect to any suitable number of base stations supporting NR cells and/or EUTRA cells.
  • the base station 104 is equipped with processing hardware 130 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units.
  • the processing hardware 130 in an example implementation includes an RRC controller 132 configured to manage RRC procedures such as RRC connection reestablishment procedure, RRC (connection) reconfiguration procedure, handover procedure, reconfiguration with sync procedure, and/or measurement configuration and reporting procedure, discussed with reference to the message and flow diagrams below.
  • the processing hardware 130 also includes an interface controller 134 configured to manage network procedures with the CN 110 and/or another base station (e.g., the base station 106A, 106B), discussed with reference to the message and flow diagrams below.
  • the base station 106A is equipped with processing hardware 140 that can also include one or more general-purpose processors such as CPUs and non-transitory computer- readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units.
  • the processing hardware 140 in an example implementation includes an RRC controller 142 configured to manage RRC procedures such as RRC connection reestablishment procedure, RRC (connection) reconfiguration procedure, handover procedure, reconfiguration with sync procedure, and/or measurement configuration and reporting procedure, discussed with reference to the message and flow diagrams below.
  • the processing hardware 140 also includes an interface controller 144 configured to manage network procedures with the CN 110 and/or another base station (e.g., the base station 106A, 106B), discussed with reference to the message and flow diagrams below.
  • the base station 106B can have hardware that is the same as or similar to the base station 104 or the base station 106A.
  • the UE 102 is equipped with processing hardware 150 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units.
  • the processing hardware 150 in an example implementation includes an RRC controller 152 configured to manage RRC procedures such as RRC connection reestablishment procedure, RRC (connection) reconfiguration procedure, handover procedure, reconfiguration with sync procedure, and/or measurement configuration and reporting procedure, discussed with reference to the message and flow diagrams below.
  • the UE 102 can use one or more radio bearers (e.g., DRB(s) and/or an SRB(s)) to communicate with the base station 104.
  • the UE 102 can receive a radio bearer configuration configuring the radio bearer from the base station 104.
  • the UE 102 can apply one or more security keys when communicating on the radio bearer, in the uplink (from the UE 102 to a base station) and/or downlink (from a base station to the UE 102) direction.
  • the UE 102 in some cases can use different RATs to communicate with the base stations 104 and 106A.
  • the techniques of this disclosure also can apply to other suitable radio access and/or core network technologies such as sixth generation (6G) radio access and/or 6G core networks.
  • 6G sixth generation
  • the CN 110 communicatively connects the UE 102, to an Internet Protocol (IP) Multimedia Subsystem (IMS) network 170, via the RAN 105.
  • IP Internet Protocol
  • IMS Internet Multimedia Subsystem
  • the IMS network 170 can provide to the UE 102 various IMS services, such as IMS short messages, IMS unstructured supplementary service data (USSD), IMS value added service data, IMS supplementary service data, IMS voice calls, and IMS video calls.
  • an entity e.g., a server or a group of servers
  • operating in the IMS network 170 supports packet exchange with the UE.
  • the packets can convey signaling (such as session initiation protocol (SIP) messages, IP messages, or other suitable messages) as well as data (“or media”) such as voice or video.
  • signaling such as session initiation protocol (SIP) messages, IP messages, or other suitable messages
  • data such as voice or video.
  • the CN 110 in general can connect to, or include, any suitable system that provides packet-based calls.
  • Fig. IB depicts an example, distributed implementation of any one or more of the base stations 104, 106A, or 106B.
  • the base station 104, 106A, or 106B includes a central unit (CU) 172 and one or more distributed units (DUs) 174.
  • the CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units.
  • the CU 172 can include the processing hardware 130 or 140 of Fig. 1A.
  • Each of the DUs 174 also includes processing hardware that can include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units.
  • the processing hardware can include a medium access control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., a random access procedure), and a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station 106A) operates as an MN or an SN.
  • the processing hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.
  • the CU 172 can include a logical node CU-CP 172A that hosts the control plane part of the Packet Data Convergence Protocol (PDCP) protocol of the CU 172 and/or radio resource control (RRC) protocol of the CU 172.
  • the CU 172 can also include logical node(s) CU-UP 172B that hosts the user plane part of the PDCP protocol and/or Service Data Adaptation Protocol (SDAP) protocol of the CU 172.
  • the CU-CP 172A can transmit the non-MBS control information and MBS control information
  • the CU-UP 172B can transmit the non-MBS data packets and MBS data packets, as described herein.
  • the CU-CP 172 A can be connected to multiple CU-UP 172B through the El interface.
  • the CU-CP 172A selects the appropriate CU-UP 172B for the requested services for the UE 102.
  • a single CU-UP 172B can be connected to multiple CU-CP 172A through the El interface.
  • the CU-CP 172A can be connected to one or more DU 174s (e.g., DU 174-1, DU 174-2, etc.) through an Fl-C interface.
  • the CU-UP 172B can be connected to one or more DU 174 through the Fl-U interface under the control of the same CU-CP 172A.
  • one DU 174 can be connected to multiple CU-UP 172B under the control of the same CU-CP 172A.
  • the connectivity between a CU-UP 172B and a DU 174 is established by the CU-CP 172 A using Bearer Context Management functions.
  • FIG. 2 illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with an eNB/ng-eNB or a gNB (e.g., one or more of the base stations 104, 106A, or 106B).
  • an eNB/ng-eNB or a gNB e.g., one or more of the base stations 104, 106A, or 106B.
  • a physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A.
  • the EUTRA RLC sublayer 206A in turn provides RLC channels to an EUTRA PDCP sublayer 208 and, in some cases, to a NR PDCP sublayer 210.
  • the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B.
  • the NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210.
  • the NR PDCP sublayer 210 in turn can provide data transfer services to an Ethernet protocol layer (not shown in Fig. 2), an Internet Protocol (IP) layer (not shown in Fig. 2), Service Data Adaptation Protocol (SDAP) 212 and/or a radio resource control (RRC) sublayer (not shown in Fig. 2).
  • the UE 102 in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2, to support handover between EUTRA and NR base stations and/or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.
  • the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”
  • IP Internet Protocol
  • PDUs protocol data units
  • the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide SRBs to exchange RRC messages or non-access-stratum (NAS) messages, for example.
  • the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide DRBs to support data exchange.
  • Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.
  • IP Internet Protocol
  • FIGs. 3A through 3H illustrate message sequences between the UE 102 and various base stations of the RAN 105 (including base stations 104, 106A, 106B), in which the UE 102 and the base stations operating in the system of Fig. 1 A manage IMS communications during a handover between the UE 102 and the RAN 105.
  • the UE 102 initially performs 302 a PDU Session Establishment procedure with the CN 110 (e.g., 5GC 160), via the RAN 105 (e.g., the base station (BS) 104 or another base station (e.g., the target BS 106A or a base station not shown in Fig. 1A)), to establish a PDU Session for a packet-based service such as IMS service(s).
  • the CN 110 e.g., 5GC 160
  • the RAN 105 e.g., the base station (BS) 104 or another base station (e.g., the target BS 106A or a base station not shown in Fig. 1A)
  • a packet-based service such as IMS service(s).
  • the UE 102 sends 302 a PDU Session Establishment Request message for establishing the PDU Session to the 5GC 160 (e.g., AMF 164 and/or SMF 166) and the 5GC 160 sends a PDU Session Establishment Accept message to the UE 102 via the RAN 105 in response.
  • the 5GC 160 e.g., AMF 164 and/or SMF 166
  • the UE 102 After establishing the PDU Session, the UE 102 performs 304 a registration procedure with the packet-based service network 170 via the RAN 105 and 5GC 160 to register to the network 170. In some embodiments, this may be an IMS registration procedure with an IMS network 170. In some implementations, the UE 102 sends 304 to the IMS network 170 via the RAN 105 and 5GC 160 a first SIP message (e.g., REGISTER message) to perform the IMS registration procedure. In response, the IMS network 170 sends 304 to the UE 102, via the RAN 105 and 5GC 160, a second SIP message (e.g., 200 OK) message to accept the registration.
  • a first SIP message e.g., REGISTER message
  • the UE 102 After successfully registering to the IMS network 170, the UE 102 initiates 306 a mobile originating (MO) IMS service with the IMS network 170 via the source BS 104 and 5GC 160 (e.g., UPF 162), or the IMS network 170 initiates 306 a mobile terminating (MT) service with the UE 102 via the source BS 104 and 5GC 160 (e.g., UPF 162).
  • the UE 102 sends 306 to the IMS network 170, via the source BS 104 and 5GC 160, a third SIP message (e.g., INVITE message) to initiate the MO IMS service.
  • a third SIP message e.g., INVITE message
  • the IMS network 170 can send a fourth SIP message (e.g., 100 TRYING message or 183 SESSION IN PROGRESS message) in response to the third SIP message.
  • the IMS network 170 can send 306 to the UE 102, via the source BS 104 and 5GC 160, a fifth SIP message (e.g., INVITE message) to initiate the MT IMS service.
  • the UE 102 can send a sixth SIP message (e.g., 100 TRYING message) in response to the fifth SIP message.
  • the IMS service can be one of IMS short message, IMS unstructured supplementary service data (USSD), IMS value added service data, IMS supplementary service data, IMS voice call, and IMS video call.
  • the source BS 104 prepares 308 a handover with the target BS 106A for the UE 102. More specifically, the source BS 104 sends a Handover Request message to the target BS 106 A to prepare the handover. In response to the Handover Request message, the target BS 106A can send 308 to the source BS 104 a Handover Request Acknowledge message including a handover command (e.g., RRCReconfiguration message). During the handover preparation 308 or before transmitting the handover command to the UE 102, the source BS 104 receives 310 from the 5GC 160 a PDU Session Resource Request message to request resources for the IMS service.
  • a handover Request Acknowledge message including a handover command (e.g., RRCReconfiguration message).
  • the source BS 104 can send 312 a PDU Session Resource Response message to the 5GC 160.
  • the source BS 104 determines to redirect the UE 102 to an EUTRA carrier frequency operated by the base station 106B for the IMS service. More specifically, upon receiving 310 the PDU Session Resource Request, the source BS 104 can determine that the UE 102 and/or the RAN 105 does not support the requested IMS service over the RAT of the target BS 106 A (in this case, NR).
  • the source BS 104 transmits 316 to the UE 102 an RRC release message (e.g., RRCRelease message) to redirect the UE 102 to an EUTRA carrier frequency operated by the base station 106B for the IMS service.
  • RRC release message e.g., RRCRelease message
  • the source BS 104 cancels 314 the handover in response to determining to redirect the UE 102 to an EUTRA carrier frequency operated by the second target BS 106B for the IMS service.
  • the setup of the IMS service is not be interrupted by the handover.
  • the source BS 104 transmits 318 a Handover Cancel message to the target BS 106A to cancel the handover. If the source BS 104 receives from the target BS 106A the Handover Request Acknowledge message including the handover command, the source BS 104 in other implementations, refrains from transmitting the handover command to the UE 102 or discards or ignores the handover command.
  • the source BS 104 initiates the handover preparation and has not yet transmitted the Handover Request message to the target BS 106A, the base station aborts the handover preparation.
  • the source BS 104 in some implementations can include an indication to indicate EPS fallback for the IMS service in the PDU Session Resource Response message 312.
  • the order of events 312, 314, 316 and 318 in Fig. 3A are an example implementation, and can be any order in different implementations.
  • the 5GC 160 can include a PDU Session identity of the PDU Session in the PDU Session Resource Request message and/or a quality of service (QoS) flow identity of a QoS flow for the IMS service.
  • the source BS 104 can determine that the PDU Session Resource Request message requests resources for the IMS service (i.e., for the PDU Session and/or QoS flow where the IMS service associates) in accordance with the PDU Session identity and/or QoS flow identity.
  • the PDU Session Resource Request message is a PDU Session Resource Setup Request message
  • the PDU Session Resource Response message is a PDU Session Resource Setup Response message or a PDU Session Resource Setup Reject message.
  • the PDU Session Resource Request message is a PDU Session Resource Modify Request message
  • the PDU Session Resource Response message is a PDU Session Resource Modify Response message or a PDU Session Resource Modify Reject message.
  • the UE 102 In response to or after receiving the RRC release message, the UE 102 enters 320 an idle state (e.g., RRC_IDLE). Then the UE 102 in the idle state selects a cell (e.g., cell 126B) on the EUTRA carrier frequency indicated by the RRC release message. After selecting the cell 126B, the UE 102 performs an RRC connection establishment procedure via the cell 126B with the second target BS 106B. The UE 102 transmits 326 an RRC connection request message (e.g., RRCConnectionRequest message) to the second target BS 106B via the cell 126B to perform the RRC connection establishment procedure.
  • RRC connection request message e.g., RRCConnectionRequest message
  • the second target BS 106B transmits an RRC connection setup message (e.g., RRCConnectionSetup message) to the UE 102 to configure an SRB (e.g., SRB1) via the cell 126B.
  • RRC connection setup message e.g., RRCConnectionSetup message
  • the UE 102 transmits an RRC connection complete message (e.g., RRCConnectionSetupComplete message) to the second target BS 106B via the cell 126B.
  • the UE 102 can perform 332 at least one NAS procedure with the CN 110 (e.g., the EPC 111) via the second target BS 106B and cell 126B.
  • the at least one NAS procedure includes, an Attach procedure, Tracking Area Update procedure, packet data network (PDN) connectivity procedure, service request procedure, authentication procedure and/or security mode control procedure as specified in 3GPP specification 24.301.
  • PDN packet data network
  • the UE 102 continues 334 the MO or MT IMS service initiation with the IMS network 170 via the second target BS 106B and CN 110.
  • the UE 102 exchanges plural SIP messages (e.g., REGISTER message, INVITE message, 200 OK message, PRACK message, 180 RINGING message, and/or ACK message) with the IMS network 170 via the second target BS 106B and CN 110 (e.g., MME 114).
  • SIP messages e.g., REGISTER message, INVITE message, 200 OK message, PRACK message, 180 RINGING message, and/or ACK message
  • the CN 110 can send 336 to the second target BS 106B a first CN-to-BS interface message (e.g., E-RAB Setup Request message) to request resources for the IMS service.
  • the IMS network 170 can send to the CN 110 an interface message which causes the CN 110 to send the first CN-to-BS interface message to the second target BS 106B.
  • the second target BS 106B transmits 338 to the UE 102 a first RRC connection reconfiguration message (e.g., RRCConnectionReconfiguration message) including a first DRB configuration for a first DRB.
  • the UE 102 transmits 340 a first RRC connection reconfiguration complete message (e.g., RRCConnectionReconfigurationComplete message) to the second target BS 106B.
  • the UE 102 communicates 342 IMS service packets with the IMS network 170 via the second target BS 106B and CN 110 (e.g., SGW 112 and/or PGW 116).
  • the UE 102 transmits 342 first plural IMS service packets on the first DRB with the second target BS 106B, which in turn transmits 342 the first plural IMS service packets to the CN 110. Then the CN 110 transmits 342 the first plural IMS service packets to the IMS network 170. Similarly, the IMS network 170 transmits 342 second plural IMS service packets to the CN 110 which in turn transmits 342 the second plural IMS service packets to the second target BS 106B. Then the second target BS 106B transmits 342 the second plural IMS service packets via the first DRB to the UE 102.
  • the CN 110 in some implementations can send to the second target BS 106B a second CN-to-BS interface message (e.g., E-RAB Setup Request message) to request resources for communicating SIP messages with the UE 102.
  • a second CN-to-BS interface message e.g., E-RAB Setup Request message
  • the second target BS 106B transmits to the UE 102 a second RRC connection reconfiguration message (e.g., RRCConnectionReconfiguration message) including a second DRB configuration for a second DRB.
  • the UE 102 transmits a second RRC connection reconfiguration message (e.g., RRCConnectionReconfigurationComplete message) to the second target BS 106B.
  • the UE 102 communicates the plural SIP messages with the second target BS 106B via the second DRB.
  • the base station can include a third DRB configuration for a third DRB in the second RRC connection reconfiguration message, and the UE 102 can communicate packets of non-IMS service(s) via the third DRB with the second target BS 106B, which communicates the packets with the CN 110 (e.g., SGW 112) or an edge server.
  • the non-IMS service(s) include web-browsing, YouTube, Gmail, WhatsApp, Line, File Transfer Protocol (FTP) application, web-TV, Android service or application, and/or iOS service or application.
  • FTP File Transfer Protocol
  • the non-IMS service(s) include a multicast and/or broadcast service (MBS).
  • the DRB configuration (z.e., the first DRB configuration, the second DRB configuration or the third DRB configuration) can be a DRB-ToAddMod information element (IE).
  • the first DRB configuration can include a first DRB identity and/or a first EPS bearer identity
  • the second DRB configuration can include a second DRB identity and/or a second EPS bearer identity
  • the third DRB configuration can include a third DRB identity and/or a third EPS bearer identity.
  • the source BS 104 and target BS 106A are gNBs and the second target BS 106B is an eNB or ng-eNB.
  • the source BS 104 can send to the UE 102 an RRC reconfiguration message (e.g., RRCReconfiguration message) including a fourth DRB configuration for a fourth DRB before event 306.
  • RRC reconfiguration message e.g., RRCReconfiguration message
  • a scenario 300B involves the CN 110 requesting the source BS 104 to allocate resources for an IMS service of the UE 102 while the source BS 104 is preparing or prepares a handover for the UE 102, similar to scenario 300A.
  • Events in this scenario similar to those discussed above are labeled with similar reference numbers. The differences between the scenarios of Fig. 3A and Fig. 3B are discussed below.
  • the source BS 104 instead of preparing a handover via a BS-to-BS interface (e.g., X2 or Xn interface) between the source BS 104 and target BS 106A, the source BS 104 prepares 309 a handover for the UE 102 via the CN 110 (e.g., AMF 164) to hand the UE 102 over to the target BS 106A. More specifically, the source BS 104 sends a Handover Required message to a CN 110 to initiate the handover preparation. After receiving the Handover Required message, the CN 110 sends a Handover Request message to the target BS 106A. The target BS 106A generates the handover command message upon receiving the Handover Request message from the CN 110.
  • the CN 110 e.g., AMF 164
  • the target BS 106A generates a Handover Request Acknowledge message which includes the handover command message described above, and sends the Handover Request Acknowledge message to the CN 110 in response to the Handover Request message received from the CN 110.
  • the CN 110 sends a Handover Command message (i.e., a CN-to-BS interface message) including the handover command to the source BS 104 in response to the Handover Required message.
  • the source BS 104 cancels 314 the handover in response to determining to redirect the UE 102 to an EUTRA carrier frequency operated by the second target BS 106B for the IMS service.
  • the setup of the IMS service would not be interrupted by the handover.
  • the source BS 104 transmits 319 a Handover Cancel message to the CN 110 (e.g., AMF 164) to cancel the handover instead of transmitting 318 the Handover Cancel message to the target BS 106A via a BS to BS interface (e.g., X2 or Xn interface).
  • the CN 110 can send a Handover Cancel Acknowledge message to the source BS 104.
  • the CN 110 can send a UE Context Release Command message to the target BS 106A to indicate the handover is canceled upon receiving the Handover Cancel message from the source BS 104.
  • the target BS 106A releases resources allocated for the UE 102 and may send a UE Context Release Complete message to the CN 110.
  • Fig. 3C illustrates a scenario 300C that involves the CN 110 requesting the source BS 104 to allocate resources for a packet-based service of the UE 102 while the source BS 104 is preparing or prepares a handover for the UE 102, similar to scenario 300A.
  • Events in this scenario similar to those discussed above are labeled with similar reference numbers. The differences between the scenarios of Fig. 3A and Fig. 3C are discussed below.
  • the RAN 105 facilitates the connection between the UE 102 and the second target BS 106B by preparing 321C a second handover procedure.
  • the source BS 104 prepares 321C a handover for the UE 102 via the CN 110 (e.g., AMF 164), to hand the UE 102 over to the second target BS 106B. More specifically, the source BS 104 sends a Handover Required message to a CN 110 to initiate the handover preparation. After receiving the Handover Required message, the CN 110 sends a Handover Request message to the second target BS 106B.
  • the CN 110 sends a Handover Request message to the second target BS 106B.
  • the second target BS 106B generates the handover command message upon receiving the Handover Request message from the CN 110. Then the target BS 106B generates a Handover Request Acknowledge message which includes the handover command message described above, and sends the Handover Request Acknowledge message to the CN 110 in response to the Handover Request message received from the CN 110.
  • the CN 110 sends a Handover Command message (i.e., a CN-to-BS interface message) including the handover command to the source BS 104 in response to the Handover Required message.
  • the 5GC 160 receives the Handover Required message and sends a Relocation Request message to the EPC 111 (e.g., MME 114) after receiving the Handover Required message.
  • the EPC 111 sends the Handover Request message to the second target BS 106B.
  • the second target BS 106B sends the Handover Request Acknowledge message to the EPC 111, which in turn sends a Relocation Response message including the handover command to the 5GC 160.
  • the 5GC 160 sends the Handover Command message to the source BS 104.
  • the source BS 104 transmits 322 the handover command message to the UE 102 to begin the handover process between the UE 102 and the second target BS 106B.
  • the UE 102 may transmit 324 an indication that the handover is complete to the second target BS 106B.
  • Fig. 3D illustrates a scenario 300D that involves the CN 110 requesting the source BS 104 to allocate resources for a packet-based service of the UE 102 while the source BS 104 is preparing or prepares a handover for the UE 102, similar to scenario 300C.
  • Events in this scenario similar to those discussed above are labeled with similar reference numbers. The differences between the scenarios of Fig. 3C and Fig. 3D are discussed below.
  • the source BS 104 instead of preparing a first handover via a BS-to-BS interface (e.g., X2 or Xn interface) between the source BS 104 and target BS 106A, the source BS 104 prepares 309 a handover for the UE 102 via the CN 110 (e.g., AMF 164) to hand the UE 102 over to the target BS 106A.
  • a BS-to-BS interface e.g., X2 or Xn interface
  • the source BS 104 cancels 314 the first handover in response to the decision to redirect the UE 102 to an EUTRA carrier frequency operated by the second target BS 106B for the packet-based service.
  • the setup of the packet-based service would not be interrupted by the first handover.
  • Fig. 3E illustrates a scenario 300E that involves the CN 110 requesting the source BS 104 to allocate resources for a packet-based service of the UE 102 while the source BS 104 is preparing or prepares a handover for the UE 102.
  • Scenario 300E differs from scenarios 300A-D in that the RAN 105 does not cancel the handover prepared at event 308, and the source BS 104 hands the UE 102 over to target BS 106A. Events in this scenario that are similar to those discussed above are labeled with similar reference numbers.
  • the source BS 104 transmits 342 a command to the UE 102 indicating that the UE 102 should begin the handover procedure.
  • the source BS 104 also transmits 313 a response to the request for resources to the CN 110 indicating that a handover has been triggered.
  • the RAN 105 receives 344 a notification indicating that the handover is complete from the UE 102 at target BS 106A.
  • the target BS 106A transmits 345 a message to the CN 110 indicating that the UE 102 is communicating with the target BS 106 A in response to receiving 344 the handover complete message.
  • the CN 110 transmits 346 a second request for resources for a packet-based service.
  • the request may repeat the request transmitted in step 310 or may be a new request.
  • the target BS 106A transmits 348 a response to the request for resources to the CN 110 in response to receiving 346 the second request for resources.
  • the target BS 106A transmits 317 to the UE 102 an RRC release message to redirect the UE 102 to an EUTRA carrier frequency operated by the second target BS 106B for the IMS service.
  • the message 345 can be an existing BS-to-CN interface message (e.g., NGAP message) which can implicitly or explicitly indicate that the UE 102 is communicating with the target BS 106A.
  • the NGAP message is a Path Switch Request message.
  • the CN 110 can send a Path Switch Request Acknowledge message in response to the Path Switch Request message.
  • the message 345 can be a new BS-to-CN interface message.
  • Fig. 3F illustrates a scenario 300F that involves the CN 110 requesting the source BS 104 to allocate resources for a packet-based service of the UE 102 while the source BS 104 is preparing or prepares a handover for the UE 102, similar to scenario 300E.
  • Events in this scenario similar to those discussed above are labeled with similar reference numbers. The differences between the scenarios of Fig. 3E and Fig. 3F are discussed below.
  • the source BS 104 instead of preparing a handover via a BS-to-BS interface between the source BS 104 and target BS 106A, the source BS 104 prepares 309 a handover for the UE 102 via the CN 110 to hand the UE 102 over to the target BS 106A. [0080] The source BS 104 transmits 342 a command to the UE 102 to begin the handover. Thus, the handover effectively interrupts the setup of the packet-based service, and the CN 110 must make 346 a new request for resources. In some implementations, the source BS 104 transmits 313 a message to the CN 110 indicating that the handover has been triggered.
  • the target BS 106A may transmit 345 a notification that the UE 102 is communicating with the target BS 106A to the CN 110.
  • the CN 110 transmits 346 a second request for resources to the target BS 106A in response to receiving 345 the notification.
  • Fig. 3G illustrates a scenario 300G that involves the CN 110 requesting the source BS 104 to allocate resources for a packet-based service of the UE 102 while the source BS 104 is preparing or prepares a handover for the UE 102, similar to scenario 300E.
  • Events in this scenario similar to those discussed above are labeled with similar reference numbers. The differences between the scenarios of Fig. 3E and Fig. 3G are discussed below.
  • the RAN 105 facilitates the connection between the UE 102 and the second target BS 106B by preparing 321 of a second handover procedure.
  • the target BS 106A prepares 321 a handover for the UE 102 via the CN 110 to hand the UE 102 over to the second target BS 106B.
  • the target BS 106 A transmits 323 a handover command message to the UE 102 to begin the handover of the UE 102 to the second target BS 106B.
  • the UE 102 may transmit 324 an indication that the handover is complete to the second target BS 106B.
  • Fig. 3H illustrates a scenario 300H that involves the CN 110 requesting the source BS 104 to allocate resources for a packet-based service of the UE 102 while the source BS 104 is preparing or prepares a handover for the UE 102, similar to scenario 300G.
  • Events in this scenario similar to those discussed above are labeled with similar reference numbers. The differences between the scenarios of Fig. 3G and Fig. 3H are discussed below.
  • the source BS 104 instead of preparing a first handover via a BS to BS interface between the source BS 104 and target BS 106A, the source BS 104 prepares 309 a handover for the UE 102 via the CN 110 (e.g., AMF 164) to hand the UE 102 over to the target BS 106A.
  • the source BS 104 transmits 342 a command to the UE 102 to begin the handover.
  • the handover interrupts the setup of the packet-based service, and the CN 110 requests 346 new resources.
  • the source BS 104 transmits 313 a message to the CN 110 indicating that the handover has been triggered.
  • the target BS 106A may transmit 345 a notification that the UE 102 is communicating with the target BS 106A to the CN 110.
  • the CN 110 transmits 346 a second request for resources to the target BS 106A in response to receiving 345 the notification.
  • Fig. 4 depicts a flow diagram of an example method 400 for continuing initiation of an IMS service, which can be implemented in one or more nodes of the RAN 105.
  • the RAN 105 communicates with a UE 102 via a first RAT (e.g. procedure 302 of Fig. 3A-D).
  • the RAN 105 prepares a handover from the first RAT for the UE 102 (e.g., procedure 308/309 in Figs. 3A-D).
  • the RAN 105 receives, at block 406, a message from the CN 110 requesting resources for a packet-based communication service (e.g., event 310 in the Figs. 3A-D).
  • the packet-based communication service is an IMS service.
  • the RAN 105 can receive the message during the preparation of the handover or before transmitting a command to begin the handover to the UE 102.
  • the RAN 105 transmits a message to the UE 102 at block 408 (e.g., event 316 of Figs. 3A&B).
  • the message is an indication to modify or setup radio resources such that the UE 102 moves to a carrier frequency of a second RAT.
  • the RAN 105 then cancels the handover (e.g., procedure 314 and event 318 of Figs. 3A-D).
  • Fig. 5 depicts a flow diagram of an example method 500 of continuing the handover procedure for Fig. 3E-H, in which the RAN 105 transmits a message to the CN 110 to indicate that the RAN 105 is unable to complete the request and transmits a message to the UE 102, including a command to perform the handover.
  • the RAN 105 communicates with a UE 102 (e.g. procedure 302 of Figs. 3E-H).
  • the UE 102 e.g. procedure 302 of Figs. 3E-H.
  • RAN 105 prepares a handover for the UE 102 (e.g., procedure 308/309 in the scenarios 300E- H).
  • the RAN then receives, at block 506, a message from the CN 110 requesting resources for a packet-based communication service (e.g., event 310 in the Figs. 3E-H).
  • the message may arrive during the preparation of the handover or before the RAN 105 transmits a command to begin the handover to the UE 102.
  • the request may be to setup, modify, release, or otherwise reallocate resources.
  • the RAN 105 transmits a message to the CN 110 at block 508 (e.g. , event 313 in the Figs. 3E-H).
  • the message is an indication that the RAN 105 is unable to complete the request for resources.
  • the RAN 105 then transmits a command to the UE 102 to initiate the handover at block 510 (e.g. , event 342 of Figs. 3E-H).
  • Fig. 6 depicts a flow diagram of an example method 600 for determining whether the UE should move to another carrier frequency.
  • the RAN 105 communicates with a UE 102 via a first RAT (e.g. procedure 302 of Figs. 3A-H).
  • the RAN 105 prepares a handover for the UE 102 (e.g., procedure 308/309 in Figs. 3A-H).
  • the RAN 105 receives, at block 606, a message from the CN 110 requesting resources (e.g., event 310 in Figs. 3A-H). The message may arrive during the preparation of the handover or before transmitting a command to begin the handover, to the UE 102.
  • the RAN 105 determines whether it should cancel the handover. In some implementations, the RAN 105 makes this determination based on whether the message received in block 606 requests resources for an IMS service. In other implementations, the RAN 105 makes this determination based on whether the message is for a quality of service (QoS) flow with a certain QoS Class Indicator (QCI). If the RAN 105 determines affirmatively at block 608, then the RAN 105 cancels the handover at block 610 (e.g., procedure 314 and event 318 of Figs. 3A-D). To this end, the RAN 105 can implement the actions of block 408 of Fig. 4 (e.g. , event 316 of Figs.
  • QoS quality of service
  • QCI QoS Class Indicator
  • the RAN 105 determines negatively at block 608, however, then the RAN 105 performs the handover at block 612 as described in blocks 508 and 510 in Fig. 5 (e.g., events 313 and 342 of Fig. 3E-H).
  • Fig. 7 depicts a flow diagram of another example method 700 in which the RAN 105 determines whether it should move the UE to another carrier frequency.
  • a RAN 105 communicates with a UE 102 via a first RAT (e.g. procedure 302 of Figs. 3A-H).
  • the RAN 105 prepares a handover for the UE 102 (e.g., procedure 308/309 of Figs. 3A-H).
  • the RAN 105 receives, at block 706, a message from the CN 110 requesting resources (e.g. event 310 of Figs. 3A-H).
  • the message may arrive during the preparation of the handover or before transmitting a command to begin the handover to the UE 102.
  • the message may be for an IMS service, a QoS flow with a particular QCI, or some combination thereof.
  • the RAN 105 determines whether it should cancel the handover. The RAN 105 makes this determination based on whether the UE 102 supports the request for resources. Similar to block 608, the RAN 105 may make the determination based on whether the UE 102 supports an IMS service, a QoS flow with a particular QCI, or both of these factors. If the UE 102 does support the request for resources, then the RAN 105 performs the handover at block 710 as described in blocks 508 and 510 in Fig. 5 (e.g., events 313 and 342 of Fig. 3E-H).
  • the RAN 105 instead cancels the handover as described in block 408 of Fig. 4 (e.g., procedure 314 and event 318 of Figs. 3A-D, event 316 of Figs. 3A&B).
  • Fig. 8 depicts a flow diagram of an example method 800 in which the RAN 105 receives a request for resources during the preparation of a handover procedure and determines whether it should cancel the handover based on whether the latest measurement result related to the UE is below a threshold.
  • a RAN 105 communicates with a UE 102 via a first RAT (e.g. procedure 302 of Figs. 3A-H).
  • the RAN 105 prepares a handover for the UE 102 (e.g., procedure 308/309 of Figs. 3A-H).
  • the RAN 105 receives, at block 806, a message from the CN 110 requesting resources (e.g. event 310 of Figs. 3A-H). The message may arrive during the preparation of the handover or before transmitting a command to begin the handover to the UE 102.
  • the RAN 105 determines whether it should cancel the handover.
  • the RAN 105 makes this determination based on whether a measurement result related to the UE 102 is below a threshold.
  • the UE 102 in some cases generates a measurement result of downlink signal quality, signal strength, etc. and reports the measurement result to the RAN 105.
  • a network node of the RAN 105 generates a measurement result of uplink signals.
  • a measurement result below a certain threshold may indicate that the UE 102 is moving out of range of the network node, and the handover is sufficiently urgent to take priority over other procedures.
  • the RAN performs the handover at block 810 as described in blocks 508 and 510 in Fig. 5 (e.g. events 313 and 342 of Figs. 3A-H). If the measurement is at or above the threshold, however, the RAN 105 instead cancels the handover at block 812 and continues on to block 814 (e.g., procedure 314 and event 318 of Figs. 3A-D, procedure 408 of Fig. 4).
  • the RAN 105 transmits a message to the UE 102 (e.g., event 316 of Fig. 3A&B, procedure 408 of Fig. 4).
  • the message indicates that the UE 102 should move to a carrier frequency of a second RAT.
  • the message indicates that the UE 102 should configure radio resources.
  • Fig. 9 depicts a flow diagram of an example method 900 in which the CN 110 sends a first message to a first BS 106A before receiving a response that indicates a handover has been triggered.
  • the CN 110 communicates with the UE 102 through the source BS 104 (e.g. procedure 302 of Figs. 3E-H).
  • the CN 110 transmits a message requesting radio resources for the UE 102 to the source BS 104 (e.g. event 310 of Figs. 3E-H).
  • the CN 110 receives, at block 906, an indication that a handover has been triggered from the first source BS 104 (e.g.
  • the CN 110 In response to receiving the message, the CN 110, at block 908, transmits a second message requesting radio resources for the UE 102 to a second target BS 106 A or 106B of the RAN 105 (e.g. event 346 of Figs. 3E-H). The CN 110 can transmit the same message at blocks 904 and 908. At block 910, the CN 110 receives a message from the base station in response to the message sent in block 908 (e.g. event 348 of Figs. 3E-H).
  • Fig. 10 depicts a flow diagram of an example method 1000 in which a CU 172 communicates with a UE 102 via a first DU 174-1, and prepares and executes a handover to a second DU 174-2.
  • a CU 172 communicates with a UE 102 via a first DU 174-1 (e.g. procedure 302 of Figs. 3E-H).
  • the CU 172 prepares a handover to a second DU 174-2 for the UE 102 (e.g. procedure 308/309 of Figs. 3E-H).
  • the CU 172 then receives, at block 1006, a message from the CN 110 requesting resources (e.g. event 310 of Figs. 3E-H).
  • the message can include a request for setup, modification, release, or other reallocation of radio resources.
  • the message may arrive during the preparation of the handover or before transmitting a command to begin the handover to the UE 102.
  • the CU 172 transmits a command to begin handover to the UE 102 via the first DU 174-1 at block 1008 (e.g. event 342 of Figs. 3E-H).
  • the CU 172 After determining that the UE 102 hands over to the second DU 174-2, the CU 172 then transmits, via the second DU 174-2 and at block 1010, a message to the UE 102 (e.g. event 317 of Figs. 3E&F).
  • the message can instruct the UE 102 to setup, modify, release, or otherwise reallocate radio resources.
  • Fig. 11 depicts a flow diagram of an example method 1100 in which a CU 172 communicates with a UE 102 via a first DU 174-1, and prepares a handover to a second DU 174-2 before cancelling the handover in response to a request for resources.
  • a CU 172 communicates with a UE 102 via a first DU 174-1 (e.g. procedure 302 of Figs. 3A-D).
  • the CU 172 prepares a handover to a second DU 174-2 for the UE 102 (e.g. procedure 308/309 of Figs. 3A-D).
  • the CU 172 then receives, at block 1106, a message from the CN 110 requesting resources (e.g. event 310 of Figs. 3A-D).
  • the message can request setup, modification, release, or other reallocation of radio resources.
  • the message may arrive during the preparation of the handover or before actually transmitting a command to begin the handover to the UE 102.
  • the CU 172 cancels the handover with the second DU 174-2 at block 1108 (e.g. procedure 314 of Figs. 3A-D).
  • the CU 172 transmits a message to the UE 102 via the first DU 174-1 (e.g. event 316 of Figs. 3A&B).
  • the message can include an instruction to setup, modify, release, or otherwise reallocate radio resources.
  • Fig. 12 depicts a flow diagram of an example method 1200 in which a CU 172 communicates with a UE 102 via a first DU 174-1, and prepares a handover to a second DU 174-2 before deciding whether to cancel the handover.
  • a CU 172 communicates with a UE 102 via a first DU 174-1 (e.g. procedure 302 of Figs. 3A-H).
  • the CU 172 prepares a handover for the UE 102 (e.g. procedure 308/309 of Figs. 3A-H).
  • the CU 172 then receives, at block 1206, a message requesting resources from the CN 110 (e.g. event 310 of Figs. 3A-H). The message may arrive during the preparation of the handover or before actually transmitting a command to begin the handover to the UE 102. [0101]
  • the CU 172 determines whether it should cancel the handover. The CU 172 can make this determination based on whether the message received at block 1206 requests resources for an IMS service. In other cases, the CU 172 makes this determination based on whether the message is for a QoS flow with a particular QCI. If the CU 172 determines affirmatively at block 1208, then the CU 172 cancels the handover at block 1210 (e.g.
  • procedure 314 of Figs. 3A-D the CU 172 does so through the same method as shown in blocks 1108 and 1110 of Fig. 11 (e.g. procedure 314 of Figs. 3A-D, event 316 of Figs. 3A&B). If the CU 172 determines negatively at block 1208, however, then the CU 172 performs the handover at block 1212 as described in blocks 1008 and 1010 in Fig. 10 (e.g. event 342 of Figs. 3E-H, event 317 of Figs. 3E&F).
  • Fig. 13 depicts a flow diagram of an example method 1300 in which a CU 172 communicates with a UE 102 via a first DU 174-1 and prepares a handover to a second DU 174-2 before deciding whether to cancel the handover.
  • a CU 172 communicates with a UE 102 via a first DU 174-1 (e.g. procedure 302 of Figs. 3A-H).
  • the CU 172 prepares a handover for the UE 102 (e.g. procedure 308/309 of Figs. 3A-H).
  • the CU 172 receives, at block 1306, a message from the CN 110 requesting resources (e.g.
  • the message may arrive during the preparation of the handover or before transmitting a command to begin the handover to the UE 102.
  • the message may be for an IMS service, a QoS flow with a QCI, or some combination thereof.
  • the CU 172 determines whether it should cancel the handover. The CU 172 makes this determination based on whether the UE 102 supports the request for resources. Much like block 708, depending on the embodiment, the CU 172 may make the determination based on whether the UE 102 supports an IMS service, a QoS flow with a particular QCI, or some combination thereof. If the UE 102 does support the request for resources, then the CU 172 performs the handover at block 1310 as described in blocks 1008 and 1010 in Fig. 10 (e.g. event 342 of Figs. 3E-H, event 317 of Figs. 3E&F).
  • Fig. 14 depicts a flow diagram of an example method 1400 in which a CU 172 communicates with a UE 102 via a first DU 174-1 and prepares a handover to a second DU 174-2 before deciding whether to cancel the handover.
  • a CU 172 communicates with a UE 102 via a first DU 174-1 (e.g. procedure 302 of Figs. 3A-H).
  • the CU 172 prepares a handover for the UE 102 (e.g. procedure 308/309 of Figs. 3A-H).
  • the CU 172 then receives, at block 1406, a message from the CN 110 requesting resources (e.g. event 310 of Figs. 3A-H).
  • the message may arrive during the preparation of the handover or before transmitting a command to begin the handover to the UE 102.
  • the CU 172 determines whether it should cancel the handover. The CU 172 makes this determination based on whether a measurement result related to the UE 102 is below a threshold. If the measurement result is below a threshold, then the CU 172 performs the handover at block 1410 as described in blocks 1008 and 1010 in Fig. 10 (e.g. event 342 of Figs. 3E-H, event 317 of Figs. 3E&F). If the measurement result is at or above the threshold, however, then the CU 172 instead cancels the handover at block 1412 and continues on to block 1414 (e.g. procedure 314 of Figs. 3A-D, procedure 1108 of Fig. 11).
  • a measurement result related to the UE 102 is below a threshold. If the measurement result is below a threshold, then the CU 172 performs the handover at block 1410 as described in blocks 1008 and 1010 in Fig. 10 (e.g. event 342 of Figs. 3E-H, event
  • the CU 172 transmits a message to the UE 102 (e.g. event 316 of Figs. 3A&B, procedure 1110 of Fig. 11).
  • the message can indicate that the UE 102 should move to a carrier frequency of a second RAT.
  • the message in some cases can indicate that the UE 102 should configure radio resources.
  • Fig. 15 depicts an example method 1500 for processing a packet-based call during a handover of a UE 102, which can be implemented in a suitable RAN 105.
  • the RAN 105 performs an initiation procedure for a session of a packet-based service, the initiation procedure including an exchange of one or more messages between the UE and a packet-based service network via a source node of the RAN 105 (e.g. procedure 306 of Figs. 3A-H).
  • a source node of the RAN 105 e.g. procedure 306 of Figs. 3A-H.
  • the RAN 105 performs at block 1504 a handover preparation procedure for handing the UE 102 over to a target node of the RAN 105 (such as target BS 106A) (e.g. procedure 308/309 of Figs. 3A-H, procedure 404 of Fig. 4, procedure 504 of Fig. 5, procedure 604 of Fig. 6, procedure 704 of Fig. 7, procedure 804 of Fig. 8, procedure 1004 of Fig. 10, procedure 1104 of Fig. 11, procedure 1204 of Fig. 12, procedure 1304 of Fig. 13, procedure 1404 of Fig. 14).
  • a target node of the RAN 105 such as target BS 106A
  • the RAN 105 After performing the handover preparation procedure and at block 1506, the RAN 105 receives a request for resources for the session from the CN (e.g., event 310 of Figs. 3A-H, procedure 406 of Fig. 4, procedure 506 of Fig. 5, procedure 606 of Fig. 6, procedure 706 of Fig. 7, procedure 806 of Fig. 8, procedure 1006 of Fig. 10, procedure 1106 of Fig. 11, procedure 1206 of Fig. 12, procedure 1306 of Fig. 13, procedure 1406 of Fig. 14).
  • the RAN 105 continues the initiation procedure (e.g., procedure 334 of Figs. 3A-H).
  • Fig. 16 an example method for processing a packet-based call during a handover of a UE 102, which can be implemented in a suitable CN 110.
  • the CN 110 facilitates an initiation procedure for a session of a packet-based service, the initiation procedure including an exchange of one or more messages between the UE 102 and a packet-based service network via the source node (such as source BS 104) and the CN 110 (e.g., event 306 of Figs. 3E-H).
  • the CN 110 transmits to the source node a first request for resources for the session (e.g. , event 310 of Figs. 3E-H, procedure 904 of Fig. 9).
  • the CN 110 After transmitting the first request, the CN 110 receives, from the source node and at block 1606, a response for the first request, the response including an indication that a handover of the UE 102 from the source node has been triggered (e.g., event 313 of Figs. 3E- H, procedure 906 of Fig. 9).
  • the CN 110 transmits a second request for resources for the session to the target node (e.g., event 346 of Figs. 3E-H, procedure 908 of Fig. 9).
  • Example 1 A method in a radio access network (RAN) for managing a packetbased call during a handover of a UE, the method comprising: performing, by processing hardware, an initiation procedure for a session of a packet-based service, the initiation procedure including an exchange of one or more messages between the UE and a packetbased service network via a source node of the RAN; prior to completion of the initiation procedure, performing a handover preparation procedure for handing the UE over to a target node of the RAN; receiving, by the processing hardware from a core network (CN) and after the handover preparation procedure, a request for resources for the session; and continuing, by the processing hardware, the initiation procedure after receiving the request for resources.
  • Example 2. The method of example 1, wherein the continuing includes: cancelling a handover corresponding to the handover preparation procedure; and establishing a new radio connection between the UE and a second target node of the RAN.
  • Example 3 The method of example 2, wherein establishing the new radio connection includes: transmitting, to the UE, a command to release an existing radio connection between the UE and the source node, to cause the UE to move to the second target node.
  • Example 4 The method of either of examples 2 or 3, wherein the cancelling includes: transmitting, from the source node to the target node, an indication that the handover is cancelled.
  • Example 5 The method of either of examples 2 or 3, wherein the cancelling includes: transmitting, from the source node to the CN, an indication that the handover is cancelled.
  • Example 6 The method of any of examples 2-6, wherein the cancelling includes: determining, by the processing hardware at the source node, that the packet-based service is not supported over a radio access technology (RAT) of the target node.
  • RAT radio access technology
  • Example 7 The method of any of examples 2-6, wherein the cancelling includes: determining that the request for resources pertains to (i) an Internet Protocol (IP) Multimedia Subsystem (IMS) or (ii) a flow with a quality of service (QoS) Class Identifier (QCI) corresponding to voice.
  • IP Internet Protocol
  • IMS Internet Multimedia Subsystem
  • QoS quality of service
  • QCI Class Identifier
  • Example 8 The method of any of examples 2-6, wherein the cancelling further includes: determining, by the processing hardware, that a signal strength measurement for a latest uplink transmission from the UE is at or above a certain threshold.
  • Example 9 The method of example 1, wherein the continuing includes: receiving, at the target node from the CN, a second request for resources for the packet-based service network; and transmitting, from the target node to the CN, a response to the second request for resources.
  • Example 10 The method of example 9, wherein the continuing includes: receiving, at the target node from the UE, an indication that the handover is complete; and determining, based on the indication that the handover is complete, that a radio connection between the UE and the target node has been established.
  • Example 11 The method of example 9 or 10, wherein: the target node is a first target node; the method further comprising: establishing a new radio connection between the UE and a second target node of the RAN.
  • Example 12 The method of any of examples 2-8 or 11, wherein establishing the new radio connection includes: receiving, at the second target node from the UE, a request to establish a radio connection, the request conforming to a protocol for controlling radio resources.
  • Example 13 The method of any of examples 2-8 or 11, wherein establishing the new radio connection includes: performing, by the processing hardware, a second handover preparation procedure for a handover of the UE to the second target node.
  • Example 14 The method of example 13, wherein the second handover preparation procedure involves the source node and the CN.
  • Example 15 The method of example 13, wherein the second handover preparation procedure involves the first target node and the CN.
  • Example 16 The method of any of examples 2-8 or 11, further comprising, subsequently to continuing the initiation procedure: receiving, at the second target node from the CN, an interface message including a request for resources for the session.
  • Example 17 The method of example 16, further comprising: transmitting, from the second target node to the UE and in response to the interface message, a message including a configuration of data radio bearer for the session.
  • Example 18 The method of any of the preceding examples, wherein the source node and the target node are implemented in different respective base stations.
  • Example 19 The method of any examples 1-17, wherein the source node and the target node are implemented in different distributed units (DU) of a distributed base station.
  • DU distributed units
  • Example 20 A radio access network (RAN) comprising processing hardware and configured to implement a method according to any of the preceding examples.
  • Example 21 A method in a core network (CN) for processing a packet-based call during a handover of a UE from a source node of a radio access network (RAN), the method comprising: facilitating, by processing hardware, an initiation procedure for a session of a packet-based service, the initiation procedure including an exchange of one or more messages between the UE and a packet-based service network via the source node and the CN; transmitting, by the processing hardware to the source node, a first request for resources for the session; receiving, by the processing hardware from the source node, a response for the first request, the response including an indication that a handover of the UE from the source node has been triggered; and transmitting, by the processing hardware to the target node, a second request for resources for the session.
  • CN core network
  • Example 22 The method of example 21, further comprising: receiving, from the target node after receiving the response and prior to transmitting the second request, a message specifying an identity of the target node.
  • Example 23 The method of example 21 or 22, further comprising: receiving, by the processing hardware from the target node, a second response to the second request.
  • Example 24 The method of any of examples 21-23, further comprising: continuing, by the processing hardware, the initiating procedure subsequently to receiving the second response.
  • Example 25 The method of any of examples 21-24, further comprising: facilitating, by the processing hardware, a handover preparation procedure for handing the UE over to the target node.
  • Example 26 The method of any of examples 21-25, further comprising: facilitating, by the processing hardware, a handover preparation for handing the UE over to a second target node.
  • Example 27 A core network (CN) comprising processing hardware and configured to implement a method according to any of the preceding examples.
  • a user device in which the techniques of this disclosure can be implemented can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media- streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router.
  • the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS).
  • ADAS advanced driver assistance system
  • the user device can operate as an intemet-of-things (loT) device or a mobile-internet device (MID).
  • the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.
  • Modules may can be software modules (e.g., code, or machine- readable instructions stored on non-transitory machine-readable medium) or hardware modules.
  • a hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner.
  • a hardware module can include dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP)) to perform certain operations.
  • FPGA field programmable gate array
  • ASIC application-specific integrated circuit
  • DSP digital signal processor
  • a hardware module may also include programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations.
  • programmable logic or circuitry e.g., as encompassed within a general-purpose processor or other programmable processor
  • the decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
  • the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc.
  • the software can be executed by one or more general-purpose processors or one or more special-purpose processors.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un réseau d'accès radio (RAN) qui peut mettre en œuvre un procédé dans un réseau d'accès radio (RAN) pour gérer un appel à base de paquets pendant un transfert intercellulaire d'un UE. Ce procédé comprend l'exécution d'une procédure d'initiation pour une session d'un service à base de paquets, la procédure d'initiation comprenant un échange d'un ou de plusieurs messages entre l'UE et un réseau de service à base de paquets par l'intermédiaire d'un nœud source du RAN (1502). Le procédé comprend en outre l'exécution d'une procédure de préparation de transfert intercellulaire pour transférer l'UE sur un nœud cible du RAN avant l'achèvement de la procédure d'initiation (1504). Le procédé peut également consister à recevoir, en provenance d'un réseau central (CN) et après la procédure de préparation de transfert intercellulaire, une demande de ressources pour la session (1506). Le procédé peut ensuite continuer la procédure d'initiation après la réception de la demande de ressources (1508).
PCT/US2022/011996 2021-01-14 2022-01-11 Gestion de connexions de réseau à base de paquets pendant un transfert intercellulaire WO2022155139A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163137384P 2021-01-14 2021-01-14
US63/137,384 2021-01-14

Publications (1)

Publication Number Publication Date
WO2022155139A1 true WO2022155139A1 (fr) 2022-07-21

Family

ID=80123240

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2022/011996 WO2022155139A1 (fr) 2021-01-14 2022-01-11 Gestion de connexions de réseau à base de paquets pendant un transfert intercellulaire

Country Status (1)

Country Link
WO (1) WO2022155139A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024063963A1 (fr) * 2022-09-19 2024-03-28 Qualcomm Incorporated Techniques de mobilité d'état connecté dans un système sans fil basé sur un service

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019097498A1 (fr) * 2017-11-20 2019-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et appareil de transfert ou de redirection
US20210007030A1 (en) * 2019-07-03 2021-01-07 Mediatek Inc. Modem and Application Interaction for Voice Calls
WO2021104263A1 (fr) * 2019-11-25 2021-06-03 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil de transfert intercellulaire

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019097498A1 (fr) * 2017-11-20 2019-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Procédés et appareil de transfert ou de redirection
US20210007030A1 (en) * 2019-07-03 2021-01-07 Mediatek Inc. Modem and Application Interaction for Voice Calls
WO2021104263A1 (fr) * 2019-11-25 2021-06-03 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil de transfert intercellulaire

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"3 rd Generation Partnership Project; Technical Specification Group Radio Access Network; NG-RAN; NG Application Protocol (NGAP) (Release 15)", 4 January 2021 (2021-01-04), XP051967495, Retrieved from the Internet <URL:https://ftp.3gpp.org/3guInternal/3GPP_ultimate_versions_to_be_transposed/sentToDpc/38413-fa0.zip 38413-fa0.doc> [retrieved on 20210104] *
3GPP SPECIFICATION 24.301
3GPP SPECIFICATION TS 36.323
3GPP SPECIFICATION TS 38.323
ERICSSON ET AL: "EPS Fallback for voice", vol. SA WG2, no. Montreal, Canada; 20180226 - 20180302, 20 February 2018 (2018-02-20), XP051408254, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fsa/WG2%5FArch/TSGS2%5F126%5FMontreal/Docs/> [retrieved on 20180220] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024063963A1 (fr) * 2022-09-19 2024-03-28 Qualcomm Incorporated Techniques de mobilité d'état connecté dans un système sans fil basé sur un service

Similar Documents

Publication Publication Date Title
US20220386191A1 (en) Conditional full configuration and conditional delta configuration
US20220279412A1 (en) Conditional handover management
CN114600503B (zh) 通过辅节点改变的快速主小区组故障恢复
EP3981217A1 (fr) Fonctionnement de pile de protocoles à double action pour transfert et changement de pscell
WO2020198723A1 (fr) Transfert intercellulaire lors d&#39;une défaillance de groupe de cellules secondaires
EP4039056A1 (fr) Opérations de noeud secondaire conditionnel
US20230403623A1 (en) Managing sidelink information, configuration, and communication
US20230397233A1 (en) Managing transmission and receiption of multicast and broadcast services
US20230049140A1 (en) Managing a conditional configuration upon addition or release of a bearer
WO2022155139A1 (fr) Gestion de connexions de réseau à base de paquets pendant un transfert intercellulaire
WO2023133265A1 (fr) Gestion de communication de nœud maître dans une connectivité double et une connectivité non double
US20230284314A1 (en) Managing Packet-Based Multimedia Network Connections During Master Cell Group Failure
US20230276468A1 (en) Managing unicast, multicast and broadcast communication
US20230224772A1 (en) Managing communication during mcg failure
EP4046423A1 (fr) Opérations conditionnelles avec une connexion radio suspendue
US20240306050A1 (en) Managing radio resources and downlink transmission during handover
WO2024173684A1 (fr) Gestion d&#39;activation sélective pour ajout ou changement conditionnel de pscell dans une station de base désagrégée
EP4402962A1 (fr) Activation d&#39;occasion de radiomessagerie d&#39;un état de veille pour l&#39;état inactif
KR20240132289A (ko) 조건부 준비 절차를 위한 후보 셀 구성 관리
WO2024155968A1 (fr) Gestion de changements de cellule conditionnels continus et configurations associées
WO2023014873A1 (fr) Gestion d&#39;information de coordination multi-connectivité pour des procédures de noeud secondaire conditionnel
WO2023014872A1 (fr) Gestion de configurations pour ajout et changement conditionnels de noeud secondaire
WO2023133241A1 (fr) Gestion de configurations de cellules candidates pour des procédures de préparation conditionnelle
WO2024155970A1 (fr) Activation de changements conditionnels en continu de cellules
EP4371371A1 (fr) Gestion de radiomessagerie pour différents services

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: 22701826

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: 22701826

Country of ref document: EP

Kind code of ref document: A1