Communication system
The communication system addresses the challenge of detecting network failures in multi-network connections by using an anchor network to monitor communication quality and detect failures, ensuring reliable communication and network availability.
Patent Information
- Application Number
- PCT/JP2024/038395
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-11-01
- Filing Date
- 2024-10-28
- Publication Date
- 2025-05-08
AI Technical Summary
Current communication systems fail to detect network failures when a user equipment (UE) is connected to multiple networks simultaneously, leading to reliability issues and reduced availability of communication networks.
The proposed communication system includes an anchor network that detects failures in non-anchor networks by acquiring communication quality information and implementing Quality of Service (QoS) monitoring, allowing for simultaneous connection of a UE to multiple networks while ensuring network reliability.
This solution enables effective detection of network failures, ensuring reliable communication and maintaining network availability even when a UE is connected to multiple networks simultaneously.
Smart Images

Figure JP2024038395_08052025_PF_FP_ABST
Abstract
Description
communication systems
[0001] The present disclosure relates to wireless communication technology.
[0002] The 3rd Generation Partnership Project (3GPP), a standardization organization for mobile communication systems, is considering a fifth-generation (hereinafter sometimes referred to as "5G") wireless access system as a successor to Long Term Evolution (LTE) and Long Term Evolution Advanced (LTE-A), one of the fourth-generation wireless access systems (see Non-Patent Document 1) (for example, Non-Patent Document 2). The technology for the wireless section of 5G is called "New Radio Access Technology" ("New Radio" is abbreviated as "NR"). The NR system is being studied based on the LTE system and the LTE-A system.
[0003] For example, in Europe, an organization called METIS has compiled 5G requirements (see Non-Patent Document 3). The requirements for a 5G wireless access system are that it must have 1000 times the system capacity, 100 times the data transmission speed, one-fifth the data processing delay, and 100 times the number of simultaneous connections of communication terminals compared to an LTE system, while also achieving further reductions in power consumption and cost reductions for the equipment (see Non-Patent Document 3).
[0004] In order to meet such demands, 3GPP is currently studying 5G standards (see Non-Patent Documents 4 to 23).
[0005] The NR access method uses OFDM (Orthogonal Frequency Division Multiplexing) in the downlink direction and OFDM and DFT-s-OFDM (Discrete Fourier Transform-spread-OFDM) in the uplink direction. Also, like LTE and LTE-A, the 5G system does not include circuit switching and is only a packet communication method.
[0006] NR allows the use of higher frequencies than LTE in order to improve transmission speeds and reduce processing delays.
[0007] In NR, which may use higher frequencies than LTE, cell coverage is ensured by forming a narrow beam-shaped transmission and reception range (beam forming) and changing the direction of the beam (beam sweeping).
[0008] The decisions made by 3GPP regarding the frame structure in an NR system, as described in Non-Patent Document 1 (Chapter 5), are explained using Figure 1. Figure 1 is an explanatory diagram showing the structure of a radio frame used in an NR communication system. In Figure 1, one radio frame is 10 ms. The radio frame is divided into 10 equally sized subframes. The NR frame structure supports one or more numerologies, i.e., one or more subcarrier spacings (SCSs). In NR, one subframe is 1 ms long, and one slot consists of 14 symbols, regardless of the subcarrier spacing. Furthermore, the number of slots included in one subframe is one when the subcarrier spacing is 15 kHz, and the number of slots at other subcarrier spacings increases in proportion to the subcarrier spacing (see Non-Patent Document 11 (3GPP TS38.211)).
[0009] 3GPP's decisions regarding channel configuration in NR systems are described in Non-Patent Document 2 (Chapter 5) and Non-Patent Document 11.
[0010] A physical broadcast channel (PBCH) is a channel for downlink transmission from a base station device (hereinafter sometimes simply referred to as a "base station") to a communication terminal device (hereinafter sometimes referred to as a "communication terminal" or "terminal") such as a mobile terminal device (hereinafter sometimes simply referred to as a "mobile terminal"). The PBCH is transmitted together with a downlink synchronization signal.
[0011] Downlink synchronization signals in NR include a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS). Synchronization signals are transmitted from base stations as synchronization signal bursts (hereinafter sometimes referred to as SS bursts) at predetermined intervals and for a predetermined duration. SS bursts are composed of synchronization signal blocks (hereinafter sometimes referred to as SS blocks) for each beam of the base station.
[0012] The base station transmits the SS block of each beam by changing the beam during the duration of the SS burst. The SS block consists of the P-SS, S-SS, and PBCH.
[0013] The Physical Downlink Control Channel (PDCCH) is a channel for downlink transmission from a base station to a communication terminal. The PDCCH carries downlink control information (DCI). The DCI includes resource allocation information for a Downlink Shared Channel (DL-SCH), which is one of the transport channels described below, resource allocation information for a Paging Channel (PCH), which is one of the transport channels described below, and Hybrid Automatic Repeat reQuest (HARQ) information related to the DL-SCH. The DCI may also include an uplink scheduling grant. The DCI may also include an acknowledgement (Ack) / negative acknowledgement (Nack), which is a response signal to the uplink transmission. In addition, in order to flexibly switch between DL and UL within a slot, the DCI may include a slot format indication (SFI). The PDCCH or the DCI is also called an L1 / L2 control signal.
[0014] In NR, a time-frequency region that is a candidate for including a PDCCH is provided. This region is called a control resource set (CORESET). A communication terminal monitors the CORESET and acquires a PDCCH.
[0015] The Physical Downlink Shared Channel (PDSCH) is a channel for downlink transmission from a base station to a communication terminal. The Downlink Shared Channel (DL-SCH), which is a transport channel, and the PCH, which is a transport channel, are mapped to the PDSCH.
[0016] The Physical Uplink Control Channel (PUCCH) is a channel for uplink transmission from a communication terminal to a base station. The PUCCH carries uplink control information (UCI). The UCI includes Ack / Nack, which is a response signal to a downlink transmission, CSI (Channel State Information), a scheduling request (SR), and the like. The CSI is composed of a Rank Indicator (RI), a Precoding Matrix Indicator (PMI), and a CQI (Channel Quality Indicator) report. The RI is rank information of a channel matrix in MIMO (Multiple Input Multiple Output). The PMI is information on a precoding weight matrix used in MIMO. The CQI is quality information indicating the quality of received data or the quality of a communication path. The UCI may be carried by the PUSCH, which will be described later. The PUCCH or UCI is also called an L1 / L2 control signal.
[0017] The Physical Uplink Shared Channel (PUSCH) is a channel for uplink transmission from a communication terminal to a base station. The Uplink Shared Channel (UL-SCH), which is one of the transport channels, is mapped to the PUSCH.
[0018] A physical random access channel (PRACH) is a channel for uplink transmission from a communication terminal to a base station. The PRACH carries a random access preamble.
[0019] A downlink reference signal (RS) is a known symbol in an NR communication system. The following four types of downlink reference signals are defined: a demodulation reference signal (DM-RS), which is a UE-specific reference signal, a phase tracking reference signal (PT-RS), a positioning reference signal (PRS), and a channel state information reference signal (CSI-RS). Measurements of the physical layer of a communication terminal include reference signal received power (RSRP) measurement and reference signal received quality (RSRQ) measurement.
[0020] Similarly, the uplink reference signal is a known symbol in an NR communication system. The following three types of uplink reference signals are defined: a data demodulation reference signal (DM-RS), a phase tracking reference signal (PT-RS), and a sounding reference signal (SRS).
[0021] The transport channels described in Non-Patent Document 2 (Chapter 5) will be described below. Among the downlink transport channels, a broadcast channel (BCH) is broadcast to the entire coverage of the base station (cell). The BCH is mapped to a physical broadcast channel (PBCH).
[0022] Retransmission control using HARQ is applied to the Downlink Shared Channel (DL-SCH). The DL-SCH can be broadcast to the entire coverage of the base station (cell). The DL-SCH supports dynamic or semi-static resource allocation. Semi-static resource allocation is also called semi-persistent scheduling. The DL-SCH supports discontinuous reception (DRX) in communication terminals to reduce power consumption of the communication terminals. The DL-SCH is mapped to the Physical Downlink Shared Channel (PDSCH).
[0023] The Paging Channel (PCH) supports DRX of communication terminals to enable low power consumption of the communication terminals. The PCH is required to broadcast to the entire coverage of the base station (cell). The PCH is mapped to physical resources such as the Physical Downlink Shared Channel (PDSCH) that can be dynamically used for traffic.
[0024] Among the uplink transport channels, the uplink shared channel (UL-SCH) is subject to retransmission control using HARQ. The UL-SCH supports dynamic or semi-static resource allocation. Semi-static resource allocation is also called configured grant. The UL-SCH is mapped to the physical uplink shared channel (PUSCH).
[0025] The Random Access Channel (RACH) is limited to control information, has a risk of collision, and is mapped to the Physical Random Access Channel (PRACH).
[0026] The following describes HARQ. HARQ is a technology that improves the communication quality of a transmission path by combining Automatic Repeat reQuest (ARQ) and Forward Error Correction. HARQ has the advantage that error correction functions effectively through retransmission even for transmission paths whose communication quality varies. In particular, by combining the reception result of the initial transmission and the reception result of the retransmission when retransmitting, it is possible to obtain further quality improvement.
[0027] An example of a retransmission method will be described below. If the receiving side is unable to decode the received data correctly, in other words, if a CRC (Cyclic Redundancy Check) error occurs (CRC=NG), the receiving side will send a "Nack" to the transmitting side. The transmitting side, having received the "Nack", will retransmit the data. If the receiving side is able to decode the received data correctly, in other words, if no CRC error occurs (CRC=OK), the receiving side will send an "Ack" to the transmitting side. The transmitting side, having received the "Ack", will send the next data.
[0028] Another example of a retransmission method will be described. If a CRC error occurs on the receiving side, the receiving side requests a retransmission from the transmitting side. The retransmission request is made by toggling an NDI (New Data Indicator). The transmitting side, upon receiving the retransmission request, retransmits the data. If no CRC error occurs on the receiving side, no retransmission request is made. If the transmitting side does not receive a retransmission request for a predetermined period of time, it assumes that no CRC error occurred on the receiving side.
[0029] The logical channels described in Non-Patent Document 1 (Chapter 6) are explained below. The Broadcast Control Channel (BCCH) is a downlink channel for broadcasting system control information. The BCCH, which is a logical channel, is mapped to the broadcast channel (BCH) or the downlink shared channel (DL-SCH), which are transport channels.
[0030] The Paging Control Channel (PCCH) is a downlink channel for transmitting paging information and changes to system information. The PCCH, which is a logical channel, is mapped to the Paging Channel (PCH), which is a transport channel.
[0031] The Common Control Channel (CCCH) is a channel for transmitting control information between a communication terminal and a base station. The CCCH is used when the communication terminal does not have an RRC connection with the network. In the downlink direction, the CCCH is mapped to the Downlink Shared Channel (DL-SCH), which is a transport channel. In the uplink direction, the CCCH is mapped to the Uplink Shared Channel (UL-SCH), which is a transport channel.
[0032] A Dedicated Control Channel (DCCH) is a channel that transmits dedicated control information between a communication terminal and a network in a one-to-one relationship. The DCCH is used when the communication terminal has an RRC connection with the network. The DCCH is mapped to an uplink shared channel (UL-SCH) in the uplink and to a downlink shared channel (DL-SCH) in the downlink.
[0033] A Dedicated Traffic Channel (DTCH) is a point-to-point communication channel for transmitting user information to a communication terminal. DTCH exists in both uplink and downlink. In uplink, DTCH is mapped to an uplink shared channel (UL-SCH) and in downlink, it is mapped to a downlink shared channel (DL-SCH).
[0034] The location of a communication terminal is tracked in units of an area consisting of one or more cells. Location tracking is performed to track the location of the communication terminal even when it is in standby mode and to call the communication terminal, in other words, to enable the communication terminal to receive calls. The area for tracking the location of this communication terminal is called a Tracking Area (TA).
[0035] In NR, paging of communication terminals within a range that is smaller than a tracking area is supported. This range is called a RAN Notification Area (RNA). Paging of communication terminals in the RRC_INACTIVE state, which will be described later, is performed within this range.
[0036] In NR, in order to support wide frequency bandwidths (transmission bandwidths), carrier aggregation (CA) is being considered, which aggregates (also referred to as "aggregation") two or more component carriers (CCs). CA is described in Non-Patent Document 1.
[0037] When CA is configured, a communication terminal (UE) has only one RRC connection with the network (NW). In the RRC connection, one serving cell provides NAS (Non-Access Stratum) mobility information and security input. This cell is called a primary cell (PCell). Depending on the UE's capabilities, a secondary cell (SCell) is configured to form a serving cell set together with the PCell. A serving cell set consisting of one PCell and one or more SCells is configured for one UE.
[0038] In addition, in 3GPP, in order to further increase communication capacity, there is a dual connectivity (abbreviated as DC) in which a UE connects to two base stations to communicate. DC is described in Non-Patent Documents 1 and 22.
[0039] Of the base stations performing dual connectivity (DC), one may be referred to as a "master base station (Master Node: MN)" and the other as a "secondary base station (Secondary Node: SN)." Serving cells configured by the master base station may be collectively referred to as a master cell group (MCG), and serving cells configured by secondary base stations may be collectively referred to as a secondary cell group (SCG). In DC, the primary cell in the MCG or SCG is referred to as a special cell (SpCell or SPCell). The special cell in the MCG is referred to as a PCell, and the special cell in the SCG is referred to as a primary SCG cell (PSCell).
[0040] In addition, in NR, the base station pre-sets a portion of the carrier frequency band (hereinafter sometimes referred to as the Bandwidth Part (BWP)) for the UE, and the UE transmits and receives data to and from the base station using this BWP, thereby reducing power consumption in the UE.
[0041] Additionally, 3GPP is considering supporting services (or applications) using side link (SL) communication (also referred to as PC5 communication) in both the Evolved Packet System (EPS) (described later) and the 5G core system (see Non-Patent Documents 1, 2, 26 to 28). SL communication involves communication between terminals. Services using SL communication include, for example, vehicle-to-everything (V2X) services and proximity services. In SL communication, not only direct communication between terminals but also communication between a UE and a network via a relay has been proposed (see Non-Patent Documents 26 and 28).
[0042] The physical channels used for SL (see Non-Patent Documents 2 and 11) are as follows: The physical sidelink broadcast channel (PSBCH) carries information related to the system and synchronization and is transmitted from the UE.
[0043] The physical sidelink control channel (PSCCH) carries control information from the UE for sidelink and V2X sidelink communications.
[0044] The physical sidelink shared channel (PSSCH) carries data from the UE for sidelink and V2X sidelink communications.
[0045] The physical sidelink feedback channel (PSFCH) carries HARQ feedback on the sidelink from a UE that received a PSSCH transmission to the UE that transmitted the PSSCH.
[0046] The transport channel used for SL (see Non-Patent Document 1) will be described. The sidelink broadcast channel (SL-BCH) has a predetermined transport format and is mapped to the PSBCH, which is a physical channel.
[0047] The Sidelink Shared Channel (SL-SCH) supports broadcast transmissions. The SL-SCH supports both UE autonomous resource selection and base station scheduled resource allocation. UE autonomous resource selection involves a collision risk, whereas when the UE is allocated dedicated resources by the base station, there is no collision. The SL-SCH also supports dynamic link adaptation by changing transmit power, modulation, and coding. The SL-SCH is mapped to the PSSCH, which is a physical channel.
[0048] The logical channels used for SL (see Non-Patent Document 2) will be described. The Sidelink Broadcast Control Channel (SBCCH) is a sidelink channel for broadcasting sidelink system information from one UE to other UEs. The SBCCH is mapped to the SL-BCH, which is a transport channel.
[0049] The Sidelink Traffic Channel (STCH) is a point-to-multipoint traffic channel for transmitting user information from one UE to other UEs. The STCH is used only by UEs with sidelink communication capability and UEs with V2X sidelink communication capability. Point-to-point communication between two sidelink-capable UEs is also realized by the STCH. The STCH is mapped to the SL-SCH, a transport channel.
[0050] The Sidelink Control Channel (SCCH) is a control channel for transmitting control information from one UE to another UE. The SCCH is mapped to the SL-SCH, which is a transport channel.
[0051] In LTE, only broadcast was supported for SL communication. In NR, support for unicast and groupcast as SL communication in addition to broadcast is being considered (see Non-Patent Document 27 (3GPP TS23.287)).
[0052] In unicast communication and groupcast communication in SL, HARQ feedback (Ack / Nack), CSI reporting, etc. are supported.
[0053] In addition, 3GPP is considering integrated access and backhaul (IAB), which performs both the access link between a UE and a base station and the backhaul link between base stations wirelessly (see Non-Patent Documents 2, 20, and 29).
[0054] Several new technologies have been proposed for mobile communication systems, such as a technology that allows a single terminal to connect to multiple networks simultaneously to improve communication capacity and reliability (see Non-Patent Documents 30 and 31).
[0055] 3GPP TS36.300 V17.5.03GPP TS38.300 V17.6.0“Scenarios, requirements and KPIs for 5G mobile and wireless system”、ICT-317669-METIS / D1.13GPP TR23.799 V14.0.03GPP TR38.801 V14.0.03GPP TR38.802 V14.2.03GPP TR38.804 V14.0.03GPP TR38.912 V16.0.03GPP RP-1721153GPP TS23.501 V18.3.03GPP TS38.211 V18.0.03GPP TS38.212 V18.0.03GPP TS38.213 V18.0.03GPP TS38.214 V18.0.03GPP TS38.321 V17.6.03GPP TS38.322 V17.3.03GPP TS38.323 V17.5.03GPP TS37.324 V17.0.03GPP TS38.331 V17.6.03GPP TS38.401 V17.6.03GPP TS38.413 V17.6.03GPP TS37.340 V17.6.03GPP TS38.423 V17.6.03GPP TS38.305 V17.6.03GPP TS23.273 V18.3.03GPP TR23.703 V12.0.03GPP TS23.287 V18.1.03GPP TS23.303 V17.1.03GPP TS38.340 V17.5.03GPP SWS-2300493GPP TS23.502 V18.3.03GPP TS23.503 V18.3.03GPP TR32.851 V12.2.03GPP TS28.537 V17.3.0
[0056] Failures may occur in multiple networks to which a UE is simultaneously connected. However, no process for detecting network failures in a communication system in which a UE is simultaneously connected to multiple networks has been disclosed. As a result, network failures cannot be detected when a UE is simultaneously connected to multiple networks, and measures against network failures cannot be implemented. As a result, problems arise in that reliability cannot be ensured in a communication system using multiple networks, and the availability of the communication networks is reduced.
[0057] In view of the above-mentioned problems, one of the objectives of the present disclosure is to enable a UE in a communication system configured to be able to simultaneously connect to multiple networks to detect a network failure while the UE is simultaneously connected to multiple networks.
[0058] The communication system according to the present disclosure is a communication system compatible with a fifth-generation radio access system, and includes a plurality of networks including a radio access network and a core network. The plurality of networks include an anchor network, which is a network to which a communication terminal is connected and has a user plane function for directly connecting to a data network to which the communication terminal sends and receives data, and a non-anchor network that connects to the data network via the anchor network. The anchor network acquires information relating to communication quality in the non-anchor network from the non-anchor network, detects a failure in the non-anchor network based on the acquired information, and detects a failure in its own network based on information relating to communication quality in its own network.
[0059] According to the present disclosure, a communication system is provided that can detect a network failure while a UE is simultaneously connected to multiple networks.
[0060] The objects, features, aspects, and advantages of the present disclosure will become more apparent from the following detailed description and the accompanying drawings.
[0061] 12. FIG. 13 is an explanatory diagram showing the configuration of a radio frame used in an NR communication system. FIG. 14 is a block diagram showing the overall configuration of an NR communication system 210 being discussed in 3GPP. FIG. 15 is a block diagram showing the configuration of a DC by a base station connected to an NG core. FIG. 16 is a block diagram showing the configuration of a mobile terminal 202 shown in FIG. 2. FIG. 17 is a block diagram showing the configuration of a base station 213 shown in FIG. 2. FIG. 18 is a block diagram showing the configuration of a 5GC unit. FIG. 19 is a flowchart showing an overview of operations from cell search to standby performed by a communication terminal (UE) in an NR communication system. FIG. 19 is a diagram showing an example of the configuration of a cell in an NR system. FIG. 20 is a connection configuration diagram showing an example of the connection configuration of a terminal in SL communication. FIG. 21 is a connection configuration diagram showing an example of the connection configuration of a base station that supports access / backhaul integration. FIG. 21 is a configuration diagram showing an example of the connection of multiple NWs for the first embodiment. FIG. 22 is a sequence diagram showing an example of the setting operation of QoS monitoring for the first embodiment. FIG. 23 is a sequence diagram showing an example of procedure 1100 of FIG. 12. FIG. 24 is a sequence diagram showing an example of procedure 1111 of FIG. 12. FIG. 25 is a sequence diagram showing an example of procedure 1150 of FIG. 12. FIG. 26 is a sequence diagram showing an example of procedure 1161 of FIG. 26. FIG. 27 is a sequence diagram showing an example of the operation of detecting a NW failure for the first embodiment. 24 is a sequence diagram showing another example of the setting operation of QoS monitoring for the first embodiment. FIG. 25 is a sequence diagram showing another example of the operation of detecting a NW failure for the first embodiment. FIG. 26 is a diagram showing the beginning of a sequence showing another example of the setting operation of QoS monitoring for the first embodiment. FIG. 27 is a diagram showing the middle of a sequence showing another example of the setting operation of QoS monitoring for the first embodiment. FIG. 28 is a diagram showing the end of a sequence showing another example of the setting operation of QoS monitoring for the first embodiment. FIG. 29 is a sequence diagram showing an example of an intermediate UPF switching operation in a non-anchor NW for the second embodiment. FIG. 29 is a sequence diagram showing an example of procedure 1625 of FIG. 23. FIG. 29 is a sequence diagram showing another example of an intermediate UPF switching operation in a non-anchor NW for the second embodiment. FIG. 29 is a sequence diagram showing an example of a NW switching operation in a non-anchor NW for the third embodiment. FIG. 29 is a sequence diagram showing another example of a NW switching operation in a non-anchor NW for the third embodiment.10 is a sequence diagram showing another example of NW switching operation in the anchor NW for a first modification of the third embodiment. FIG. 11 is a diagram showing the first half of a sequence diagram showing an example of switching operation of the anchor UPF for a fourth embodiment. FIG. 12 is a diagram showing the second half of a sequence diagram showing an example of switching operation of the anchor UPF for a fourth embodiment.
[0062] Embodiment 1. Figure 2 is a block diagram showing the overall configuration of an NR communication system 210 being discussed in 3GPP. Figure 2 will be explained. The radio access network is called an NG-RAN (Next Generation Radio Access Network) 211. A mobile terminal device (hereinafter referred to as a "mobile terminal (User Equipment: UE)") 202, which is a communication terminal device, is capable of wireless communication with a base station device (hereinafter referred to as an "NR base station (NG-RAN NodeB: gNB)") 213, and transmits and receives signals via wireless communication. The NG-RAN 211 is composed of one or more NR base stations 213.
[0063] Here, the term "communication terminal device" includes not only mobile terminal devices such as mobile cell phone terminal devices, but also stationary devices such as sensors. In the following description, the term "communication terminal device" may be simply referred to as a "communication terminal."
[0064] An access stratum (AS) protocol is terminated between the UE 202 and the NG-RAN 211. Examples of AS protocols include radio resource control (RRC), service data adaptation protocol (SDAP), packet data convergence protocol (PDCP), radio link control (RLC), medium access control (MAC), and physical layer (PHY). RRC is used in the control plane (hereinafter sometimes referred to as the C-plane, C-Plane, or CP), SDAP is used in the user plane (hereinafter sometimes referred to as the U-plane, U-Plane, or UP), and PDCP, MAC, RLC, and PHY are used in both the C-plane and the U-plane.
[0065] The control protocol RRC (Radio Resource Control) between the UE 202 and the NR base station 213 performs broadcasting, paging, RRC connection management, etc. The states of the NR base station 213 and the UE 202 in RRC include RRC_IDLE, RRC_CONNECTED, and RRC_INACTIVE.
[0066] In RRC_IDLE, PLMN (Public Land Mobile Network) selection, system information (SI) broadcast, paging, cell re-selection, mobility, etc. are performed. In RRC_CONNECTED, the mobile terminal has an RRC connection and can transmit and receive data with the network. In addition, in RRC_CONNECTED, handover (HO), measurement of neighbor cells, etc. are performed. In RRC_INACTIVE, the connection between the 5G core unit 214 and the NR base station 213 is maintained, and system information (SI) broadcast, paging, cell re-selection, mobility, etc. are performed.
[0067] The gNB 213 is connected to a 5G core unit (hereinafter sometimes referred to as the "5GC unit") 214, which includes an Access and Mobility Management Function (AMF), a Session Management Function (SMF), or a User Plane Function (UPF), via an NG interface. Control information and / or user data is communicated between the gNB 213 and the 5GC unit 214. The NG interface is a collective term for the N2 interface between the gNB 213 and the AMF 220, the N3 interface between the gNB 213 and the UPF 221, the N11 interface between the AMF 220 and the SMF 222, and the N4 interface between the UPF 221 and the SMF 222. Multiple 5GC units 214 may be connected to one gNB 213. The gNBs 213 are connected via an Xn interface, and control information and / or user data are communicated between the gNBs 213.
[0068] The 5GC unit 214 is a higher-level device, specifically a higher-level node, and controls the connection between the NR base station 213 and the mobile terminal (UE) 202, distributes paging signals to one or more NR base stations (gNB) 213 and / or LTE base stations (E-UTRAN NodeB: eNB), and performs other functions. The 5GC unit 214 also performs mobility control in the idle state. The 5GC unit 214 manages the tracking area list when the mobile terminal 202 is in the idle state, in the inactive state, and in the active state. The 5GC unit 214 initiates a paging protocol by transmitting a paging message to a cell belonging to the tracking area in which the mobile terminal 202 is registered.
[0069] The gNB 213 may configure one or more cells. When one gNB 213 configures multiple cells, each cell is configured to be able to communicate with the UE 202.
[0070] The gNB 213 may be divided into a central unit (hereinafter, sometimes referred to as CU) 215 and a distributed unit (hereinafter, sometimes referred to as DU) 216. One CU 215 is configured within the gNB 213. One or more DUs 216 are configured within the gNB 213. One DU 216 configures one or more cells. The CU 215 is connected to the DU 216 via an F1 interface, and control information and / or user data is communicated between the CU 215 and the DU 216. The F1 interface consists of an F1-C interface and an F1-U interface. The CU 215 is responsible for the functions of the RRC, SDAP, and PDCP protocols, and the DU 216 is responsible for the functions of the RLC, MAC, and PHY protocols. One or more TRPs (Transmission Reception Points) 219 may be connected to the DU 216. The TRP 219 transmits and receives radio signals to and from the UE.
[0071] The CU 215 may be divided into a C-plane CU (CU-C) 217 and a U-plane CU (CU-U) 218. One CU-C 217 is configured within the CU 215. One or more CU-Us 218 are configured within the CU 215. The CU-C 217 is connected to the CU-U 218 via an E1 interface, and control information is communicated between the CU-C 217 and the CU-U 218. The CU-C 217 is connected to the DU 216 via an F1-C interface, and control information is communicated between the CU-C 217 and the DU 216. The CU-U 218 is connected to the DU 216 via an F1-U interface, and user data is communicated between the CU-U 218 and the DU 216.
[0072] In a 5G communication system, a Unified Data Management (UDM) function and a Policy Control Function (PCF) described in Non-Patent Document 10 (3GPP TS23.501) may be included. The UDM and / or PCF may be included in the 5GC unit 214 in FIG. 2 .
[0073] In a 5G communication system, a Location Management Function (LMF) described in Non-Patent Document 24 (3GPP TS 38.305) may be provided. The LMF may be connected to a base station via an AMF as disclosed in Non-Patent Document 25 (3GPP TS 23.273).
[0074] A 5G communication system may include a Non-3GPP Interworking Function (N3IWF) described in Non-Patent Document 10 (3GPP TS23.501). The N3IWF may terminate an Access Network (AN) between the UE and the N3IWF in non-3GPP access between the UE and the N3IWF.
[0075] FIG. 3 is a diagram showing a DC (dual connectivity) configuration connected to an NG core. In FIG. 3, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In FIG. 3, the master base station 240-1 may be a gNB or an eNB. Furthermore, the secondary base station 240-2 may be a gNB or an eNB. For example, in FIG. 3, a DC configuration in which the master base station 240-1 is a gNB and the secondary base station 240-2 is an eNB may be referred to as NG-EN-DC. In FIG. 3, an example is shown in which the U-Plane connection between the 5GC unit 214 and the secondary base station 240-2 is performed via the master base station 240-1, but it may also be performed directly between the 5GC unit 214 and the secondary base station 240-2. 3, an EPC (Evolved Packet Core), which is a core network connected to the LTE system and the LTE-A system, may be connected to the master base station 240-1 instead of the 5GC unit 214. A U-Plane connection may be directly established between the EPC and the secondary base station 240-2.
[0076] FIG. 4 is a block diagram showing the configuration of mobile terminal 202 shown in FIG. 2. The transmission process of mobile terminal 202 shown in FIG. 4 will be described. First, control data from control unit 310 and user data from application unit 302 are sent to protocol processing unit 301. Buffering of the control data and user data may be performed. Buffers for the control data and user data may be provided in control unit 310, application unit 302, or protocol processing unit 301. Protocol processing unit 301 performs protocol processing such as SDAP, PDCP, RLC, and MAC, for example, determining a destination base station in DC, and adding a header for each protocol. The protocol-processed data is passed to encoder unit 304, where it is subjected to encoding such as error correction. Some data may be output directly from protocol processing unit 301 to modulation unit 305 without being encoded. The data encoded by encoder unit 304 is modulated by modulation unit 305. Precoding in MIMO may be performed by modulation unit 305. The modulated data is converted into a baseband signal, and then output to frequency conversion section 306, where it is converted into a radio transmission frequency. Then, the transmission signal is transmitted from antennas 307-1 to 307-4 to base station 213. Although the example in FIG. 4 shows a case where the number of antennas is four, the number of antennas is not limited to four.
[0077] Furthermore, the reception process of the mobile terminal 202 is performed as follows. Radio signals from the base station 213 are received by the antennas 307-1 to 307-4. The received signals are converted from a radio reception frequency to a baseband signal by the frequency conversion unit 306, and demodulated by the demodulation unit 308. The demodulation unit 308 may also perform weight calculation and multiplication processing. The demodulated data is passed to the decoder unit 309, where decoding processes such as error correction are performed. The decoded data is passed to the protocol processing unit 301, where protocol processing such as MAC, RLC, PDCP, and SDAP is performed, for example, operations such as removing headers in each protocol. Of the data that has undergone protocol processing, the control data is passed to the control unit 310, and the user data is passed to the application unit 302.
[0078] A series of processes in the mobile terminal 202 is controlled by a control unit 310. Therefore, the control unit 310 is also connected to each of the units 302, 304 to 309, although this is omitted in FIG.
[0079] Each unit of the mobile terminal 202, such as the control unit 310, protocol processing unit 301, encoder unit 304, and decoder unit 309, is implemented by a processing circuit including, for example, a processor and memory. For example, the control unit 310 is implemented by a processor executing a program describing a series of processes performed by the mobile terminal 202. The program describing the series of processes performed by the mobile terminal 202 is stored in memory. Examples of memory include non-volatile or volatile semiconductor memory such as RAM (Random Access Memory), ROM (Read Only Memory), and flash memory. Each unit of the mobile terminal 202, such as the control unit 310, protocol processing unit 301, encoder unit 304, and decoder unit 309, may be implemented by a dedicated processing circuit such as an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a DSP (Digital Signal Processor). In FIG. 4, the number of antennas used by the mobile terminal 202 for transmission and the number of antennas used for reception may be the same or different.
[0080] 5 is a block diagram showing the configuration of the base station 213 shown in FIG. 2. The transmission process of the base station 213 shown in FIG. 5 will be described. The EPC communication unit 401 transmits and receives data between the base station 213 and the EPC. The 5GC communication unit 412 transmits and receives data between the base station 213 and the 5GC (such as the 5GC unit 214). The other base station communication unit 402 transmits and receives data with other base stations. The EPC communication unit 401, the 5GC communication unit 412, and the other base station communication unit 402 each exchange information with the protocol processing unit 403. Control data from the control unit 411, and user data and control data from the EPC communication unit 401, the 5GC communication unit 412, and the other base station communication unit 402 are sent to the protocol processing unit 403. Buffering of the control data and user data may be performed. Buffers for control data and user data may be provided in the control unit 411, the EPC communication unit 401, the 5GC communication unit 412, or the other base station communication unit 402.
[0081] The protocol processing unit 403 performs protocol processing such as SDAP, PDCP, RLC, MAC, etc., such as routing transmission data in DC, etc., and adding headers for each protocol. The protocol-processed data is passed to the encoder unit 405, where it is subjected to encoding processing such as error correction. Some data may be output directly from the protocol processing unit 403 to the modulation unit 406 without being encoded. Data may also be sent from the protocol processing unit 403 to the other base station communication unit 402. For example, in DC, data sent from the 5GC communication unit 412 or the EPC communication unit 401 may be sent to another base station, such as a secondary base station, via the other base station communication unit 402. The encoded data is modulated by the modulation unit 406. The modulation unit 406 may also perform MIMO precoding. The modulated data is converted into a baseband signal, and then output to the frequency conversion unit 407, where it is converted into a radio transmission frequency. Thereafter, the transmission signals are transmitted from antennas 408-1 to 408-4 to one or more mobile terminals 202. Although the number of antennas is four in the example shown in Fig. 5, the number of antennas is not limited to four.
[0082] Furthermore, the reception process of the base station 213 is performed as follows. Radio signals from one or more mobile terminals 202 are received by antennas 408-1 to 408-4. The received signals are converted from a radio reception frequency to a baseband signal by a frequency conversion unit 407, and demodulated by a demodulation unit 409. The demodulated data is passed to a decoder unit 410, where decoding processes such as error correction are performed. The decoded data is passed to a protocol processing unit 403, where protocol processes such as MAC, RLC, PDCP, and SDAP are performed, for example, operations such as removing headers in each protocol. Of the data that has undergone protocol processing, control data is passed to the control unit 411, 5GC communication unit 412, EPC communication unit 401, or other base station communication unit 402, and user data is passed to the 5GC communication unit 412, EPC communication unit 401, or other base station communication unit 402. Data sent from the other base station communication unit 402 may be sent to the 5GC communication unit 412 or the EPC communication unit 401. The data may be, for example, uplink data sent to the 5GC communication unit 412 or the EPC communication unit 401 via another base station in DC.
[0083] A series of processes in the base station 213 is controlled by a control unit 411. Therefore, the control unit 411 is also connected to each of the units 401, 402, 405 to 410, and 412, although this is omitted in FIG.
[0084] Each unit of the base station 213, for example, the control unit 411, the protocol processing unit 403, the 5GC communication unit 412, the EPC communication unit 401, the other base station communication unit 402, the encoder unit 405, and the decoder unit 410, is realized by a processing circuit including a processor and a memory, or a dedicated processing circuit such as an FPGA, an ASIC, or a DSP, similar to the above-mentioned mobile terminal 202. In Fig. 5, the number of antennas used by the base station 213 for transmission and the number of antennas used for reception may be the same or different.
[0085] As an example of the configuration of the CU 215 shown in Fig. 2, a configuration in which a DU communication unit is provided is sometimes used, excluding the encoder unit 405, modulation unit 406, frequency conversion unit 407, antennas 408-1 to 408-4, demodulation unit 409, and decoder unit 410 shown in Fig. 5. The DU communication unit is connected to a protocol processing unit 403. The protocol processing unit 403 in the CU 215 performs protocol processing such as PDCP and SDAP.
[0086] As an example of the configuration of the DU 216 shown in Fig. 2, a configuration in which a CU communication unit is provided may be used, excluding the EPC communication unit 401, other base station communication unit 402, and 5GC communication unit 412 shown in Fig. 5. The CU communication unit is connected to a protocol processing unit 403. The protocol processing unit 403 in the DU 216 performs protocol processing such as PHY, MAC, and RLC.
[0087] FIG. 6 is a block diagram showing the configuration of the 5GC unit. FIG. 6 shows the configuration of the 5GC unit 214 shown in FIG. 2 described above. FIG. 6 shows a case where the 5GC unit 214 shown in FIG. 2 includes an AMF configuration, an SMF configuration, and a UPF configuration. In the example shown in FIG. 6, the AMF may have the function of the control plane control unit 525, the SMF may have the function of the session management unit 527, and the UPF may have the functions of the user plane communication unit 523 and the Data Network communication unit 521. The Data Network communication unit 521 transmits and receives data between the 5GC unit 214 and the Data Network. The base station communication unit 522 transmits and receives data via the NG interface between the 5GC unit 214 and the base station 213. User data sent from the Data Network is passed from the Data Network communication unit 521 to the base station communication unit 522 via the user plane communication unit 523, and then transmitted to one or more base stations 213. User data sent from the base station 213 is passed from the base station communication unit 522 to the Data Network communication unit 521 via the user plane communication unit 523, and then transmitted to the Data Network.
[0088] The control data sent from the base station 213 is passed from the base station communication unit 522 to the control plane control unit 525. The control plane control unit 525 may pass the control data to the session management unit 527. The control data may be sent from the Data Network. The control data sent from the Data Network may be sent from the Data Network communication unit 521 to the session management unit 527 via the user plane communication unit 523. The session management unit 527 may send the control data to the control plane control unit 525.
[0089] The user plane communication unit 523 includes a PDU processing unit 523-1, a mobility anchoring unit 523-2, etc., and performs general processing for the user plane (hereinafter sometimes referred to as U-Plane). The PDU processing unit 523-1 processes data packets, for example, transmitting and receiving packets to and from the Data Network communication unit 521, and transmitting and receiving packets to and from the base station communication unit 522. The mobility anchoring unit 523-2 is responsible for anchoring the data path during UE mobility.
[0090] The session management unit 527 manages the PDU session established between the UE and the UPF. The session management unit 527 includes a PDU session control unit 527-1, a UE IP address allocation unit 527-2, etc. The PDU session control unit 527-1 manages the PDU session between the mobile terminal 202 and the 5GC unit 214. The UE IP address allocation unit 527-2 assigns an IP address to the mobile terminal 202, etc.
[0091] The control plane control unit 525 includes a NAS security unit 525-1, an idle state mobility management unit 525-2, etc., and performs overall processing for the control plane (hereinafter sometimes referred to as the C-Plane). The NAS security unit 525-1 performs security for NAS (Non-Access Stratum) messages, etc. The idle state mobility management unit 525-2 performs mobility management in the standby state (idle state: also referred to as RRC_IDLE state or simply idle), generation and control of paging signals in the standby state, addition, deletion, update, search, tracking area list management, etc. for one or more mobile terminals 202 under its control.
[0092] A series of processes of the 5GC unit 214 is controlled by a control unit 526. Therefore, although the control unit 526 is omitted in Fig. 6, it is connected to each unit 521 to 523, 525, and 527. Like the control unit 310 of the mobile terminal 202 described above, each unit of the 5GC unit 214 is realized by, for example, a processing circuit configured to include a processor and memory, or a dedicated processing circuit such as an FPGA, ASIC, or DSP.
[0093] Next, an example of a cell search method in a communication system is shown. Fig. 7 is a flowchart showing an outline of the process from cell search to standby operation performed by a communication terminal (UE) in an NR communication system. When the communication terminal starts a cell search, in step ST601, it synchronizes slot timing and frame timing using a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS) transmitted from a surrounding base station.
[0094] P-SS and S-SS are collectively called a synchronization signal (SS). A synchronization code is assigned to the synchronization signal (SS) in one-to-one correspondence with a PCI (Physical Cell Identifier) assigned to each cell. 1008 different PCIs are being considered. A communication terminal synchronizes using these 1008 different PCIs and detects (identifies) the PCI of the synchronized cell.
[0095] In step ST602, the communication terminal receives the PBCH for the next synchronized cell. A master information block (MIB) including cell configuration information is mapped to the BCCH on the PBCH. Therefore, the MIB can be obtained by receiving the PBCH and obtaining the BCCH. Examples of MIB information include a system frame number (SFN), scheduling information for system information block (SIB) 1, subcarrier spacing for SIB1 and the like, and information on the DM-RS position.
[0096] Furthermore, the communication terminal acquires an SS block identifier from the PBCH. A part of the bit string of the SS block identifier is included in the MIB. The remaining bit string is included in an identifier used to generate a sequence of DM-RS associated with the PBCH. The communication terminal acquires the SS block identifier using the MIB included in the PBCH and the sequence of DM-RS associated with the PBCH.
[0097] Next, in step ST603, the communication terminal measures the received power of the SS block.
[0098] Next, in step ST604, the communication terminal selects the cell with the best reception quality, for example, the cell with the highest reception power, that is, the best cell, from among the one or more cells detected up to step ST603. The communication terminal also selects the beam with the best reception quality, for example, the beam with the highest reception power of the SS block, that is, the best beam. The reception power of the SS block for each SS block identifier is used, for example, to select the best beam.
[0099] Next, in step ST605, the communication terminal receives DL-SCH based on the scheduling information of SIB1 included in the MIB, and obtains SIB (System Information Block) 1 in the broadcast information BCCH. SIB1 includes information on access to the cell, cell configuration information, and scheduling information of other SIBs (SIBk: k is an integer greater than or equal to 2). SIB1 also includes a tracking area code (TAC).
[0100] Next, in step ST606, the communication terminal compares the TAC of SIB1 received in step ST605 with the TAC portion of the tracking area identity (TAI) in the tracking area list already held by the communication terminal. The tracking area list is also called a TAI list. The TAI is identification information for identifying a tracking area, and is composed of an MCC (Mobile Country Code), an MNC (Mobile Network Code), and a TAC (Tracking Area Code). The MCC is a country code. The MNC is a network code. The TAC is a tracking area code number.
[0101] If the comparison in step ST606 shows that the TAC received in step ST605 is the same as the TAC included in the tracking area list, the communication terminal enters standby mode in the cell. If the comparison shows that the TAC received in step ST605 is not included in the tracking area list, the communication terminal requests a core network (EPC) including an MME and the like to change the tracking area through the cell in order to perform a Tracking Area Update (TAU).
[0102] An apparatus constituting a core network (hereinafter sometimes referred to as a "core network apparatus") updates the tracking area list based on the identification number (e.g., UE-ID) of a communication terminal sent from the communication terminal together with a TAU request signal. The core network apparatus transmits the updated tracking area list to the communication terminal. The communication terminal rewrites (updates) the TAC list held by the communication terminal based on the received tracking area list. Thereafter, the communication terminal enters standby mode in the cell.
[0103] Next, examples of random access methods in a communication system are shown. Four-step random access and two-step random access are used for random access. For each of the four-step and two-step random access methods, there is contention-based random access, i.e., random access in which timing collisions with other mobile terminals may occur, and contention-free random access.
[0104] An example of a collision-based four-step random access method is shown below. In the first step, the mobile terminal transmits a random access preamble to the base station. The random access preamble may be selected by the mobile terminal from a predetermined range, or may be individually assigned to the mobile terminal and notified by the base station.
[0105] In the second step, the base station transmits a random access response to the mobile terminal, which includes uplink scheduling information used in the third step, a terminal identifier used in the uplink transmission in the third step, and the like.
[0106] In the third step, the mobile terminal performs uplink transmission to the base station. The mobile terminal uses the information acquired in the second step for uplink transmission. In the fourth step, the base station notifies the mobile terminal whether or not the collision has been resolved. If the mobile terminal is notified that there is no collision, it ends the random access process. If the mobile terminal is notified that there is a collision, it starts the process over from the first step.
[0107] The contention-free four-step random access method differs from the contention-based four-step random access method in the following points: Prior to the first step, the base station pre-assigns a random access preamble and uplink scheduling to the mobile terminal, and the notification of whether or not contention has been resolved in the fourth step is not required.
[0108] An example of a collision-based two-step random access method is shown below. In the first step, the mobile terminal transmits a random access preamble and performs uplink transmission to the base station. In the second step, the base station notifies the mobile terminal whether there is a collision. If the mobile terminal is notified that there is no collision, it terminates the random access process. If the mobile terminal is notified that there is a collision, it restarts the process from the first step.
[0109] The contention-free two-step random access method differs from the contention-based two-step random access method in the following points: prior to the first step, the base station pre-assigns a random access preamble and uplink scheduling to the mobile terminal, and in the second step, the base station transmits a random access response to the mobile terminal.
[0110] FIG. 8 shows an example of a cell configuration in NR. In an NR cell, narrow beams are formed and transmitted in different directions. In the example shown in FIG. 8, at certain times, base station 750 transmits and receives signals to and from a mobile terminal using beam 751-1. At other times, base station 750 transmits and receives signals to and from a mobile terminal using beam 751-2. In a similar manner, base station 750 transmits and receives signals to and from a mobile terminal using one or more of beams 751-3 to 751-8. In this way, base station 750 forms a wide-area cell 752.
[0111] 8 shows an example in which the number of beams used by the base station 750 is 8, but the number of beams may be different from 8. Also, in the example shown in FIG. 8, the number of beams used simultaneously by the base station 750 is 1, but it may be multiple.
[0112] The concept of Quasi-CoLocation (QCL) is used to identify beams (see Non-Patent Document 14 (3GPP TS38.214)). That is, the beam is identified by information indicating which reference signal (e.g., SS block, CSI-RS) the beam can be considered to be the same as. The information may include types of information regarding the aspects of the beams that can be considered to be the same, such as Doppler shift, Doppler shift spread, mean delay, mean delay spread, and spatial Rx parameters (see Non-Patent Document 14 (3GPP TS38.214)).
[0113] In 3GPP, a side link (SL) is supported for D2D (Device to Device) communication and V2V (Vehicle to Vehicle) communication (see Non-Patent Document 1 and Non-Patent Document 16). The SL is defined by the PC5 interface.
[0114] In order to support unicast and groupcast in addition to broadcast in SL communication, support for PC5-S signaling is being considered (see Non-Patent Document 27 (3GPP TS23.287)). For example, PC5-S signaling is implemented to establish a link for implementing SL, i.e., PC5 communication. The link is implemented in the V2X layer and is also called a Layer 2 link.
[0115] Furthermore, support for RRC signaling in SL communication is being considered (see Non-Patent Document 27 (3GPP TS23.287)). RRC signaling in SL communication is also referred to as PC5 RRC signaling. For example, it has been proposed to notify UE capabilities between UEs performing PC5 communication, or to notify AS layer settings for performing V2X communication using PC5 communication.
[0116] An example of a connection configuration of mobile terminals in SL communication is shown in Fig. 9. In the example shown in Fig. 9, UE 805 and UE 806 exist within the coverage 803 of base station 801. UL / DL communication 807 is performed between base station 801 and UE 805. UL / DL communication 808 is performed between base station 801 and UE 806. SL communication 810 is performed between UE 805 and UE 806. UE 811 and UE 812 exist outside the coverage 803. SL communication 814 is performed between UE 805 and UE 811. In addition, SL communication 816 is performed between UE 811 and UE 812.
[0117] As an example of communication between a UE and a NW via a relay in SL communication, a UE 805 shown in FIG. 9 relays communication between a UE 811 and a base station 801.
[0118] A configuration similar to that shown in FIG. 4 may be used for a UE that performs relaying. The relaying process in the UE will be described using FIG. 4. The relaying process by UE 805 in communication from UE 811 to base station 801 will be described. A radio signal from UE 811 is received by antennas 307-1 to 307-4. The received signal is converted from a radio reception frequency to a baseband signal by frequency conversion unit 306, and demodulated by demodulation unit 308. Weight calculation and multiplication processing may also be performed by demodulation unit 308. The demodulated data is passed to decoder unit 309, where decoding processing such as error correction is performed. The decoded data is passed to protocol processing unit 301, where protocol processing such as MAC and RLC used for communication with UE 811 is performed, such as removing headers in each protocol. Protocol processing such as RLC and MAC used for communication with base station 801 is also performed, such as adding headers in each protocol. Protocol processing of PDCP and SDAP may be performed in protocol processing unit 301 of UE 811. The protocol-processed data is passed to encoder unit 304, where encoding such as error correction is performed. Some data may be output directly from protocol processing unit 301 to modulation unit 305 without being encoded. The data encoded by encoder unit 304 is modulated by modulation unit 305. Precoding in MIMO may be performed by modulation unit 305. The modulated data is converted into a baseband signal, and then output to frequency conversion unit 306, where it is converted into a radio transmission frequency. Thereafter, a transmission signal is transmitted to base station 801 from antennas 307-1 to 307-4.
[0119] In the above, an example of relaying by UE 805 in communication from UE 811 to base station 801 has been shown, but similar processing is also used in relaying communication from base station 801 to UE 811.
[0120] 5G base stations can support integrated access and backhaul (IAB) (see Non-Patent Documents 2 and 20). A base station supporting IAB (hereinafter sometimes referred to as an IAB base station) is composed of an IAB donor CU, which is a CU of the base station operating as an IAB donor that provides IAB functions, an IAB donor DU, which is a DU of the base station operating as an IAB donor, and an IAB node connected to the IAB donor DU and to a UE via a radio interface. An F1 interface is provided between the IAB node and the IAB donor CU (see Non-Patent Document 2).
[0121] An example of IAB base station connections is shown in Figure 10. IAB donor CU 901 is connected to IAB donor DU 902. IAB node 903 is connected to IAB donor DU 902 using a wireless interface. IAB node 903 is connected to IAB node 904 using a wireless interface. In other words, IAB nodes may be connected in cascade. UE 905 is connected to IAB node 904 using a wireless interface. UE 906 may be connected to IAB node 903 using a wireless interface, and UE 907 may be connected to IAB donor DU 902 using a wireless interface. Multiple IAB donor DUs 902 may be connected to an IAB donor CU 901, multiple IAB nodes 903 may be connected to an IAB donor DU 902, and multiple IAB nodes 904 may be connected to an IAB node 903.
[0122] A BAP (Backhaul Adaptation Protocol) layer is provided in the connection between the IAB donor DU and the IAB node and in the connection between the IAB nodes (see Non-Patent Document 29). The BAP layer performs operations such as routing received data to the IAB donor DU and / or the IAB node, and mapping to an RLC channel (see Non-Patent Document 29).
[0123] As an example of the configuration of the IAB donor CU, a configuration similar to that of CU 215 is used.
[0124] An example of the configuration of the IAB donor DU is the same as that of the DU 216. The protocol processing unit of the IAB donor DU performs BAP layer processing, such as adding a BAP header to downstream data, routing to an IAB node, and removing the BAP header from upstream data.
[0125] As an example of the configuration of an IAB node, a configuration excluding the EPC communication unit 401, other base station communication unit 402, and 5GC communication unit 412 shown in Figure 5 may be used.
[0126] The transmission and reception processing at the IAB node will be described using FIGS. 5 and 10 . The transmission and reception processing at the IAB node 903 in communication between the IAB donor CU 901 and the UE 905 will be described. In uplink communication from the UE 905 to the IAB donor CU 901, a radio signal from the IAB node 904 is received by the antenna 408 (some or all of the antennas 408-1 to 408-4). The received signal is converted from a radio reception frequency to a baseband signal by the frequency conversion unit 407, and demodulated by the demodulation unit 409. The demodulated data is passed to the decoder unit 410, where decoding processing such as error correction is performed. The decoded data is passed to the protocol processing unit 403, where protocol processing such as MAC and RLC used for communication with the IAB node 904 is performed, such as removing headers in each protocol. In addition, routing to the IAB donor DU 902 is performed using a BAP header, and protocol processing such as RLC and MAC used for communication with the IAB donor DU 902, such as adding headers for each protocol, is performed. The protocol-processed data is passed to the encoder unit 405, where it is subjected to encoding processing such as error correction. Some data may be output directly from the protocol processing unit 403 to the modulation unit 406 without being encoded. The encoded data is modulated by the modulation unit 406. The modulation unit 406 may also perform precoding in MIMO. The modulated data is converted into a baseband signal, and then output to the frequency conversion unit 407, where it is converted into a radio transmission frequency. Then, a transmission signal is transmitted to the IAB donor DU 902 from antennas 408-1 to 408-4. Similar processing is performed in downlink communication from the IAB donor CU 901 to the UE 905.
[0127] The IAB node 904 also performs the same transmission and reception processing as the IAB node 903. The protocol processing unit 403 of the IAB node 903 performs BAP layer processing, such as adding a BAP header and routing to the IAB node 904 in upstream communication, and removing the BAP header in downstream communication.
[0128] In a 3GPP mobile communication system, a UE may be connected to multiple NWs. The connection between the UE and a data network (DN) may be established via an anchor UPF (a UPF directly connected to the DN). An anchor NW (a network having an anchor UPF; the same applies hereinafter) may be connected to one or more NWs connected to the UE. In this specification, a NW that does not have an anchor UPF is referred to as a non-anchor NW. Furthermore, a device constituting an anchor NW is referred to as an anchor NW device, and a device constituting a non-anchor NW is referred to as a non-anchor NW device.
[0129] Fig. 11 is a configuration diagram showing an example in which a UE is connected to multiple networks. In the example shown in Fig. 11, the UE is connected to each of NW1090 and NW1091. In the example shown in Fig. 11, base station #1, AMF #1, UPF #1, SMF #1, SEPP (Security Edge Protection Proxy: see Non-Patent Document 10) #1, PCF #1, UDM #1, and anchor UPF all belong to NW1090, and base station #2, AMF #2, UPF #2, SMF #2, SEPP #2, PCF #2, and UDM #2 all belong to NW1091. The anchor UPF is connected to a DN.
[0130] Failures may occur in multiple networks to which a UE is simultaneously connected. However, no process for detecting network failures in a communication system in which a UE is simultaneously connected to multiple networks has been disclosed. As a result, a network failure cannot be detected in a state in which a UE is simultaneously connected to multiple networks, and measures against the network failure cannot be implemented. As a result, problems arise in that reliability cannot be ensured in a communication system using multiple networks.
[0131] In this embodiment, a method for solving the above-mentioned problems is disclosed.
[0132] In this embodiment, the anchor network detects a network failure. A network function (NF) in the anchor network may perform the detection, or an anchor network device may perform the detection. For example, an SMF of the anchor network (hereinafter, sometimes referred to as an anchor SMF) may perform the detection. This allows, for example, the same device to perform network failure detection and session management, which results in a reduction in the time required to detect a network failure and a reduction in signaling.
[0133] To detect a network failure, a QoS (Quality of Service) monitoring report (see Non-Patent Documents 10 and 31) or the result of a QoE (Quality of Experience) measurement (see Non-Patent Document 2) may be used. For example, the anchor network may detect a network failure using QoS information, such as a QoS monitoring report, or may detect a network failure using QoE information, such as the result of a QoE measurement. The anchor network may detect a network failure using both QoS information and QoE information. The QoS information and QoE information are information about communication quality. The result of the QoE measurement may be, for example, a measurement result in a UE. The UE may notify the base station of the measurement result. The base station may notify the measurement result to an OAM (Operation, Administration and Maintenance) (see Non-Patent Document 33) function unit, or to an MnS (Management Service) (see Non-Patent Document 34) function unit, or to an NF (e.g., SMF). The notification from the base station to the NF (e.g., SMF) may be performed via the AMF or directly.
[0134] The NF (e.g., SMF) may obtain the QoE measurement results from the base station, from the OAM, from the MnS, or from the NWDAF (Network Data Analytics Function) (see non-patent document 10).
[0135] The anchor network device may request QoS monitoring from a non-anchor network device. For example, the anchor SMF may request QoS monitoring from a non-anchor network device. The anchor SMF may make the request to an SMF of the non-anchor network (hereinafter, sometimes referred to as a non-anchor SMF). The request from the anchor SMF to the non-anchor network device (e.g., non-anchor SMF) may be made, for example, via SEPP. Signaling transmission and reception between the anchor SMF and the non-anchor SMF may be made via SEPP.
[0136] The QoS monitoring request may be made by an Application Function (AF). The AF may make the QoS monitoring request for the non-anchor NW via the anchor NW or directly to the non-anchor NW. The request from the AF may be made to the PCF of the anchor NW and / or the non-anchor NW, or to a Network Exposure Function (NEF) (see Non-Patent Document 10), or may be made to the PCF via the NEF.
[0137] A QoS monitoring request from the anchor SMF to the non-anchor NW device may be made at the time of PDU session establishment or at the time of PDU session modification. For example, information about the request may be included in the signaling of a PDU session establishment request or may be included in the signaling of a PDU session modification request. For example, Nsmf_PDUSession_Establish_Request (see Non-Patent Document 31) may be used for the signaling of a PDU session establishment request. For example, Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31) may be used for the signaling of a PDU session modification request.
[0138] The non-anchor SMF may request QoS monitoring from the UPF. The request from the non-anchor SMF to the UPF may be triggered, for example, by a QoS monitoring request from the anchor SMF to the non-anchor SMF, or may be made by the non-anchor SMF voluntarily. The UPF may be, for example, an intermediate UPF (a UPF that is not an anchor UPF). The intermediate UPF may be an intermediate UPF (e.g., UPF #2 shown in FIG. 11) belonging to the non-anchor NW. The UPF may perform QoS monitoring in response to the request.
[0139] The non-anchor SMF may request QoS monitoring from the base station. The base station may, for example, be a base station belonging to the same NW as the non-anchor SMF. The request from the non-anchor SMF to the base station may, for example, be made via an AMF (hereinafter sometimes referred to as a non-anchor AMF) belonging to the same NW as the non-anchor SMF. The request from the non-anchor SMF to the base station may, for example, be made in response to a QoS monitoring request from the anchor SMF to the non-anchor SMF, or may be made autonomously by the non-anchor SMF. The base station may perform QoS monitoring in response to the request.
[0140] The anchor NW may determine information regarding QoS monitoring in each NW, for example, a QoS monitoring policy. Each NW may include an anchor NW or a non-anchor NW. For example, the PCF of the anchor NW (hereinafter, may be referred to as the anchor PCF) may determine the information. As another example, the AF may determine the information regarding QoS monitoring. The AF may notify the anchor PCF of the information. The anchor SMF may obtain the information from the anchor PCF. The anchor SMF may determine the QoS monitoring configuration using the QoS monitoring policy. For example, the anchor SMF may determine which device will perform QoS monitoring.
[0141] The QoS monitoring policy may include, for example, information disclosed in 3GPP TS 23.503, Section 6.1.3.21, such as information about QoS parameters, reporting periodicity, and conditions that trigger reporting (e.g., thresholds, minimum waiting time before subsequent reports).
[0142] As another example of determining information related to QoS monitoring in each NW, the non-anchor NW may determine information related to QoS monitoring in the non-anchor NW, such as a QoS monitoring policy. For example, the PCF of the non-anchor NW (hereinafter, sometimes referred to as the non-anchor PCF) may determine the information. As another example, the AF may determine information related to QoS monitoring in the non-anchor NW. The AF may notify the non-anchor PCF of the information. The non-anchor SMF may obtain the information from the non-anchor PCF. The AF may be present in the DN, the anchor NW, or the non-anchor NW.
[0143] The anchor NW may decide which NW will determine the QoS monitoring configuration in each NW. For example, the anchor NW may decide which NW will determine the QoS monitoring configuration in a non-anchor NW. The anchor SMF may notify the non-anchor SMF of a QoS monitoring request including information indicating which NW will perform the QoS monitoring configuration. The non-anchor SMF may use the information to determine which NW will perform the QoS monitoring configuration. For example, the non-anchor SMF may notify the non-anchor PCF of the QoS monitoring configuration determined by the anchor NW upon receiving information indicating that the anchor NW will perform QoS monitoring configuration, or may request the non-anchor PCF to perform QoS monitoring configuration upon receiving information indicating that the non-anchor NW will perform QoS monitoring configuration. This makes it possible to prevent, for example, conflict between QoS monitoring settings determined in the anchor network and QoS monitoring settings determined in the non-anchor network, and as a result, to prevent malfunctions related to QoS monitoring.
[0144] As another example, it may be possible to determine which NW will perform the QoS monitoring configuration based on whether or not a QoS monitoring configuration is included in a QoS monitoring request from the anchor SMF to the non-anchor SMF. For example, the anchor NW may determine the QoS monitoring configuration based on the QoS monitoring configuration being included in the request, or the non-anchor NW may determine the QoS monitoring configuration based on the QoS monitoring configuration not being included in the request. The non-anchor SMF may determine that the QoS monitoring configuration determined by the anchor NW will be used based on the QoS monitoring configuration being included in the request, or may determine that the non-anchor NW will perform the QoS monitoring configuration based on the QoS monitoring configuration not being included in the request. This, for example, makes it possible to reduce the size of the signaling of the QoS monitoring request.
[0145] As another example of determining the QoS monitoring setting in each NW, both NWs may determine the QoS monitoring setting, which can avoid complexity in the communication system, for example.
[0146] Which NW determines the QoS monitoring setting has priority may be defined by a standard. For example, the QoS monitoring setting determined by the anchor NW may have priority over the QoS monitoring setting determined by the non-anchor NW, or the QoS monitoring setting determined by the non-anchor NW may have priority over the QoS monitoring setting determined by the anchor NW.
[0147] The following (1) to (10) are disclosed as examples of information included in the QoS monitoring settings.
[0148] (1) Information about the conditions that trigger QoS monitoring reporting.
[0149] (2) Information regarding the type of QoS to be monitored.
[0150] (3) Information about the UE.
[0151] (4) Information about the PDU session.
[0152] (5) Information about QoS flows.
[0153] (6) Information about the entity performing QoS monitoring.
[0154] (7) Information about the entity that performs network failure detection.
[0155] (8) Information about QoS monitoring policies.
[0156] (9) Information regarding uplink / downlink.
[0157] (10) A combination of the above (1) to (9).
[0158] The above-mentioned (1) may include, for example, information indicating that reporting is to be performed periodically, or information indicating that reporting is to be performed in response to a predetermined event.
[0159] The above (1) may include information about the reporting period, which, for example, makes it possible to prevent unnecessary reporting and, as a result, reduce the amount of signaling in the communication system.
[0160] The above-mentioned (1) may include information about the event. The event may be the QoS falling below a predetermined threshold, the QoS being equal to or less than a predetermined threshold, the QoS being above a predetermined threshold, or the QoS being equal to or more than a predetermined threshold. For example, the above-mentioned (1) may include information about the threshold of the event. Information about the period for measuring the QoS may also be included. Including information about the period for measuring the QoS makes it possible to prevent, for example, excessive reporting of QoS monitoring results.
[0161] The aforementioned (2) may be, for example, packet delay, congestion, data rate, packet delay variation, or packet round-trip delay. The packet delay may be, for example, upstream packet delay or downstream packet delay. The packet delay variation may be, for example, packet delay variance or packet delay standard deviation.
[0162] The above (3) may be, for example, information about a UE related to data to be monitored for QoS. The information may be information about a UE receiving the data, or information about a UE transmitting the data. The above (3) may include, for example, information for identifying a UE. This allows, for example, the UPF to quickly identify data traffic to be monitored for QoS.
[0163] The above (4) may be PDU session information related to data subject to QoS monitoring. The above (4) may include, for example, information for identifying the PDU session. This provides, for example, the same effects as those described above.
[0164] The above-mentioned (5) may be, for example, information on the QoS flow related to the data to be monitored. The above-mentioned (5) may include, for example, information for identifying the QoS flow. This may provide, for example, the same effect as described above.
[0165] The above-mentioned (6) may include, for example, information about the UPF, base station, and / or UE that performs QoS monitoring. The above-mentioned (6) may include, for example, information identifying the UPF, the base station, or the UE. This allows, for example, the UPF, the base station, and / or the UE to quickly recognize that their own devices are performing QoS monitoring.
[0166] As examples of the above-mentioned (7), the following (7-1) to (7-3) are disclosed.
[0167] (7-1) Information indicating that the anchor network detects network failures.
[0168] (7-2) Information indicating that a non-anchor network detects network failures.
[0169] (7-3) Information indicating that a failure in the own network is detected in the own network.
[0170] The above (7-1) may include information indicating which NF performs the detection. For example, it may include information indicating that the anchor SMF performs the detection, or that the anchor AMF (AMF belonging to the same NW as the anchor SMF) performs the detection, or that the anchor UPF performs the detection. A non-anchor NW, for example, a non-anchor SMF, may notify the anchor NW, for example, the anchor SMF, of a QoS monitoring report using the information in the above (7-1). The QoS monitoring report notified by the non-anchor NW device may be, for example, a QoS monitoring report received from the UPF of its own NW. This enables, for example, rapid NW failure detection in the anchor NW.
[0171] The above (7-2) may include information indicating which NF performs the detection. For example, it may include information indicating that a non-anchor SMF performs the detection, or information indicating that a non-anchor AMF performs the detection, or information indicating that a UPF of the non-anchor NW performs the detection. The anchor NW, for example, the anchor SMF, may notify the non-anchor NW, for example, the non-anchor SMF, of a QoS monitoring report using the information in the above (7-2). The QoS monitoring report notified by the anchor NW device may be, for example, a QoS monitoring report received from the UPF of its own NW. This enables, for example, rapid NW failure detection in the non-anchor NW.
[0172] The above (7-3) makes it possible to avoid complexity in a communication system, for example.
[0173] The above-mentioned (8) may include, for example, a QoS monitoring policy determined by the anchor PCF. The non-anchor SMF may notify the non-anchor PCF of the information in the above-mentioned (8). This makes it possible to prevent, for example, a discrepancy in the QoS monitoring policy between the anchor NW and the non-anchor NW, and as a result, to prevent malfunctions related to QoS monitoring.
[0174] The above (9) may include, for example, information indicating whether the traffic to be monitored is upstream or downstream. The non-anchor network device may use this information to perform QoS monitoring of the upstream and / or downstream traffic. This may improve the efficiency of QoS monitoring, for example.
[0175] The non-anchor SMF may request QoS monitoring from the intermediate UPF. The request may include, for example, the information (1) to (10) described above. The intermediate UPF may start QoS monitoring in response to the request.
[0176] The non-anchor SMF may request QoS monitoring from a non-anchor base station (a base station of a non-anchor network). The request may include, for example, the information (1) to (10) described above. The non-anchor base station may start QoS monitoring in response to the request.
[0177] Fig. 12 is a sequence diagram showing an example of the setting operation of QoS monitoring. Fig. 12 shows a sequence example of the setting operation in the communication system having the configuration shown in Fig. 11. That is, in the example shown in Fig. 12, base station #1, AMF #1, UPF #1, SMF #1, PCF #1, UDM #1, and anchor UPF belong to NW1090, and base station #2, AMF #2, UPF #2, SMF #2, PCF #2, and UDM #2 belong to NW1091. The same applies to figures showing other sequence examples. In the example shown in Fig. 12, QoS monitoring is set for UPF #1, anchor UPF, and UPF #2. Fig. 12 shows a case where the setting related to QoS monitoring is determined in the anchor NW. In the example of Fig. 12, a QoS monitoring request is made simultaneously with PDU session establishment, but the QoS monitoring request may be made simultaneously with PDU session change, or a PDU session change may be made for the QoS monitoring request. In the example shown in Fig. 12, PDU sessions are established in both NW1090 and NW1091.
[0178] 12, a procedure 1100 is performed to establish a connection with the UPF in the NW 1090. The procedure 1100 will be described below. Fig. 13 is a sequence diagram showing an example of the procedure 1100 in Fig. 12.
[0179] In step ST1101 shown in Fig. 13, SMF#1 selects a UPF. In the example shown in Fig. 13, SMF#1 selects UPF#1 and determines to use UPF#1.
[0180] In step ST1102 shown in FIG. 13 , a procedure for establishing a session management policy association is performed between SMF#1 and PCF#1. This procedure may be, for example, the procedure disclosed in clause 4.16.4 of non-patent document 31 (3GPP TS 23.502). In step ST1102, SMF#1 may request a QoS monitoring policy from PCF#1. PCF#1 may notify SMF#1 of the QoS monitoring policy. In step ST1102, a procedure for changing the session management policy association may be performed. The procedure for changing the session management policy association may be, for example, the procedure disclosed in clause 4.16.5 of non-patent document 31 (3GPP TS 23.502). SMF#1 may determine the QoS monitoring configuration using the QoS monitoring policy from PCF#1.
[0181] In step ST1104 shown in FIG. 13 , SMF#1 requests the anchor UPF to establish an N4 session. The anchor UPF establishes the N4 session in response to step ST1104. In step ST1105, the anchor UPF responds to step ST1104 to SMF#1.
[0182] In step ST1107 shown in Fig. 13, SMF#1 requests UPF#1 to establish an N4 session. Step ST1107 triggers UPF#1 to establish an N4 session. In step ST1108, UPF#1 responds to step ST1107 to SMF#1. In steps ST1107 and ST1108, a request to change the N4 session and a response to the request may be made.
[0183] Returning to the description of FIG. 12 , in step ST1110 shown in FIG. 12 , SMF#1 requests SMF#2 to establish a PDU session. The request may be a request for modifying a PDU session. The request may include information about the QoS monitoring policy or information about the QoS monitoring configuration. The request may include the information (1) to (10) described above, information about the anchor UPF, information about the PDU session, for example, information about the PDU session to be established, or information about the QoS flow, for example, information about the QoS flow to be established. In step ST1110, signaling of Nsmf_PDUSession_Establishment_Request (see Non-Patent Document 31) or signaling of Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31) may be used. SMF#2 may start an operation for establishing a PDU session or an operation for modifying a PDU session, triggered by step ST1110.
[0184] 12, a PDU session is established in the NW 1090. A PDU session change may also be performed in the NW 1090. Procedure 1111 will be described below. FIG. 14 is a sequence diagram showing an example of procedure 1111 in FIG. 12.
[0185] In steps ST1113 and ST1114 shown in FIG. 14 , information required for establishing a PDU session for the UE is transmitted and received between SMF#1 and AMF#1. Information required for modifying a PDU session may also be transmitted and received. In step ST1113, an instruction to establish a PDU session may be sent from SMF#1 to AMF#1, or an instruction to modify a PDU session may be sent. The instruction may include the above-mentioned information. The information may include information about the UE, information about the PDU session, information about the QoS flow, information about the UPF, or information about QoS monitoring configuration.
[0186] In step ST1116 shown in FIG. 14 , AMF #1 notifies base station #1 of a PDU session establishment request for the UE. The notification may be a PDU session modification request. The notification may include QoS monitoring configuration. In step ST1117, base station #1 notifies the UE of a PDU session establishment request. The notification may include a PDU session modification request. RRC signaling, for example, RRC establishment signaling or RRC reconfiguration signaling may be used in step ST1117. The notification in step ST1117 may include QoS monitoring configuration. The UE may perform PDU session establishment processing or PDU session modification processing using the content of the notification in step ST1117.
[0187] In step ST1118 shown in Fig. 14, the UE responds to step ST1117 to the base station #1. For the response, RRC signaling, for example, signaling indicating RRC establishment completion or signaling indicating RRC reconfiguration completion may be used. In step ST1119, the base station #1 responds to step ST1116 to the AMF #1. The response in step ST1119 may include N2 session management information.
[0188] In step ST1121 shown in Fig. 14, AMF#1 notifies SMF#1 of the N2 session management information from base station#1. This notification may be performed, for example, using signaling of Nsmf_PDUSession_UpdateSMContext Request (see Non-Patent Document 31). In step ST1122, SMF#1 responds to step ST1121 to AMF#1. This response may be performed, for example, using signaling of Nsmf_PDUSession_UpdateSMContext Response (see Non-Patent Document 31).
[0189] In step ST1124 shown in FIG. 14 , SMF#1 requests the anchor UPF to modify the N4 session. The request may include, for example, QoS monitoring configuration. The anchor UPF may start QoS monitoring using the configuration. In step ST1125, the anchor UPF sends a response to step ST1124 to SMF#1.
[0190] In step ST1128 shown in FIG. 14, SMF#1 requests UPF#1 to modify the N4 session. The request may include, for example, QoS monitoring settings. UPF#1 may start QoS monitoring using the settings. In step ST1129, UPF#1 responds to step ST1128 to SMF#1.
[0191] In step ST1131 shown in FIG. 14, the UE notifies the base station #1 of an acknowledgment to the PDU session establishment request. An acknowledgment to the PDU session modification request may also be notified. This notification may be triggered by the completion of PDU session establishment and / or modification. In step ST1132, the base station #1 notifies the AMF #1 of information related to the acknowledgment. The notification in step ST1132 may include N2 session management information.
[0192] In steps ST1133 and ST1134 shown in FIG. 14, the same processing as in steps ST1121 and ST1122 is performed.
[0193] In steps ST1136 and ST1137 shown in FIG. 14, the same processing as in steps ST1124 and ST1125 is performed.
[0194] In steps ST1138 and ST1139 shown in FIG. 14, the same processing as in steps ST1128 and ST1129 is performed.
[0195] 14, a procedure for changing a session management policy association is performed between the SMF#1 and the PCF#1. This procedure may be, for example, the procedure disclosed in Section 4.16.5 of Non-Patent Document 31 (3GPP TS23.502).
[0196] Returning to the description of Fig. 12, a procedure 1150 shown in Fig. 12 performs a process of establishing a connection with the UPF in the NW 1091. The procedure 1150 will be described below. Fig. 15 is a sequence diagram showing an example of the procedure 1150 in Fig. 12.
[0197] In step ST1151 shown in FIG. 15 , SMF#2 selects a UPF. In the example shown in FIG. 15 , SMF#2 selects UPF#2 and decides to use the selected UPF#2. In step ST1152, a session management policy association establishment process is performed between SMF#2 and PCF#2. This procedure may be, for example, the procedure disclosed in clause 4.16.4 of non-patent document 31 (3GPP TS 23.502). In step ST1152, SMF#2 may notify PCF#2 of the QoS monitoring policy notified by SMF#1 in step ST1110. In step ST1152, a session management policy association change procedure may be performed. The session management policy association change procedure may be, for example, the procedure disclosed in clause 4.16.5 of non-patent document 31 (3GPP TS 23.502).
[0198] In steps ST1154 and ST1155 shown in FIG. 15, the same processes as in steps ST1107 and ST1108 of procedure 1100 shown in FIG. 13 are performed between SMF#2 and UPF#2.
[0199] Returning to the description of Fig. 12, in step ST1158 shown in Fig. 12, SMF#2 notifies SMF#1 of information related to the intermediate UPF. In the example shown in Fig. 12, SMF#2 may notify SMF#1 of information related to UPF#2.
[0200] In steps ST1159 and ST1160 shown in Fig. 12, the same processes as in steps ST1124 and ST1125 of procedure 1111 shown in Fig. 14 are performed. In step ST1159, a connection request with UPF#2 may be transmitted. The anchor UPF may establish a connection with UPF#2 upon receiving step ST1159.
[0201] 12, a PDU session is established in the NW 1091. A PDU session change may also be performed in the NW 1091. Procedure 1161 will be described below. FIG. 16 is a sequence diagram showing an example of procedure 1161 in FIG. 12.
[0202] In steps ST1163 to ST1174 shown in FIG. 16, processing similar to steps ST1113 to ST1122 of procedure 1111 shown in FIG. 14 is performed in SMF#2, AMF#2, base station #2, and UE.
[0203] In steps ST1178 and ST1179 shown in FIG. 16, the same processes as in steps ST1128 and ST1129 of procedure 1111 shown in FIG. 14 are performed between SMF#2 and UPF#2.
[0204] In steps ST1181 to ST1184 shown in FIG. 16, processing similar to steps ST1131 to ST1134 of procedure 1111 shown in FIG. 14 is performed in the UE, base station #2, AMF #2, and SMF #2.
[0205] In steps ST1188 to ST1190 shown in FIG. 16, the same processes as steps ST1138 to ST1140 of procedure 1111 shown in FIG. 14 are performed in UPF#2, SMF#2, and PCF#2.
[0206] Returning to the description of Fig. 12 , in step ST1191 shown in Fig. 12 , SMF #2 responds to SMF #1 with respect to the PDU session establishment request. A response to a PDU session modification request may also be sent. Step ST1191 may be performed as a response to step ST1110.
[0207] Step ST1191 shown in Fig. 12 may be performed after step ST1184 of procedure 1161 shown in Fig. 16. Step ST1191 may be performed before step ST1188 of procedure 1161 shown in Fig. 16. This enables, for example, SMF#2 to quickly respond to the establishment / modification of a PDU session.
[0208] 12, data is transmitted and received between the UE and the DN via the NW 1090. Step ST1192 indicates data transmission and reception between the UE and the base station #1, step ST1193 indicates data transmission and reception between the base station #1 and the UPF #1, step ST1194 indicates data transmission and reception between the UPF #1 and the anchor UPF, and step ST1195 indicates data transmission and reception between the anchor UPF and the DN.
[0209] 12, data is transmitted and received between the UE and the DN via the NW 1091. Step ST1196 indicates data transmission and reception between the UE and the base station #2, step ST1197 indicates data transmission and reception between the base station #2 and the UPF #2, step ST1198 indicates data transmission and reception between the UPF #2 and the anchor UPF, and step ST1199 indicates data transmission and reception between the anchor UPF and the DN.
[0210] A UPF of a non-anchor network, for example, an intermediate UPF, may send a QoS monitoring report to a non-anchor SMF. The UPF may send the QoS monitoring report when the condition (1) above is satisfied. For example, the N4 Session Report signaling (see Non-Patent Document 31) may be used for the report.
[0211] The base station may send a QoS monitoring report to the non-anchor SMF. The base station may send a QoS monitoring report, for example, when the above-mentioned condition (1) is satisfied. The report may be sent via the non-anchor AMF, for example.
[0212] The following (A) to (I) are disclosed as examples of information included in the report from the intermediate UPF and / or base station.
[0213] (A) Information about the entity that performs the QoS monitoring report.
[0214] (B) Information regarding QoS type.
[0215] (C) Information about the UE.
[0216] (D) Information about the PDU session.
[0217] (E) Information about QoS flows.
[0218] (F) Information about time.
[0219] (G) Information regarding uplink / downlink.
[0220] (H) Information about QoS monitoring measurements.
[0221] (I) A combination of the above (A) to (H).
[0222] The information (A) above may be, for example, information about the own UPF or information about the own base station, which enables, for example, the non-anchor SMF to quickly identify the location of the NW failure.
[0223] The above-mentioned information (B) to (E) may be, for example, the same information as the above-mentioned information (2) to (5).
[0224] The above-mentioned (F) may include, for example, information on a QoS type that satisfies the above-mentioned condition (1), or information on time, which enables, for example, the non-anchor SMF to know the time of occurrence of a network failure.
[0225] The above-mentioned (G) may include, for example, information indicating whether the traffic to be reported in the QoS monitoring report is upstream or downstream. This allows, for example, the anchor network device to quickly determine whether the traffic to be reported in the QoS monitoring report is upstream or downstream.
[0226] The above-mentioned (H) may include, for example, the measurement results of QoS monitoring, which allows, for example, the recipient of the QoS monitoring report to know the detailed measurement results of QoS monitoring.
[0227] The non-anchor SMF may send a QoS monitoring report to the anchor SMF. The report from the non-anchor SMF to the anchor SMF may be triggered by a QoS monitoring report from the UPF and / or the base station to the non-anchor SMF. The report from the non-anchor SMF to the anchor SMF may include the above-mentioned information (A) to (I), or may include information about the non-anchor NW, for example, information about the non-anchor SMF. By including information about the non-anchor NW in the report, it becomes possible to determine, for example, whether the report is from the anchor NW or the non-anchor NW, and as a result, it becomes possible to identify the location of a NW failure.
[0228] The anchor UPF may perform QoS monitoring. QoS monitoring by the anchor UPF may be triggered by a QoS monitoring request from the anchor SMF. In QoS monitoring between the anchor UPF and the UE, QoS that does not go through a non-anchor NW (i.e., goes through the anchor NW) and QoS that goes through the non-anchor NW may be monitored separately. A QoS monitoring request from the anchor SMF to the anchor UPF may include information about the NW that is passed through. A QoS monitoring report from the anchor UPF to the anchor SMF may include information about the NW that is passed through. This enables, for example, a device (or NF) that performs NW failure detection to quickly identify the failure location.
[0229] The anchor SMF may detect a network failure using the information contained in the report from the non-anchor SMF.
[0230] For example, the anchor SMF may detect a failure of the intermediate UPF of one of the networks when the QoS between the UE and the intermediate UPF of one of the networks is abnormal and the QoS between the UE and the anchor UPF via the other network is normal.
[0231] As another example, a failure of the intermediate UPF of one of the networks may be detected when the QoS between the UE and the intermediate UPF of one of the networks is abnormal and the QoS between the UE and the intermediate UPF of the other network is normal.
[0232] As another example, a failure of the anchor UPF may be detected when the uplink QoS between the UE and the intermediate UPF is normal and the QoS between the UE and the anchor UPF is abnormal.
[0233] As another example, a failure between the anchor UPF and the DN may be detected when the upstream QoS between the UE and the intermediate UPF and the upstream QoS between the UE and the anchor UPF are both normal, and the downstream QoS between the UE and the intermediate UPF and the downstream QoS between the UE and the anchor UPF are abnormal.
[0234] The intermediate UPF may be an intermediate UPF of the anchor network (e.g., UPF #1 shown in FIG. 11 ) or an intermediate UPF of the non-anchor network (e.g., UPF #2 shown in FIG. 11 ). The QoS abnormality mentioned above may be, for example, the QoS being equal to or greater than a predetermined threshold, or the QoS being equal to or less than a predetermined threshold. The normal QoS mentioned above may be, for example, the QoS not being abnormal. This enables, for example, the anchor SMF to identify the failure location in the event of a network failure.
[0235] Fig. 17 is a sequence diagram showing an example of the operation of detecting a network failure. Fig. 17 shows an example of a failure occurring in UPF #2. Fig. 17 shows an example of an anchor network performing failure detection. In Fig. 17, the same steps as in Fig. 12 are assigned the same step numbers, and common explanations will be omitted.
[0236] Steps ST1196 to ST1199 in FIG. 17 are the same as those in FIG.
[0237] In step ST1204 in FIG. 17 , the anchor UPF detects QoS deterioration. The anchor UPF may detect, for example, QoS deterioration of data from NW 1091. In step ST1205, the anchor UPF sends a QoS monitoring report to SMF#1. For example, the signaling of an N4 session report (see non-patent document 31) may be used for the report. In step ST1206, SMF#1 sends an acknowledgment of the report to the anchor UPF. For example, the signaling of an N4 session report acknowledgment (see non-patent document 31) may be used for the response.
[0238] In step ST1209 in FIG. 17 , UPF#2 detects QoS deterioration. UPF#2 may detect, for example, QoS deterioration of data passing through its own UPF. In step ST1210, UPF#2 sends a QoS monitoring report to SMF#2. For example, the same signaling as in step ST1205 may be used for this report. In step ST1211, SMF#2 sends a positive response to the report to UPF#2. For example, the same signaling as in step ST1206 may be used for this response.
[0239] In step ST1215 in FIG. 17, SMF#2 sends a QoS monitoring report to SMF#1. SMF#2 may send the report when it receives the information in (7-2) above from UPF#2. The report may include the information in step ST1210 or information about the UPF. The information about the UPF may be, for example, information about the UPF that sent the QoS monitoring report. In step ST1216, SMF#1 sends a response to the report to SMF#2. In the example shown in FIG. 17, the response may be a positive response.
[0240] In step ST1220 shown in Fig. 17, SMF#1 detects a network failure. In the example shown in Fig. 17, SMF#1 detects a failure of UPF#2. SMF#1 may detect the failure of UPF#2 by using the QoS monitoring report from the anchor UPF and the QoS monitoring report from UPF#2.
[0241] In Figure 17, an example of a failure occurring in UPF #2 is shown, but a failure may also occur between UPF #2 and the anchor UPF, or between UPF #2 and base station #2.
[0242] 17 shows an example in which step ST1216 is a positive response, but the response may be a negative response. SMF#2 may retransmit the QoS monitoring report in response to the negative response. This allows, for example, SMF#1 to correct an error in the report content, thereby enabling appropriate detection of a network failure.
[0243] Another solution is disclosed. A network failure is detected in a network where the network failure occurs. The network failure may be an anchor network or a non-anchor network. For example, the detection may be performed by an anchor SMF or a non-anchor SMF.
[0244] Each NW may determine information regarding QoS monitoring in that NW, for example, a QoS monitoring policy. For example, the PCF of that NW may determine the information. As another example, an Application Function (AF) may determine information regarding QoS monitoring. The AF may notify the PCF of that NW of the information. The SMF of that NW may acquire the QoS monitoring policy from the PCF of that NW as the information. A non-anchor NW may be included in the aforementioned NWs. The SMF of that NW may determine the QoS monitoring setting using the acquired QoS monitoring policy.
[0245] As another example, the anchor NW may determine information regarding QoS monitoring in the non-anchor NW. For example, the anchor PCF may determine the information. As another example, the AF may determine the information regarding QoS monitoring. The AF may notify the anchor PCF of the information. The anchor SMF may obtain the information from the anchor PCF. The anchor SMF may notify the information to a non-anchor NW device, for example, a non-anchor SMF.
[0246] The SMF of each NW may send a QoS monitoring request to the UPF of each NW. For example, the SMF of each NW may send the request to the UPF of its own NW. The request may include QoS monitoring settings. The request may include information related to the above-mentioned (1) to (10).
[0247] The SMF of each NW may send a QoS monitoring request to the base station of each NW. The request may be sent, for example, via the AMF of each NW. The request may include QoS monitoring settings. The request may include information related to the above items (1) to (10).
[0248] FIG. 18 is a sequence diagram showing another example of the QoS monitoring configuration operation. In the example shown in FIG. 18, QoS monitoring configuration is performed for UPF #1, anchor UPF, and UPF #2. FIG. 18 shows a case where the configuration related to QoS monitoring in a non-anchor NW is determined in the non-anchor NW. In the example shown in FIG. 18, a QoS monitoring request is performed simultaneously with PDU session establishment, but the QoS monitoring request may be performed simultaneously with PDU session change, or a PDU session change may be performed for the QoS monitoring request. In the example shown in FIG. 18, PDU sessions are established in both NW 1090 and NW 1091. In FIG. 18, the same processes as in FIG. 12 are assigned the same numbers, and common descriptions will be omitted.
[0249] The procedure 1100 in FIG. 18 is similar to that in FIGS.
[0250] In step ST1310 in FIG. 18 , SMF#1 requests SMF#2 to establish a PDU session. Step ST1310 may be, for example, a request to change a PDU session. The request may include information to the effect that the QoS monitoring policy and / or QoS monitoring setting will be determined in the NW 1091, or may not include the QoS monitoring policy and / or QoS monitoring setting. The request may include information about the UE, information about the anchor UPF, information about the PDU session, or information about the QoS flow. Step ST1310 may use the same signaling as step ST1110 in FIG. 12 . SMF#2 may start an operation to establish a PDU session or an operation to change a PDU session, triggered by step ST1310. SMF#2 may start an operation to determine the QoS monitoring setting in the NW 1091, triggered by step ST1310.
[0251] The procedure 1111 in FIG. 18 is similar to that in FIGS.
[0252] Step ST1151 in FIG. 18 is the same as in FIG. 12 and FIG.
[0253] In step ST1352 shown in FIG. 18 , a procedure for establishing a session management policy association is performed between SMF#2 and PCF#2. This procedure may be, for example, the procedure disclosed in section 4.16.4 of non-patent document 31 (3GPP TS23.502). In step ST1352, SMF#2 may request a QoS monitoring policy from PCF#2. This request may be triggered by step ST1310. The request for the QoS monitoring policy may be triggered, for example, by the request in step ST1310 including information indicating that the QoS monitoring policy and / or QoS monitoring setting is to be determined by the NW1091, or by the request in step ST1310 not including the QoS monitoring policy and / or QoS monitoring setting. PCF#2 may notify SMF#2 of the QoS monitoring policy. The SMF#2 may determine the QoS monitoring configuration using the QoS monitoring policy. In Step ST1352, a session management policy association change procedure may be performed. The session management policy association change procedure may be, for example, the procedure disclosed in Section 4.16.5 of Non-Patent Document 31 (3GPP TS23.502).
[0254] Steps ST1154 and ST1155 in FIG. 18 are the same as those in FIG. 12 and FIG.
[0255] Steps S1158 to S1160 in FIG. 18 are the same as those in FIG.
[0256] The procedure 1161 shown in FIG. 18 is similar to that shown in FIGS.
[0257] In step ST1386 shown in FIG. 18 , SMF#2 responds to the PDU session establishment request to SMF#1. A response to a PDU session modification request may also be sent. Step ST1386 may be sent as a response to step ST1310. The response in step ST1386 may include a QoS monitoring policy and / or a QoS monitoring setting. The QoS monitoring policy and / or the QoS monitoring setting may be, for example, the QoS monitoring policy determined by PCF#2 in step ST1352 or the QoS monitoring setting determined by SMF#2.
[0258] Steps ST1192 to ST1199 in FIG. 18 are the same as those in FIG.
[0259] The UPF of each NW may send a QoS monitoring report to the SMF of each NW. The UPF may send the QoS monitoring report when the condition (1) above is satisfied, for example. For the report, for example, N4 Session Report signaling (see Non-Patent Document 31) may be used.
[0260] The base station of each NW may send a QoS monitoring report to the SMF of each NW. The base station may send a QoS monitoring report, for example, when the above-mentioned condition (1) is satisfied. The report may be sent via the AMF of each NW, for example.
[0261] The report from each NW's UPF and / or base station to the SMF may include information similar to (A) to (I) above.
[0262] The non-anchor SMF may detect a network failure using the information included in the report. For example, the non-anchor SMF may detect a failure of the intermediate UPF when the QoS between the UE and the intermediate UPF is abnormal, or may detect a failure of the anchor UPF when the QoS between the UE and the intermediate UPF is normal and the QoS between the UE and the anchor UPF is abnormal. The intermediate UPF may be, for example, an intermediate UPF of a non-anchor network. The QoS abnormality may be, for example, the QoS being equal to or greater than a predetermined threshold, or the QoS being equal to or less than a predetermined threshold. The normal QoS may be, for example, the QoS being normal. This enables the non-anchor SMF to identify the location of a network failure.
[0263] The anchor SMF may send a QoS monitoring report to the non-anchor SMF. For example, the anchor SMF may send the report to the non-anchor SMF in response to a QoS monitoring report from the anchor UPF of its own network, or in response to the absence of QoS monitoring from the intermediate UPF, or in response to both of the above. The non-anchor SMF may detect a network failure using the information included in the report. This allows the non-anchor SMF to detect a failure of only the intermediate UPF of the non-anchor network, for example.
[0264] Fig. 19 is a sequence diagram showing another example of the operation of detecting a network failure. Fig. 19 shows an example of a failure occurring in UPF #2. Fig. 19 shows an example of a non-anchor network detecting a failure. In Fig. 19, the same step numbers are assigned to processes similar to those in Fig. 12 and Fig. 17, and common explanations will be omitted.
[0265] Steps ST1196 to ST1199 in FIG. 19 are the same as those in FIG.
[0266] Steps ST1204 to ST1211 in FIG. 19 are the same as those in FIG.
[0267] In step ST1415 in FIG. 19, SMF#1 sends a QoS monitoring report to SMF#2. SMF#1 may send the report triggered by transmitting the information of (7-2) described above to SMF#2. The report may include the information reported in step ST1205, information about the UPF, or information about the network via which the QoS monitoring report from the anchor UPF passes. The information about the UPF may be, for example, information about the UPF that sent the QoS monitoring report. In step ST1416, SMF#2 sends a response to the report to SMF#1. In the example shown in FIG. 19, the response may be a positive response.
[0268] In step ST1420 shown in Fig. 19 , SMF#2 detects a network failure. In the example shown in Fig. 19 , SMF#2 detects a failure of UPF#2. SMF#2 may detect the failure of UPF#2 by using the QoS monitoring report from the anchor UPF and the QoS monitoring report from UPF#2.
[0269] In step ST1425 shown in Fig. 19 , SMF#2 may notify SMF#1 of information related to the network failure. The notification may include information related to the failure location, information related to the PDU session, or information related to the QoS flow. In the example shown in Fig. 19 , the information related to the failure location may be information related to UPF#2. SMF#1 may become aware of the network failure with step ST1425 as a trigger.
[0270] In Figure 19, an example of a failure occurring in UPF #2 is shown, but a failure may also occur between UPF #2 and the anchor UPF, or between UPF #2 and base station #2.
[0271] 19 shows an example in which step ST1416 is a positive response, but the response may be a negative response. SMF#1 may retransmit the QoS monitoring report in response to the negative response. This allows, for example, SMF#2 to correct an error in the report content, thereby enabling appropriate detection of a network failure.
[0272] A PDU session change request to the UE may be made from the anchor NW. For example, the anchor NW may notify information about a PDU session passing through a non-anchor NW.
[0273] A non-anchor NW, for example, a non-anchor SMF, may notify an anchor NW, for example, an anchor SMF, of information regarding a PDU session modification of a UE. For example, signaling of Nsmf_PDUSession_Modification_Response (see Non-Patent Document 31) may be used for the notification. For example, information regarding NAS signaling (hereinafter, sometimes referred to as NAS signaling information) may be included in the notification. For example, the NAS signaling may be NAS signaling related to the PDU session modification. For example, the NAS signaling may be NAS signaling from the non-anchor AMF to the UE.
[0274] The non-anchor SMF may request NAS signaling information from the non-anchor AMF. The NAS signaling may be, for example, NAS signaling related to PDU session modification. The non-anchor AMF may notify the non-anchor SMF of the NAS signaling information. The notification from the non-anchor AMF to the non-anchor SMF may be triggered by the request from the non-anchor SMF to the non-anchor AMF.
[0275] The NAS signaling may include information related to RRC signaling (hereinafter may be referred to as RRC signaling information). The RRC signaling may be, for example, RRC signaling related to a PDU session change. The RRC signaling may be RRC signaling from a non-anchor base station to a UE. The non-anchor AMF may request RRC signaling information from the non-anchor base station. The non-anchor base station may notify the non-anchor AMF of the RRC signaling information. The notification from the non-anchor base station to the non-anchor AMF may be triggered by the request from the non-anchor AMF to the non-anchor base station.
[0276] A QoS monitoring request from an anchor NW (e.g., anchor SMF) to a non-anchor NW (e.g., non-anchor NW) may include information indicating that a PDU session change request to the UE is sent from the anchor NW. Upon receiving the information, the non-anchor NW (e.g., non-anchor SMF) may notify the anchor NW (e.g., anchor SMF) of information regarding the PDU session change of the UE.
[0277] The anchor SMF may notify the anchor AMF of the PDU session change. The anchor AMF may notify the UE of the PDU session change. The notification may be performed via the base station of the anchor NW (hereinafter sometimes referred to as the anchor base station). The UE may change the PDU session setting of its own UE based on the notification.
[0278] The notification from the anchor SMF to the anchor AMF may be triggered by notification of information regarding a PDU session request from a non-anchor SMF to the anchor SMF. The notification from the anchor SMF to the anchor AMF may include information regarding NAS signaling. The NAS signaling may include NAS signaling in the anchor NW or may include NAS signaling in the non-anchor NW. This enables, for example, the UE to change PDU session settings for the anchor NW and the non-anchor NW, thereby improving communication efficiency in the communication system.
[0279] 20, 21, and 22 are sequence diagrams showing another example of the QoS monitoring configuration operation. FIG. 20 shows the beginning of the sequence, FIG. 21 shows the middle part of the sequence, and FIG. 22 shows the end part of the sequence. FIGS. 20, 21, and 22 show a series of operations (QoS monitoring configuration operations). In the examples shown in FIGS. 20, 21, and 22, QoS monitoring is configured for UPF #1, anchor UPF, and UPF #2. FIGS. 20, 21, and 22 show a case where the QoS monitoring configuration is determined in the anchor NW. In the examples shown in FIGS. 20, 21, and 22, a QoS monitoring request is made simultaneously with PDU session establishment, but a QoS monitoring request may be made simultaneously with a PDU session change, or a PDU session change may be made for a QoS monitoring request. In the examples shown in FIGS. 20, 21, and 22, PDU sessions are established in both NW 1090 and NW 1091. 20, 21, and 22, a PDU session establishment / modification request from the NW 1091 to the UE is notified from the NW 1190. In Fig. 20, 21, and 22, the same processes as those in Fig. 12 are assigned the same numbers, and common explanations will be omitted.
[0280] The procedure 1100 shown in FIG. 20 is similar to that shown in FIGS.
[0281] In step ST1510 shown in Fig. 20, SMF #1 requests SMF #2 to establish a PDU session. The request may include information indicating that a PDU session establishment / modification request to the UE is sent from the anchor NW, or may include information similar to the above-mentioned information included in the request transmitted in step ST1110 shown in Fig. 12. Step ST1510 may use the same signaling as that in step ST1110 shown in Fig. 12.
[0282] Steps ST1151 to ST1160 shown in FIG. 20 are the same as those in FIGS.
[0283] In step ST1563 shown in FIG. 20 , SMF#2 requests NAS signaling information from AMF#2. The NAS signaling may be, for example, NAS signaling related to PDU session establishment / modification. In step ST1566, AMF#2 requests RRC signaling information from base station#2. The RRC signaling may be, for example, RRC signaling related to PDU session establishment / modification. In step ST1567, base station#2 notifies AMF#2 of the RRC signaling information. In step ST1568, AMF#2 notifies SMF#2 of the NAS signaling information. Step ST1568 may include the RRC signaling information notified from base station#2 in step ST1567.
[0284] In step ST1570 shown in FIG. 20 , SMF#2 notifies SMF#1 of information related to the PDU session change. The notification may be made by a NAS signaling transmission request, or the request may be included in the notification. Information related to the NAS signaling may be included in the notification and / or the request. The information related to the NAS signaling may include the information notified in step ST1568.
[0285] In steps ST1513 and ST1114 shown in Fig. 21, the same processes as in steps ST1113 and ST1114 shown in Fig. 12 and Fig. 14 are performed. The signaling in step ST1513 may include NAS signaling information included in the request received in step ST1570 or may include RRC signaling information.
[0286] In steps ST1516 and ST1517 shown in Fig. 21, the same processes as in steps ST1116 and ST1117 shown in Fig. 12 and 14 are performed. Steps ST1516 and ST1517 may include NAS signaling information or RRC signaling information included in the request received in step ST1570.
[0287] In steps ST1518 to ST1521 shown in Fig. 21, the same processes as in steps ST1118 to ST1121 shown in Fig. 12 and Fig. 14 are performed. In step ST1518, the UE may include RRC signaling for base station #2 or NAS signaling for AMF #2. In steps ST1519 and ST1521, the UE may include RRC signaling for base station #2 or NAS signaling for AMF #2.
[0288] Step ST1122 shown in FIG. 21 is the same as that in FIGS.
[0289] In Step ST1571 shown in FIG. 21 , SMF#1 responds to the NAS signaling transmission request from SMF#2. This response may be sent as a response to Step ST1570. Step ST1571 may include RRC signaling for base station #2 or NAS signaling for AMF#2.
[0290] In Step ST1572 shown in Fig. 21 , SMF#2 transfers NAS signaling to AMF#2. The NAS signaling may include RRC signaling for base station #2 included in the response in Step ST1571, or may include NAS signaling for AMF#2. In Step ST1572, AMF#2 acquires the NAS signaling from the UE.
[0291] In Step ST1573 shown in FIG. 21 , AMF#2 transfers RRC signaling to base station#2. This RRC signaling may be, for example, the RRC signaling for base station#2 included in Step ST1571. In Step ST1573, base station#2 acquires the RRC signaling from the UE.
[0292] In step ST1574 shown in FIG. 21, base station #2 sends a response to step ST1573 to AMF #2. In step ST1575, AMF #2 sends a response to step ST1572 to SMF #2.
[0293] Steps ST1178 and ST1179 shown in FIG. 21 are the same as those in FIGS.
[0294] Steps ST1124 to ST1129 shown in FIG. 21 are the same as those in FIGS.
[0295] In steps ST1531 to ST1533 shown in Fig. 21, the same processes as in steps ST1131 to ST1133 shown in Fig. 12 and Fig. 14 are performed. In step ST1531, the UE may include RRC signaling for base station #2 or NAS signaling for AMF #2. In steps ST1532 and ST1533, the UE may include RRC signaling for base station #2 or NAS signaling for AMF #2.
[0296] Step ST1134 shown in FIG. 21 is the same as that shown in FIG. 12 and FIG.
[0297] In steps ST1585 to ST1589 shown in FIG. 22, the same processes as those in steps ST1571 to ST1575 in FIG. 21 are performed.
[0298] Steps ST1136 to ST1140 shown in FIG. 22 are the same as those in FIGS.
[0299] Steps ST1188 to ST1199 shown in FIG. 22 are the same as those in FIGS.
[0300] The network that determines the QoS monitoring policy and the network that determines the QoS monitoring setting may be the same, which makes it possible to avoid complexity in the communication system, for example.
[0301] As another example, the NW that determines the QoS monitoring policy and the NW that determines the QoS monitoring configuration may be different. For example, the QoS monitoring policy may be determined by the anchor NW (e.g., anchor PCF), and the QoS monitoring configuration may be determined by the non-anchor NW (e.g., non-anchor SMF). The QoS monitoring policy may be determined by the anchor NW (e.g., anchor PCF), and the QoS monitoring configuration may be determined by the non-anchor NW (e.g., non-anchor SMF). The anchor SMF may notify the non-anchor SMF of the QoS monitoring policy. This notification may be included in, for example, step ST1110 in FIG. 12 . The non-anchor SMF may determine the QoS monitoring configuration using the QoS monitoring policy. The non-anchor SMF may notify an intermediate UPF and / or a base station in its own NW of the QoS monitoring configuration. This makes it possible to determine QoS monitoring settings in each network while avoiding inconsistencies in QoS monitoring policies between networks, thereby improving flexibility in QoS monitoring.
[0302] The QoS monitoring report may be sent to the NWDAF. The NWDAF may be, for example, the NWDAF of the anchor NW. The report to the NWDAF may be made by the SMF, the AMF, the UPF, or the base station. The NWDAF may use the report to detect a network failure or the location of the network failure. The NWDAF may use the report to change the network configuration. This makes it possible to change the network configuration according to the state of the network failure, for example, and as a result, the robustness of the communication system can be improved.
[0303] The QoS monitoring setting for the base station may be performed directly from the SMF, and the QoS monitoring report from the base station may be performed directly to the SMF. An interface between the base station and the SMF may be provided. This may, for example, reduce the amount of processing by the AMF.
[0304] The NW that performs the NW fault detection and the NW that determines the QoS monitoring policy may be the same. The NW that performs the NW fault detection and the NW that determines the QoS monitoring setting may be the same. This makes it possible to avoid complexity in the communication system, for example.
[0305] As another example, a network that performs network failure detection may be different from a network that determines a QoS monitoring policy, or a network that performs network failure detection may be different from a network that determines a QoS monitoring setting. This makes it possible to improve flexibility in a communication system, for example.
[0306] The network that detects the network failure may differ depending on the form of the PDU session. For example, when a PDU session is configured to branch to multiple networks, an anchor network device (e.g., anchor SMF) may detect the network failure. As another example, when a PDU session is configured to switch between networks, the network failure may be detected in each network. This makes it possible to avoid, for example, complexity in the communication system.
[0307] According to the first embodiment, it becomes possible to grasp the location of a network failure in a communication system, and as a result, it becomes possible to perform recovery from the network failure.
[0308] Modification 1 of the First Embodiment: A failure of the Uu interface may be detected. For example, a failure of the Uu interface may be detected when the UE is connected to a plurality of networks.
[0309] The UE may detect a failure of the Uu interface, for example, using a method similar to that used to detect a Radio Link Failure (RLF).
[0310] The UE may notify the base station of the failure of the Uu interface. The notification from the UE may be made to a base station of a network where no failure occurs. The base station may be an anchor base station or a non-anchor base station. The notification from the UE to the base station may use RRC signaling, MAC signaling, or L1 / L2 signaling. The notification may include information about the UE, information about the network where the failure occurred, information about the PDU session, or information about the QoS flow.
[0311] The base station may notify the AMF of the information from the UE. As another example, the base station may notify the SMF of the information from the UE. The notification from the base station to the SMF may be performed via the AMF or directly.
[0312] As another example, the UE may notify the AMF of a failure of the Uu interface. For example, NAS signaling may be used for the notification from the UE to the AMF. The notification from the UE may be made to an AMF of a NW where no failure occurs. The AMF may be an anchor AMF or a non-anchor AMF. The notification may include information about the UE, information about the base station, information about the NW where the failure occurs, information about the PDU session, or information about the QoS flow. The notification may be made via the base station.
[0313] The AMF may notify the SMF of information regarding the UE's Uu interface failure. The notification may include, for example, information similar to the information included in the notification of the Uu interface failure from the UE. The SMF to which the notification is sent may be, for example, an SMF in the same network as the AMF. The notification may be performed, for example, by transferring the above-mentioned information from the UE to the AMF. The SMF may recognize the Uu interface failure based on the notification.
[0314] The SMF may notify an SMF of another NW of information regarding the Uu interface failure of the UE. The notification may include, for example, information similar to the information included in the notification of the Uu interface failure from the UE. The SMF of the other NW may be, for example, an SMF of a NW in which the Uu interface failure occurred, an SMF that detects the NW failure, or an anchor SMF. The notification may be performed, for example, by transferring the above-mentioned information from an AMF to an SMF. The SMF of the other NW may grasp the Uu interface failure in response to the notification. The SMF of the other NW may perform a NW recovery process in response to the notification. The process may be, for example, a method disclosed in embodiment 2 or later.
[0315] The SMF of another NW may notify the AMF of its own NW of information regarding the Uu interface failure of the UE. The notification may include, for example, information similar to the information included in the notification of the Uu interface failure from the UE. The notification may be performed, for example, by forwarding a notification of the above information to the SMF of the other NW. The AMF may recognize the Uu interface failure based on the information. The AMF may perform a process for restoring the connection with the UE based on the information. For example, the AMF may initiate a service request process. The process may be, for example, the process disclosed in Section 4.2.3.3 of Non-Patent Document 31 (3GPP TS23.502).
[0316] This first modification makes it possible to detect a Uu interface failure in the communication network, and as a result, it becomes possible to quickly execute processing for recovery from the Uu interface failure of the UE.
[0317] Second Embodiment In a second embodiment, a method for recovering from a network failure is disclosed.
[0318] Switching of the intermediate UPF may be performed. The intermediate UPF may be, for example, the intermediate UPF of the non-anchor NW. The switching may be performed, for example, when a failure of the intermediate UPF of the non-anchor NW is detected.
[0319] The switching process may be performed by a network device or an NF that detects a network failure. For example, the switching process may be performed by an SMF that detects a network failure. As another example, the network device or the NF that detects a network failure may request the SMF to perform the switching process.
[0320] The switching process may be initiated by the anchor NW. For example, the anchor SMF may initiate the switching process. The anchor SMF may request the non-anchor SMF to switch the UPF. The request may be made, for example, as a PDU session modification request. For example, the signaling of Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31) may be used for the request.
[0321] The request may include information about the failure of the intermediate UPF. The information may be included in the request as information about the reason, which allows, for example, a non-anchor SMF to quickly understand the occurrence of the intermediate UPF failure.
[0322] The non-anchor SMF may select a new intermediate UPF (hereinafter, may be referred to as a post-switching intermediate UPF). The non-anchor SMF may establish a connection with the post-switching intermediate UPF.
[0323] The non-anchor SMF may request the post-switching intermediate UPF to establish a connection. For example, the request may use signaling of an N4 Session Establishment Request (see Non-Patent Document 31). The request may include information about the UE, information about the PDU session, information about the QoS flow, information about the QoS monitoring disclosed in the first embodiment, or information about the anchor UPF. For example, including information about the anchor UPF enables the connection between the post-switching intermediate UPF and the anchor UPF to be quickly established.
[0324] The post-switching intermediate UPF may respond to the connection establishment request to the non-anchor SMF. For example, the response may use signaling of an N4 Session Establishment Response (see Non-Patent Document 31). The non-anchor SMF may recognize the completion of the connection of the post-switching intermediate UPF based on the response.
[0325] The non-anchor SMF may request a connection release from an intermediate UPF in which a failure is detected (hereinafter, sometimes referred to as a failed intermediate UPF). For example, the request may use N4 Session Release Request signaling (see Non-Patent Document 31). The request may include information about the UE, information about the PDU session to be released, or information about the QoS flow to be released. The failed intermediate UPF may use the information to release resources related to the PDU session and / or the QoS flow.
[0326] The failed intermediate UPF may respond to the non-anchor SMF in response to the connection release request. For example, the response may use signaling of an N4 Session Release Response (see Non-Patent Document 31). The non-anchor SMF may recognize the completion of the release of the failed intermediate UPF based on the response.
[0327] The communication NW may notify the UE of a change in the PDU session. The notification may be made, for example, from a NW in which intermediate UPF switching has been performed. For example, the non-anchor NW may notify the UE of a change in the PDU session. The notification may be made from a non-anchor AMF to the UE. The non-anchor SMF may request the non-anchor AMF to notify the UE. The notification may be made in response to the request.
[0328] The non-anchor SMF may respond to the UPF switching request to the anchor SMF. For example, the response may use signaling of Nsmf_PDUSession_Modification_Response (see Non-Patent Document 31). The response may include information about the post-switching intermediate UPF. This allows, for example, the anchor SMF to quickly determine the post-switching intermediate UPF.
[0329] The anchor SMF may notify the anchor UPF that the intermediate UPF has been switched, or may request switching of the connection with the intermediate UPF. The request may include information about the post-switching intermediate UPF, information about the UE, information about the PDU session, information about the QoS flow, or information about the QoS monitoring configuration disclosed in the first embodiment. For example, the request may use signaling of an N4 Session Modification Request (see Non-Patent Document 31). The anchor UPF may switch the connection with the intermediate UPF in response to the request. For example, the anchor UPF may release the N9 interface (see Non-Patent Document 10) between the failed intermediate UPF and the anchor UPF in response to the request, or may establish the N9 interface between the post-switching intermediate UPF and the anchor UPF in response to the request.
[0330] The anchor UPF may notify the anchor SMF of the completion of switching of the connection with the intermediate UPF. For example, the notification may be performed using signaling of an N4 Session Modification Response (see Non-Patent Document 31). The anchor SMF may recognize the completion of switching of the connection with the intermediate UPF based on the notification.
[0331] Fig. 23 is a sequence diagram showing an example of intermediate UPF switching operation in a non-anchor NW. Fig. 23 shows an example in which the anchor NW detects a NW failure and the anchor NW decides to switch the UPF. In the example shown in Fig. 23, the intermediate UPF of NW1091 switches from UPF#2-1 to UPF#2-2. In the example shown in Fig. 23, the same processes as those in Fig. 12 and Fig. 17 are assigned the same numbers, and common explanations will be omitted.
[0332] Steps ST1196 to ST1199 shown in FIG. 23 are the same as those in FIG.
[0333] Step ST1220 shown in FIG. 23 is the same as that in FIG.
[0334] In step ST1621 shown in FIG. 23, SMF#1 determines to switch the UPF.
[0335] In step ST1623 shown in Fig. 23 , SMF#1 requests SMF#2 to switch the UPF. The request may include information about a failure of an intermediate UPF, information about a request for UPF switching, information about the UE, information about a PDU session, or information about a QoS flow.
[0336] A process related to the post-switching intermediate UPF is performed in procedure 1625 shown in Fig. 23. The procedure 1625 will be described below. Fig. 24 is a sequence diagram showing an example of the procedure 1625 shown in Fig. 23.
[0337] Steps ST1151 and ST1152 shown in Fig. 24 are the same as steps ST1151 and ST1152 of procedure 1150 shown in Fig. 12 and 15. In step ST1151 shown in Fig. 24, SMF#2 selects UPF#2-2.
[0338] In step ST1654 shown in FIG. 24, SMF#2 requests UPF#2-2 to establish an N4 session. UPF#2-2 establishes the N4 session in response to step ST1654. In step ST1655, UPF#2-2 responds to step ST1654 to SMF#2.
[0339] In step ST1656 shown in FIG. 24, the SMF#2 requests the UPF#2-1 to release the N4 session. The UPF#2-1 releases the N4 session in response to step ST1656. In step ST1657, the UPF#2-1 responds to step ST1656 to the SMF#2.
[0340] Returning to the explanation of Fig. 23, steps ST1158 to ST1160 shown in Fig. 23 are the same as those in Fig. 12. In step ST1158 shown in Fig. 23, information on UPF#2-2 is notified.
[0341] The procedure 1161 shown in Fig. 23 is the same as Fig. 12 and Fig. 16. In the procedure 1161 shown in Fig. 23, UPF#2 may be replaced with UPF#2-2.
[0342] Step ST1191 shown in FIG. 23 is the same as that in FIG.
[0343] In steps ST1696 to ST1699 shown in FIG. 23, the same processes as those in steps ST1196 to ST1199 shown in FIG. 12 are performed in the UE, base station #2, UPF #2-2, anchor UPF, and DN.
[0344] As another example of the PDU session change notification to the UE, the notification may be made from the anchor NW to the UE. For example, the anchor AMF may make the notification to the UE. The notification from the anchor AMF to the UE may use the method disclosed in the first embodiment, for example, the method disclosed in Figures 20 to 22.
[0345] The anchor SMF may request the anchor AMF to notify the UE. The notification from the anchor AMF to the UE may be triggered by the request. The anchor SMF may make the request to the anchor AMF in response to a request for UPF switching from a non-anchor SMF to the anchor SMF.
[0346] Another solution is disclosed. The process of intermediate UPF switching may be initiated by a network to which the intermediate UPF belongs. For example, the process of intermediate UPF switching of a non-anchor network may be initiated by the non-anchor network. For example, the non-anchor SMF may initiate the switching process.
[0347] The non-anchor SMF may select a post-switching intermediate UPF, establish a connection with the post-switching intermediate UPF, or release the connection with the failed intermediate UPF. The operations in the non-anchor SMF may be performed in the same manner as described above.
[0348] The non-anchor SMF may notify the anchor SMF of information regarding UPF switching. The notification may be performed, for example, as a PDU session modification request. For the notification from the non-anchor SMF to the anchor SMF, for example, Nsmf_PDUSession_Modification_Request signaling (see Non-Patent Document 31) may be used. The notification may include information regarding a failure of the intermediate UPF, information regarding the UE, information regarding the PDU session, information regarding the QoS flow, information regarding the failed intermediate UPF, information regarding the post-switching intermediate UPF, or information regarding the QoS monitoring configuration disclosed in the first embodiment.
[0349] The anchor SMF may notify the anchor UPF that the intermediate UPF has been switched, or may request a switchover of the connection with the intermediate UPF. The notification and / or request from the anchor SMF to the anchor UPF may be, for example, similar to the above. The anchor UPF may notify the anchor SMF that the switchover of the connection with the intermediate UPF has been completed. The notification from the anchor UPF to the anchor SMF may be, for example, similar to the above.
[0350] The anchor SMF may respond to the notification to the non-anchor SMF. The response may be, for example, a response to a PDU session modification request. The response from the anchor SMF to the non-anchor SMF may be, for example, signaled using Nsmf_PDUSession_Modification_Response (see 31).
[0351] Figure 25 is a sequence diagram showing another example of intermediate UPF switching operation in a non-anchor NW. Figure 25 shows an example in which a non-anchor NW detects a NW failure and the non-anchor NW decides to switch UPFs. In the example shown in Figure 25, the intermediate UPF of NW 1091 switches from UPF #2-1 to UPF #2-2. In the example shown in Figure 25, the same processes as those in Figures 12, 17, 19, and 23 are assigned the same numbers, and common descriptions will be omitted.
[0352] Steps ST1196 to ST1199 shown in FIG. 25 are the same as those in FIG.
[0353] Step ST1420 shown in FIG. 25 is the same as that in FIG.
[0354] The procedure 1625 shown in FIG. 25 is similar to that shown in FIGS.
[0355] In step ST1758 shown in FIG. 25 , SMF#2 requests SMF#1 to change the PDU session. The request in step ST1758 may be made as a notification of information related to UPF switching. For example, signaling of Nsmf_PDUSession_Modification_Request (see non-patent document 31) may be used in step ST1758. The request may include information related to a failure of the intermediate UPF, information related to the UE, information related to the PDU session, information related to the QoS flow, information related to the failed intermediate UPF, information related to the post-switching intermediate UPF, or information related to the QoS monitoring configuration disclosed in the first embodiment. Taking step ST1758 as a trigger, SMF#1 may start a process of connecting the anchor UPF and UPF#2-2.
[0356] Steps ST1159 and ST1160 shown in FIG. 25 are the same as those in FIG.
[0357] In Step ST1761 shown in FIG. 25, SMF #1 responds to the PDU session modification request to SMF #2. Step ST1761 may be performed as a response to Step ST1758. For example, signaling of Nsmf_PDUSession_Modification_Response may be used in Step ST1761.
[0358] The procedure 1161 shown in Fig. 25 is the same as that shown in Fig. 12 and Fig. 16. In Fig. 25, the process of step ST1191 shown in Fig. 12 may not be performed.
[0359] Steps ST1696 to ST1699 shown in FIG. 25 are the same as those in FIG.
[0360] The NW that detects the NW failure may be different from the NW that initiates the intermediate UPF switching process. For example, the anchor NW may detect the NW failure and the non-anchor NW may initiate the intermediate UPF switching process. The anchor SMF may notify the non-anchor SMF of information about the NW failure. The notification may include information about the failed intermediate UPF, information about the PDU session, or information about the QoS flow. The non-anchor SMF may initiate the intermediate UPF switching process in response to the notification.
[0361] The network that initiates the switching process of the intermediate UPF may be determined in advance by a standard. For example, the network that detects a network failure may initiate the switching process of the intermediate UPF. This enables, for example, the switching process of the intermediate UPF to be performed quickly. As another example, the network in which a network failure occurs may initiate the switching process of the intermediate UPF.
[0362] As another example, the anchor NW may determine the NW that starts the switching process of the intermediate UPF. The anchor NW may determine the NW that starts the switching process of the intermediate UPF, for example, when a NW failure is detected, or when a non-anchor notifies the anchor NW of information related to the NW failure.
[0363] The anchor NW may notify the non-anchor NW of information regarding the NW that will initiate the intermediate UPF switching process. As another example, it may be possible to determine which NW will initiate the intermediate UPF switching process based on information included in the signaling transmitted from the anchor SMF to the non-anchor SMF. For example, the anchor NW may initiate the intermediate UPF switching process based on the inclusion of a UPF switching request, or the non-anchor NW may initiate the intermediate UPF switching process based on the inclusion of information regarding a NW failure. This, for example, makes it possible to reduce the size of signaling from the anchor NW to the non-anchor NW.
[0364] As another example, the UE may determine a network that will activate the intermediate UPF switching process. The UE may notify the anchor AMF of information regarding the network that will activate the intermediate UPF switching process. The information may be, for example, preference information from the UE. The anchor AMF may notify the anchor SMF of the information. This allows the UE to select a network with low latency between the UE and the anchor AMF, thereby enabling the intermediate UPF switching process to be performed quickly.
[0365] A PDU session modification request to the UE may be made from the anchor network. For example, the anchor network may notify information about a PDU session passing through a non-anchor network. The PDU session modification request from the anchor network may be made using, for example, a method similar to the method disclosed in the first embodiment. For example, the methods disclosed in Figures 20 to 22 may be used. This makes it possible to prevent, for example, contention between a PDU session request transmitted from the anchor network to the UE and a PDU session request transmitted from a non-anchor network to the UE, and as a result, to prevent malfunction of the UE.
[0366] The failed intermediate UPF may be released. For example, this release may be applied when a UE connects to an anchor UPF via multiple intermediate UPFs in a non-anchor network and some of the multiple intermediate UPFs fail. The UE may connect to the anchor UPF via a non-failed intermediate UPF among the multiple intermediate UPFs. A response to a UPF switching request from the non-anchor SMF to the anchor SMF and / or a notification of information regarding UPF switching may include information about the non-failed intermediate UPF or information about the base station of the non-anchor network. This may improve the flexibility of path switching when a failure occurs in a communication system, for example.
[0367] A non-anchor base station and an anchor UPF may be directly connected. For example, the above-mentioned direct connection may be triggered by a failure of an intermediate UPF in the non-anchor network. The non-anchor SMF may instruct the non-anchor base station to connect to the anchor UPF. The instruction may be sent via the non-anchor AMF. The instruction may include information (e.g., address) about the anchor UPF. The non-anchor base station may initiate a connection with the anchor UPF in response to the instruction. The non-anchor SMF may notify the anchor SMF of information about the non-anchor base station. The anchor SMF may notify the anchor UPF of information about the non-anchor base station. The anchor UPF may initiate a connection with the non-anchor base station in response to the notification. This may reduce latency in the non-anchor network, for example.
[0368] The non-anchor base station and the anchor UPF may be connected via SEPP. As a method of connection, a method similar to the operation of directly connecting the non-anchor base station and the anchor UPF described above may be used.
[0369] According to the second embodiment, recovery from an intermediate UPF failure in a non-anchor NW becomes possible.
[0370] Third Embodiment In a third embodiment, another example of a method for recovering from a network failure is disclosed.
[0371] The network serving as the data path may be switched. For example, in data transmission and reception via a non-anchor network, the path of the data transmission and reception may be switched to the anchor network when a failure of an intermediate UPF of the non-anchor network is detected.
[0372] The anchor NW may initiate the switching of the NW serving as a path. For example, the anchor NW may initiate the switching when detecting a failure of a non-anchor NW. For example, the anchor SMF may initiate the switching.
[0373] The anchor SMF may notify the non-anchor NW of information about NW switching or may request the release of the failed intermediate UPF. The notification and / or the request may be made, for example, to the non-anchor SMF. The notification and / or the request may be made, for example, as a PDU session modification request or a PDU session release request. For the notification and / or the request, for example, Nsmf_PDUSession_Modification_Request signaling (see Non-Patent Document 31) or Nsmf_PDUSession_Release_Request signaling (see Non-Patent Document 31) may be used. The notification and / or the request may include information about the NW failure, information about the failed intermediate UPF, information about the UE, information about the PDU session, or information about the QoS flow.
[0374] The non-anchor NW may release the resources of the failed intermediate UPF. For example, the non-anchor SMF may request the failed intermediate UPF to release the connection. The request may be made in a manner similar to that disclosed in the second embodiment.
[0375] The non-anchor SMF may notify the non-anchor AMF of the release of resources of the failed intermediate UPF. The notification may include a request for NAS signaling information. The NAS signaling may be, for example, NAS signaling related to PDU session modification. The non-anchor AMF may notify the non-anchor SMF of the NAS signaling information. The notification from the non-anchor AMF to the non-anchor SMF may be triggered by the request from the non-anchor SMF to the non-anchor AMF.
[0376] The NAS signaling may include information about RRC signaling. The RRC signaling may be, for example, RRC signaling related to a PDU session change. The non-anchor AMF may request RRC signaling information from the non-anchor base station. The non-anchor base station may notify the non-anchor AMF of the RRC signaling information. The notification from the non-anchor base station to the non-anchor AMF may be triggered by the request from the non-anchor AMF to the non-anchor base station.
[0377] The non-anchor SMF may notify the anchor SMF of information regarding the release of the failed intermediate UPF. The notification may be, for example, a response to a PDU session modification request or a response to a PDU session release request. For example, the notification may use Nsmf_PDUSession_Modification_Response signaling (see Non-Patent Document 31) or Nsmf_PDUSession_Release_Response signaling (see Non-Patent Document 31). The notification may include, for example, information regarding NAS signaling. The NAS signaling may be, for example, NAS signaling related to PDU session modification. The NAS signaling may be, for example, NAS signaling acquired from the non-anchor AMF. The NAS signaling may include RRC signaling. The RRC signaling may be, for example, RRC signaling related to PDU session release. The RRC signaling may be, for example, RRC signaling obtained from a non-anchor base station.
[0378] The anchor SMF may perform UPF configuration. The UPF may be, for example, an intermediate UPF of the anchor network or an anchor UPF. The UPF configuration may, for example, reserve resources for the UPF for UE communication. In the UPF configuration, for example, some or all of the processes disclosed in PDU session establishment (Section 4.3.2 of Non-Patent Document 31) may be performed.
[0379] The anchor SMF may configure the anchor UPF for network switching. For example, the anchor SMF may instruct the anchor UPF to release the connection with the failed intermediate UPF. The anchor UPF may release the connection with the failed intermediate UPF in response to the instruction.
[0380] The anchor SMF may notify the anchor AMF of the PDU session change. The anchor AMF may notify the UE of the PDU session change. The notification may be performed via the base station of the anchor NW (hereinafter sometimes referred to as the anchor base station). The UE may change the PDU session setting of its own UE based on the notification.
[0381] The notification from the anchor SMF to the anchor AMF may be triggered by notification of information regarding the release of the failed intermediate UPF from the non-anchor SMF to the anchor SMF. The notification from the anchor SMF to the anchor AMF may include information regarding NAS signaling. The NAS signaling may include NAS signaling in the anchor NW or may include NAS signaling in the non-anchor NW. This enables, for example, the UE to change PDU session settings for the anchor NW and the non-anchor NW, thereby improving communication efficiency in the communication system.
[0382] Fig. 26 is a sequence diagram showing an example of NW switching operation in a non-anchor NW. Fig. 26 shows an example in which the anchor NW detects a NW failure and the anchor NW decides to switch the NW. In the example shown in Fig. 26, the NW is switched from NW1091 to NW1090. In the example shown in Fig. 26, the same processes as those in Fig. 12 and Fig. 17 are assigned the same numbers, and common explanations will be omitted.
[0383] Steps ST1196 to ST1199 shown in Fig. 26 are the same as those in Fig. 12. Step ST1220 shown in Fig. 26 is the same as those in Fig. 17.
[0384] In step ST1806 shown in Fig. 26 , SMF#1 determines to switch the network that serves as the data path. In the example shown in Fig. 26 , SMF#1 determines to switch the data path that passes through UPF#2 to NW1090.
[0385] In step ST1810 shown in FIG. 26 , SMF#1 requests SMF#2 to release the PDU session. The request may include information about the UE, information about the PDU session, information about the QoS flow, information about a network failure, or information about switching of a network that serves as a path. The information about the network failure may include information about the UPF that is the target of the network failure. In step ST1810, signaling of Nsmf_PDUSession_Release_Request (see Non-Patent Document 31) may be used. SMF#2 may start the operation of releasing the PDU session triggered by step ST1810.
[0386] The procedures 1100 and 1111 shown in FIG. 26 are similar to those in FIGS.
[0387] Steps ST1656 and ST1657 shown in FIG. 26 are the same as those in FIGS.
[0388] In procedure 1861 shown in Figure 26, processing similar to that of procedure 1161 shown in Figures 12 and 16 is performed. In procedure 1861, PDU session release may be performed instead of a PDU session establishment / modification request. In procedure 1861, signaling similar to that of procedure 1161 may be used. In step ST1190 of procedure 1861, which corresponds to step ST1190 of procedure 1161 shown in Figure 16, a procedure for terminating a session management policy association is performed between SMF#2 and PCF#2. This procedure may be, for example, the procedure disclosed in section 4.16.6 of Non-Patent Document 31 (3GPP TS23.502).
[0389] In step ST1891 shown in FIG. 26, SMF #2 responds to the PDU session release request to SMF #1. Step ST1891 may be performed as a response to step ST1810.
[0390] Steps ST1192 to ST1195 shown in FIG. 26 are the same as those in FIG.
[0391] Another solution is disclosed. The switching of the NW serving as a route may be initiated by the non-anchor NW. For example, the anchor NW may initiate the switching when it detects a failure in the non-anchor NW, or when it receives a notification of a NW failure from the anchor NW.
[0392] The non-anchor NW may request the anchor NW to switch the NW. The request may be made, for example, between the non-anchor SMF and the anchor SMF. The request may include information about the failed intermediate UPF, information about the UE, information about the PDU session, or information about the QoS flow. The anchor NW may configure the UPF in response to the request. The configuration may be, for example, reserving resources for the UPF for UE communication. The configuration of the UPF in the anchor NW may be the same as described above.
[0393] Fig. 27 is a sequence diagram showing another example of NW switching operation in a non-anchor NW. Fig. 27 shows an example in which a non-anchor NW detects a NW failure and makes a decision to switch NWs. In the example shown in Fig. 27, the NW switches from NW1091 to NW1090. In the example shown in Fig. 27, the same processes as those in Figs. 12, 17, 19, 23, 24, and 26 are assigned the same numbers, and common explanations will be omitted.
[0394] Steps ST1196 to ST1199 shown in Fig. 27 are the same as those in Fig. 12. Step ST1420 shown in Fig. 27 is the same as those in Fig. 19.
[0395] In step ST1906 shown in Fig. 27, SMF#2 determines to switch the network that serves as the data path. In the example shown in Fig. 27, SMF#2 determines to switch the data path that passes through UPF#2 to NW1901.
[0396] In step ST1910 shown in FIG. 27 , SMF#2 requests SMF#1 to modify the PDU session. The request may include information about the UE, information about the PDU session, information about the QoS flow, information about a network failure, or information about switching of a network that serves as a path. The information about the network failure may include information about the UPF that is the target of the network failure. In step ST1910, signaling of Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31) may be used.
[0397] In step ST1910 shown in FIG. 27, a request to establish a PDU session may be made. For example, signaling of Nsmf_PDUSession_Establishment_Request (see Non-Patent Document 31) may be used.
[0398] The procedures 1100, 1111 shown in FIG. 27 are similar to those in FIGS.
[0399] Steps ST1656 and ST1657 shown in FIG. 27 are the same as those in FIGS.
[0400] In step ST1961 shown in FIG. 27, SMF #1 responds to the PDU session modification request to SMF #2. Step ST1961 may be performed as a response to step ST1910.
[0401] The procedure 1861 shown in Fig. 27 is the same as that shown in Fig. 26. Steps ST1192 to ST1195 are the same as those shown in Fig. 12.
[0402] The NW that detects the NW failure and the NW that initiates the NW switching process may be different. For example, the anchor NW may detect the NW failure and the non-anchor NW may initiate the NW switching process. The anchor SMF may notify the non-anchor SMF of information about the NW failure. The notification may include information about the failed intermediate UPF, information about the PDU session, or information about the QoS flow. The non-anchor SMF may initiate the NW switching process in response to the notification.
[0403] The network that initiates the network switching process may be determined in advance by a standard. For example, the network that detects a network failure may initiate the network switching process. This enables, for example, the network switching process to be performed quickly. As another example, the network in which a network failure occurs may initiate the network switching process.
[0404] As another example, the anchor NW may determine the NW that starts the NW switching process. The anchor NW may determine the NW that starts the NW switching process, for example, when a NW failure is detected, or when a non-anchor NW notifies the anchor NW of information related to the NW failure.
[0405] The anchor NW may notify the non-anchor NW of information regarding the NW that will initiate the NW switching process. As another example, it may be possible to determine which NW will initiate the NW switching process based on information included in the signaling transmitted from the anchor SMF to the non-anchor SMF. For example, the anchor NW may initiate the NW switching process based on the inclusion of a NW switching request, or the non-anchor NW may initiate the NW switching process based on the inclusion of information regarding a NW failure. This makes it possible to reduce the size of the signaling from the anchor NW to the non-anchor NW, for example.
[0406] As another example, the UE may determine the network that will activate the network switching process. The UE may notify the anchor AMF of information regarding the network that will activate the switching process. The information may be, for example, preference information from the UE. The anchor AMF may notify the anchor SMF of the information. This allows the UE to select a network with low latency between the UE and the anchor AMF, thereby enabling the network switching process to be performed quickly.
[0407] A priority may be set between the intermediate UPF switching disclosed in the second embodiment and the NW switching disclosed in the third embodiment.
[0408] For example, intermediate UPF switching may be performed preferentially, which makes it possible to prevent an increase in the load on other networks.
[0409] As another example, network switching may be performed with priority, which enables traffic distribution between networks, for example.
[0410] As another example, the UE may decide which switching process to prioritize. The UE may notify the anchor AMF of information regarding which switching process to prioritize. The information may be, for example, preference information from the UE. The anchor AMF may notify the anchor SMF of the information. This may enable, for example, the UE to execute a method with a low processing load, thereby reducing the power consumption of the UE.
[0411] As another example, which switching process is to be prioritized may be decided by the anchor network, the network that detected the failure, or the network in which the failure occurred.
[0412] A decision as to which switching process to perform may be made each time. The decision may be made by an anchor network device, for example, an anchor SMF, or by a non-anchor network device, for example, a non-anchor SMF. For example, the anchor SMF may make the decision using information on the QoS and / or QoE of the non-anchor network, or may make the decision using information on the QoS and / or QoE of its own network, or may make the decision using both of the aforementioned information. As another example, the non-anchor SMF may make the decision using information on the QoS and / or QoE of the anchor network, or may make the decision using information on the QoS and / or QoE of its own network, or may make the decision using both of the aforementioned information.
[0413] The information regarding QoS and / or QoE may include, for example, information regarding the QoS and / or QoE that can be supported in the network, information regarding the measurement results of the QoS and / or QoE, or information regarding the QoS and / or QoE required for the service.
[0414] The non-anchor NW may notify the anchor NW of information regarding its own QoS and / or QoE. The anchor NW may request information regarding QoS and / or QoE from the non-anchor NW. The notification from the non-anchor NW to the anchor NW may be triggered by the request from the anchor NW to the non-anchor NW.
[0415] As another example, the anchor network may notify the non-anchor network of information regarding its own QoS and / or QoE. The non-anchor network may request information regarding QoS and / or QoE from the anchor network. The notification from the anchor network to the non-anchor network may be triggered by the request from the non-anchor network to the anchor network.
[0416] In the NW switching disclosed in this third embodiment, a PDU session change of the anchor NW may be performed, or a PDU session establishment may be performed.
[0417] The method disclosed in the third embodiment may be used when a PDU session is established in the anchor NW, or when a PDU session is not established in the anchor NW. For example, a PDU session change in the NW switching process may be performed when a PDU session is established in the anchor NW. As another example, a PDU session establishment in the NW switching process may be performed when a PDU session is not established in the anchor NW.
[0418] According to the third embodiment, recovery from a network failure becomes possible, and load balancing of the network becomes possible.
[0419] Modification 1 of Embodiment 3 In this modification 1, another example regarding NW switching is disclosed.
[0420] A network serving as a data path may be switched from an anchor network to a non-anchor network. For example, in data transmission and reception via an anchor network, the path of the data transmission and reception may be switched to a non-anchor network upon detection of a failure in an intermediate UPF of the anchor network.
[0421] The anchor NW may initiate the switching of the NW serving as the path. For example, the anchor NW may initiate the switching when detecting a failure in its own NW. For example, the anchor SMF may initiate the switching.
[0422] The anchor network may initiate the switchover using information about the QoS and / or QoE of the non-anchor network, may initiate the switchover using information about the QoS and / or QoE of its own network, or may initiate the switchover using both of the aforementioned information.
[0423] The information regarding QoS and / or QoE may include, for example, information regarding the QoS and / or QoE that can be supported in the network, information regarding the measurement results of the QoS and / or QoE, or information regarding the QoS and / or QoE required for the service.
[0424] The non-anchor NW may notify the anchor NW of information regarding its own QoS and / or QoE. The anchor NW may request information regarding QoS and / or QoE from the non-anchor NW. The notification from the non-anchor NW to the anchor NW may be triggered by the request from the anchor NW to the non-anchor NW.
[0425] The PDU session may be released in the anchor network, or the PDU session may be changed. The PDU session may be established in the non-anchor network, or the PDU session may be changed.
[0426] The anchor SMF may notify the non-anchor NW of information regarding NW switching. The notification may be made to the non-anchor SMF, for example. The notification may be made as a PDU session establishment request or a PDU session modification request. For example, the notification and / or the request may use signaling of Nsmf_PDUSession_Establishment_Request (see Non-Patent Document 31) or signaling of Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31). The notification and / or the request may include information regarding NW failure, information regarding the failed intermediate UPF, information regarding the UE, information regarding the PDU session, or information regarding the QoS flow.
[0427] The anchor NW may release the resources of the failed intermediate UPF. For example, the anchor SMF may request the failed intermediate UPF to release the connection.
[0428] The non-anchor NW may determine the post-switching intermediate UPF or may initiate a connection with the post-switching intermediate UPF.
[0429] The non-anchor NW may notify the anchor NW of information about the post-switching intermediate UPF. The anchor SMF may instruct the anchor UPF to start a connection with the post-switching intermediate UPF.
[0430] Fig. 28 is a sequence diagram showing an example of NW switching operation in an anchor NW. Fig. 28 shows an example in which the anchor NW detects a NW failure and makes a decision to switch the NW. In the example shown in Fig. 28, the NW is switched from NW1090 to NW1091. In the example shown in Fig. 28, the same processes as those in Figs. 12, 17, 18, 23, and 26 are assigned the same numbers, and common explanations will be omitted.
[0431] Steps ST1192 to ST1195 shown in Fig. 28 are the same as those in Fig. 12. Step ST1220 is the same as that in Fig. 17. Step ST1806 is the same as that in Fig. 26. In step ST1806 shown in Fig. 28, SMF#1 decides to switch the path of data passing through UPF#1 to NW1091.
[0432] In step ST2010 shown in FIG. 28 , SMF#1 requests SMF#2 to establish a PDU session. It may also request a modification of the PDU session. The request may include information about the UE, information about the PDU session, information about the QoS flow, information about a network failure, or information about switching of a network that serves as a route. The information about the network failure may include information about the UPF that is the target of the network failure. In step ST2010, signaling of Nsmf_PDUSession_Establish_Request (see Non-Patent Document 31) or signaling of Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31) may be used.
[0433] The procedure 1150 shown in FIG. 28 is similar to that shown in FIGS.
[0434] In steps ST2056 and ST2057 shown in FIG. 28, the same processes as those in steps ST1656 and ST1657 of procedure 1625 shown in FIGS. 23 and 24 are performed between SMF#1 and UPF#1.
[0435] In procedure 2011 shown in Figure 28, processing similar to that of procedure 1111 shown in Figures 12 and 14 is performed. In procedure 2011, PDU session release may be performed instead of a PDU session establishment / modification request. In procedure 2011, signaling similar to that of procedure 1161 may be used. In step ST1140 of procedure 2011, which corresponds to step ST1140 of procedure 1111 shown in Figure 14, a procedure for terminating a session management policy association is performed between SMF#1 and PCF#1. This procedure may be, for example, the procedure disclosed in section 4.16.6 of Non-Patent Document 31 (3GPP TS23.502).
[0436] Steps ST1158 to ST1160 shown in Figure 28 are the same as those in Figure 12. Procedure 1161 is the same as those in Figures 12 and 16. Step ST1386 is the same as those in Figure 18. Steps ST1196 to ST1199 are the same as those in Figure 12.
[0437] A priority may be established between intermediate UPF switching in the anchor network and the network switching disclosed in this first variant.
[0438] For example, intermediate UPF switching may be performed preferentially, which makes it possible to prevent an increase in the load on the non-anchor NW.
[0439] As another example, network switching may be performed with priority, which enables traffic distribution between networks, for example.
[0440] As another example, the UE may decide which switching process to prioritize. The UE may notify the anchor AMF of information regarding which switching process to prioritize. The information may be, for example, preference information from the UE. The anchor AMF may notify the anchor SMF of the information. This may enable, for example, the UE to execute a method with a low processing load, thereby reducing the power consumption of the UE.
[0441] As another example, the anchor NW may decide which switching process is to be prioritized. For example, the anchor SMF or the anchor PCF may decide which switching process is to be prioritized.
[0442] A decision as to which switching process to perform may be made each time. The decision may be made by an anchor network device, for example, an anchor SMF. For example, the anchor SMF may make the decision using information on the QoS and / or QoE of a non-anchor network, or may make the decision using information on the QoS and / or QoE of its own network, or may make the decision using both of the above information.
[0443] The information regarding QoS and / or QoE may include, for example, information regarding the QoS and / or QoE that can be supported in the network, information regarding the measurement results of the QoS and / or QoE, or information regarding the QoS and / or QoE required for the service.
[0444] The non-anchor NW may notify the anchor NW of information regarding its own QoS and / or QoE. The anchor NW may request information regarding QoS and / or QoE from the non-anchor NW. The notification from the non-anchor NW to the anchor NW may be triggered by the request from the anchor NW to the non-anchor NW.
[0445] In the NW switching disclosed in this variant example 1, a PDU session change of the non-anchor NW may be performed, or a PDU session establishment may be performed.
[0446] The method disclosed in this first modification may be used when a PDU session is established in a non-anchor network, or when a PDU session is not established in a non-anchor network. For example, a PDU session change in a network switching process may be performed when a PDU session is established in a non-anchor network. As another example, a PDU session establishment in a network switching process may be performed when a PDU session is not established in a non-anchor network.
[0447] This first modification enables recovery from a network failure and load balancing of the network.
[0448] Fourth Embodiment In a fourth embodiment, another example of a method for recovering from a network failure is disclosed.
[0449] The anchor UPF may be switched. For example, the switching may be triggered by detecting a fault in the anchor UPF. The anchor SMF may perform the detection.
[0450] The anchor SMF may determine a new anchor UPF (hereinafter, may be referred to as a post-switching anchor UPF). The anchor SMF may establish a connection with the post-switching anchor UPF.
[0451] The anchor SMF may request the post-switching anchor UPF to establish a connection. For example, the request may use signaling of an N4 Session Establishment Request (see Non-Patent Document 31). The request may include information about the UE, information about the PDU session, information about the QoS flow, information about the QoS monitoring disclosed in the first embodiment, or information about the intermediate UPF. For example, including information about the intermediate UPF enables the connection between the post-switching anchor UPF and the intermediate UPF to be quickly established.
[0452] The post-switching anchor UPF may respond to the connection establishment to the anchor SMF. For example, the response may use signaling of an N4 Session Establishment Response (see Non-Patent Document 31). The anchor SMF may recognize the completion of the connection of the post-switching anchor UPF based on the response.
[0453] The anchor SMF may request a connection release from the anchor UPF in which the failure is detected (hereinafter, sometimes referred to as the failed anchor UPF). For example, the request may use N4 Session Release Request signaling (see Non-Patent Document 31). The request may include information about the UE, information about the PDU session to be released, or information about the QoS flow to be released. The failed anchor UPF may use the information to release resources related to the PDU session and / or the QoS flow.
[0454] The failed anchor UPF may respond to the request for connection release to the anchor SMF. For example, the response may use signaling of an N4 Session Release Response (see Non-Patent Document 31). The anchor SMF may recognize the completion of the release of the failed anchor UPF based on the response.
[0455] The anchor SMF may request a connection modification from the intermediate UPF. For example, the request may use signaling of an N4 Session Modification Request (see Non-Patent Document 31). The request may include information about the UE, information about the PDU session, information about the QoS flow, information about the QoS monitoring disclosed in the first embodiment, or information about the post-switching anchor UPF. The intermediate UPF may use the information to initiate a connection with the post-switching anchor UPF or terminate a connection with the failed anchor UPF. As another example, the intermediate UPF may use the information to change the anchor UPF to which it is connected.
[0456] The anchor SMF may notify the non-anchor SMF of the UPF switch. A request for the UPF switch may be made. For example, the notification and / or the request may use signaling of Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31). The notification and / or the request may include information about the post-switch anchor UPF. This allows, for example, the non-anchor SMF to quickly recognize that the anchor UPF has been switched.
[0457] The non-anchor SMF may request the intermediate UPF to switch its connection destination. The request may include information about the post-switching anchor UPF, information about the UE, information about the PDU session, information about the QoS flow, or information about the QoS monitoring configuration disclosed in the first embodiment. For example, the request may use signaling of an N4 Session Modification Request (see Non-Patent Document 31). The intermediate UPF may switch its connection with the anchor UPF in response to the request. For example, the intermediate UPF may release the N9 interface (see Non-Patent Document 10) between itself and the failed anchor UPF or establish an N9 interface between itself and the post-switching anchor UPF in response to the request.
[0458] The intermediate UPF may notify the non-anchor SMF of the completion of switching of the connection with the anchor UPF. For example, the notification may be performed using signaling of an N4 Session Modification Response (see Non-Patent Document 31). The non-anchor SMF may recognize the completion of switching of the connection between the intermediate UPF and the post-switching anchor UPF upon receiving the notification.
[0459] The non-anchor NW may notify the UE of a change in the PDU session. The notification may be made, for example, from the non-anchor SMF or via the non-anchor AMF. As another example, the notification may be made from the non-anchor AMF. The UE may perform settings related to switching of the anchor UPF in response to the notification.
[0460] The non-anchor SMF may respond to the UPF switching request to the anchor SMF. For example, the response may use signaling of Nsmf_PDUSession_Modification_Response (see Non-Patent Document 31). This allows, for example, the anchor SMF to quickly grasp the completion of connection between the intermediate UPF of the non-anchor NW and the post-switching anchor UPF.
[0461] Notification of anchor UPF switching from the anchor NW to the non-anchor NW may be performed when a PDU session is not established in the non-anchor NW. The non-anchor NW device may retain information regarding anchor UPF switching. This retention may be performed, for example, by the non-anchor SMF. The information may be used, for example, to establish a PDU session in the non-anchor NW. This makes it possible, for example, to quickly establish a PDU session in the non-anchor NW.
[0462] 29 and 30 are sequence diagrams showing an example of the switching operation of the anchor UPF. FIG. 29 shows the first half of the sequence, and FIG. 30 shows the second half of the sequence. FIG. 29 and 30 show a series of operations (switching operation of the anchor UPF). In the example shown in FIG. 29 and 30, anchor UPF #1 switches to anchor UPF #2 in the same NW. In the example shown in FIG. 29 and 30, an example is shown in which the anchor NW detects a NW failure and the anchor NW decides to switch the anchor UPF. In the example shown in FIG. 29 and 30, the same processes as those in FIG. 12, FIG. 17, and FIG. 23 are assigned the same numbers, and common explanations are omitted.
[0463] Steps ST1192 to ST1199 shown in FIG. 29 are the same as those in FIG. 12. Step ST1220 is the same as that in FIG. 17. In step S1220 shown in FIG. 29, SMF#1 detects a failure in anchor UPF#1. Step ST1621 is the same as that in FIG. 23. In step ST1621 shown in FIG. 29, SMF#1 decides to switch the anchor UPF. Step ST1101 is the same as that in FIGS. 12 and 13. In step ST1101 shown in FIG. 29, SMF#1 selects anchor UPF#2. Step ST1102 is the same as that in FIGS. 12 and 13.
[0464] In step ST2104 shown in FIG. 29 , SMF#1 requests anchor UPF#2 to establish an N4 session. Step ST2104 triggers the anchor UPF#2 to establish an N4 session. In step ST2105, anchor UPF#2 responds to step ST2104 to SMF#1.
[0465] In step ST2106 shown in FIG. 29 , SMF#1 requests anchor UPF#1 to release the N4 session. Step ST2106 triggers the anchor UPF#1 to release the N4 session. In step ST2107, anchor UPF#1 sends a response to step ST2106 to SMF#1.
[0466] In step ST2108 shown in FIG. 29 , SMF#1 requests UPF#1 to change the N4 session. The request may include information regarding a change of the destination UPF. The request may include information regarding the anchor UPF#2. UPF#1 may switch the destination UPF upon receiving step ST2108. In step ST2109, UPF#1 responds to step ST2108 to SMF#1.
[0467] In step ST2110 shown in FIG. 29 , SMF#1 requests SMF#2 to modify the PDU session. The request may include information about the UE, information about the PDU session, information about the QoS flow, information about a network failure, information about UPF switching, or information about the UPF after switching. The information about the network failure may include information about the UPF that is the target of the network failure. In step ST2110, signaling of Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31) may be used.
[0468] In procedure 2111 shown in Fig. 30, processing similar to that of procedure 1111 shown in Fig. 12 and 14 may be performed. In procedure 2111 shown in Fig. 30, processing of anchor UPF#2 may be performed instead of processing of anchor UPF shown in Fig. 12 and 14.
[0469] In steps ST2154 and ST2155 shown in FIG. 30, the same processing as in steps ST2108 and ST2109 shown in FIG. 29 is performed between SMF#2 and UPF#2.
[0470] The procedure 1161 shown in FIG. 30 is similar to that shown in FIGS.
[0471] In step ST2186 shown in FIG. 30, SMF #2 responds to the PDU session modification request to SMF #1. Step ST2186 may be performed as a response to step ST2110 shown in FIG.
[0472] 30, data is transmitted and received between the UE and the DN via the NW 1090. Step ST1192 indicates data transmission and reception between the UE and the base station #1, step ST1193 indicates data transmission and reception between the base station #1 and the UPF #1, step ST2194 indicates data transmission and reception between the UPF #1 and the anchor UPF #2, and step ST2195 indicates data transmission and reception between the anchor UPF #2 and the DN.
[0473] 30, data is transmitted and received between the UE and the DN via the NW 1091. Step ST1196 indicates data transmission and reception between the UE and the base station #2, step ST1197 indicates data transmission and reception between the base station #2 and the UPF #2, step ST2198 indicates data transmission and reception between the UPF #2 and the anchor UPF #2, and step ST2199 indicates data transmission and reception between the anchor UPF #2 and the DN.
[0474] The intermediate UPF may be switched. The switching of the intermediate UPF may be triggered by switching the anchor UPF. The intermediate UPF to be the new intermediate UPF after switching (post-switching intermediate UPF) may be, for example, an intermediate UPF with a large communication capacity with the post-switching anchor UPF, or an intermediate UPF with low latency in communication with the post-switching anchor UPF. The switching of the intermediate UPF may be performed in the anchor NW or in the non-anchor NW. The switching of the intermediate UPF may be performed, for example, by a method similar to the method disclosed in the second embodiment. For example, the operation by each device of the non-anchor NW in the second embodiment may be performed by each device of the anchor NW. This makes it possible to improve communication efficiency in the communication system, for example.
[0475] Another solution is disclosed. A UPF of another network may be the anchor UPF. The anchor AMF may not be switched, the anchor SMF may not be switched, and the anchor PCF may not be switched. This can improve the flexibility of data transmission in the communication system, for example.
[0476] As another solution, the anchor network and the non-anchor network may be switched, which can avoid the complexity of the communication system, for example.
[0477] The anchor SMF may determine the switch. The anchor SMF may request the non-anchor SMF to switch. The non-anchor SMF may respond to the request to the anchor SMF. The anchor SMF may notify the anchor AMF of the switch of the anchor NW. The anchor AMF may perform processing for switching from the anchor NW to the non-anchor NW, triggered by the notification. The processing may be, for example, a PDU session change. The processing may be performed between the anchor base station and the UE. The non-anchor SMF may notify the non-anchor AMF of the switch of the non-anchor NW. The non-anchor AMF may perform processing for switching from the non-anchor NW to the anchor NW, triggered by the notification. The processing may be, for example, a PDU session change. The processing may be performed between the non-anchor base station and the UE.
[0478] The request for switching from the anchor SMF to the non-anchor SMF may include information about the DN or information about the UE. The information about the DN may include information about the address of the DN. The information about the address may include an IP address or information about a Full Qualified Domain Name (FQDN). The information about the UE may include an address (e.g., IP address) of the UE, an identifier of the UE, or information about slicing of the UE.
[0479] The non-anchor SMF may notify the post-switching anchor UPF of the information about the DN and / or the information about the UE, which may, for example, allow the post-switching anchor UPF to quickly establish a connection with the DN.
[0480] In the anchor UPF switching disclosed in this fourth embodiment, a PDU session change may be performed in the anchor UPF after switching, or a PDU session may be established.
[0481] The anchor UPF change disclosed in the fourth embodiment may be performed when a PDU session is established in the anchor UPF, or when a PDU session is not established in the anchor UPF. For example, the PDU session change of the anchor UPF may be performed when a PDU session is established in the anchor UPF. As another example, the PDU session establishment of the anchor UPF may be performed when a PDU session is not established in the anchor UPF.
[0482] According to the fourth embodiment, recovery from a failure of the anchor UPF becomes possible, and as a result, availability of data communication in the communication NW can be improved.
[0483] The network device in the present disclosure may be a network function (NF) of the network. For example, the anchor network device may be a network function (NF) of the anchor network. The non-anchor network device may be a network function (NF) of the non-anchor network. This makes it possible to apply the method described in the present disclosure even when, for example, multiple network functions of the network are accommodated in the same device.
[0484] The method described in the present disclosure may be used in situations other than a network failure. For example, the method may be used when QoS deteriorates. The network failure detection described in the present disclosure may be QoS deterioration detection. This makes it possible to perform UPF switching and / or network switching operations before communication is interrupted, thereby improving the availability of the communication network.
[0485] As another example, the method described in the present disclosure may be used in a predetermined situation. The predetermined situation may be, for example, an increase in the load of the UPF or the AMF. This may prevent a further increase in the load of the UPF and / or the AMF, and as a result, prevent a failure of the network.
[0486] In the present disclosure, signaling between different networks may be performed via SEPP (see Non-Patent Document 10), which makes it possible to ensure security in the signaling, for example.
[0487] In the present disclosure, the Inter PLMN User Plane Security (IPUPS) function (see Non-Patent Document 10) may be used for transferring user data between different networks. This makes it possible to ensure security in transferring user data, for example.
[0488] Transmission and reception between a base station and a CN node (excluding the AMF) may be performed via the AMF. Alternatively, transmission and reception between a base station and a CN node (excluding the AMF) may be performed without the AMF. By not using the AMF, the amount of signaling can be reduced and the load on the AMF can be reduced.
[0489] In this specification, a node may be a function.
[0490] In the communication system according to the present disclosure, one or more cells are configured in one gNB. In the present disclosure, although it is described as a gNB or a cell, it may be a gNB or a cell unless otherwise specified.
[0491] In the present disclosure, a gNB may be an MCG or an SCG.
[0492] The above-described embodiments and their modifications are merely examples, and the embodiments and their modifications can be freely combined. Furthermore, any of the components of the embodiments and their modifications can be modified or omitted as appropriate.
[0493] For example, in the above-described embodiments and their modifications, a slot is an example of a time unit for communication in a fifth-generation communication system. A slot may be a scheduling unit. In the above-described embodiments and their modifications, processing described as being performed in slot units may be performed in TTI units, subframe units, subslot units, or minislot units.
[0494] For example, the methods disclosed in the above-described embodiments and their modifications may be applied to the IAB, to communications between an IAB donor and an IAB node, or to processing using a Uu in the IAB.
[0495] 202 Communication terminal device (mobile terminal), 210 Communication system, 213, 240-1, 240-2, 750 Base station device (NR base station, base station), 214 5G core unit, 215 Central unit, 216 Distributed unit, 217 Central unit for control plane, 218 Central unit for user plane, 219 TRP, 301, 403 Protocol processing unit, 302 Application unit, 304, 405 Encoder unit, 305, 406 Modulation unit, 306, 407 Frequency conversion unit, 307-1 to 307-4, 408-1 to 408-4 Antenna, 308, 409 Demodulation unit, 309, 410 Decoder unit, 310, 411, 526 Control unit, 401 EPC communication unit, 402 Other base station communication unit, 412 5GC communication unit, 521 Data Network communication unit, 522 base station communication unit, 523 user plane communication unit, 523-1 PDU processing unit, 523-2 mobility anchoring unit, 525 control plane control unit, 525-1 NAS security unit, 525-2 idle state mobility management unit, 527 session management unit, 527-1 PDU session control unit, 527-2 UE IP address allocation unit, 751-1 to 751-8 beams, 752 cell.
Claims
1. A communications system compatible with a fifth-generation wireless access system, comprising a plurality of networks including a wireless access network and a core network, wherein the plurality of networks include an anchor network, which is a network to which a communications terminal is connected and has a user plane function for directly connecting to a data network to which the communications terminal transmits and receives data, and a non-anchor network which is connected to the data network via the anchor network, wherein the anchor network acquires information relating to communication quality in the non-anchor network from the non-anchor network, detects a fault in the non-anchor network based on the acquired information, and detects a fault in its own network based on information relating to communication quality in the anchor network.
2. A communications system compatible with a fifth-generation wireless access system, comprising a plurality of networks including a wireless access network and a core network, wherein the plurality of networks include an anchor network, which is a network to which a communications terminal is connected and has a user plane function for directly connecting to a data network to which the communications terminal transmits and receives data, and a non-anchor network which connects to the data network via the anchor network, wherein the non-anchor network acquires information relating to communication quality in the anchor network from the anchor network, detects a fault in the anchor network based on the acquired information, and detects a fault in its own network based on information relating to communication quality in the own network.
3. The communication system according to claim 1, characterized in that, when the anchor network detects a failure in the non-anchor network, it requests the non-anchor network to switch the data transmission path within the non-anchor network, and when it detects a failure in its own network, it switches the data transmission path within its own network.
4. A communication system as described in claim 1 or 3, characterized in that, when the anchor network detects a failure in a network device that is directly connected to the data network to transmit and receive data among the network devices that constitute its own network, the anchor network switches the network device that is directly connected to the data network to transmit and receive data.
5. The communication system according to claim 1, characterized in that, when the anchor network detects a failure of the non-anchor network, it requests the non-anchor network to switch the transmission path of data transmitted and received via the non-anchor network to a transmission path that passes through its own network, and, when it detects a failure of its own network, it switches the transmission path of data transmitted and received via its own network to a transmission path that passes through the non-anchor network.
6. The communication system according to claim 2, characterized in that, when the non-anchor network detects a failure in the anchor network, it requests the anchor network to switch the data transmission path within the anchor network, and when it detects a failure in its own network, it switches the data transmission path within its own network.
7. The communication system according to claim 2 or 6, characterized in that, when the non-anchor network detects a failure in a network device that is directly connected to the data network and transmits / receives data among the network devices that constitute the anchor network, the non-anchor network requests the anchor network to switch to the network device that is directly connected to the data network and transmits / receives data.
8. The communication system according to claim 2, characterized in that, when the non-anchor network detects a failure of the anchor network, it requests the anchor network to switch the transmission path of data transmitted and received via the anchor network to a transmission path that passes through its own network, and, when it detects a failure of its own network, it switches the transmission path of data transmitted and received via its own network to a transmission path that passes through the anchor network.