Communication system

Abstract

A communication system of the present application includes a plurality of networks including a radio access network and a core network, the plurality of networks including: an anchor network that is a network having a user plane function directly connected with a data network that is a data transmission destination of a communication terminal; and a non-anchor network that is connected to the data network via the anchor network, the anchor network acquiring information about a communication quality in the non-anchor network from the non-anchor network, performing failure detection of the non-anchor network based on the acquired information, and performing failure detection of the own network.

Description

Technical Field

[0001] This disclosure relates to wireless communication technology. Background Technology

[0002] Within the 3GPP (3rd Generation Partnership Project), the standardization organization for mobile communication systems, the fifth-generation (hereinafter sometimes referred to as "5G") radio access system (e.g., Non-Patent Document 2) was discussed as a successor to Long Term Evolution (LTE) and Long Term Evolution Advanced (LTE-A), one of the fourth-generation radio access systems (refer to Non-Patent Document 1). The technology for the 5G radio band is called "New Radio Access Technology" ("New Radio" is abbreviated as "NR"). The NR system is discussed based on the LTE and LTE-A systems.

[0003] For example, in Europe, the organization METIS is summarizing the requirements for 5G (see Non-Patent Document 3). In 5G wireless access systems, for LTE systems, assuming a system capacity 1000 times greater, data transmission speed 100 times greater, data processing latency 1 / 5th, and simultaneous connection capacity of communication terminals 100 times greater, further reductions in power consumption and device cost can be listed as requirements (see Non-Patent Document 3).

[0004] To meet these requirements, discussions on 5G standards are ongoing within 3GPP (see Non-Patent Literature 4-23).

[0005] As an access method for NR, the downlink direction uses OFDM (Orthogonal Frequency Division Multiplexing), while the uplink direction uses OFDM and DFT-s-OFDM (Discrete Fourier Transform-spread-OFDM). Furthermore, similar to LTE and LTE-A, the 5G system does not include line switching; it uses only packet communication.

[0006] In NR, higher frequencies can be used compared to LTE to increase transmission speed and reduce processing latency.

[0007] In NR, which sometimes uses frequencies higher than LTE, a narrower beam-shaped transmit / receive range is formed (beamforming) and the direction of the beam is changed (beam scanning) so that the capability map can ensure cell coverage.

[0008] use Figure 1 To explain the decisions regarding the frame structure of the NR system in 3GPP as described in Non-Patent Document 1 (Chapter 5). Figure 1 This is an explanatory diagram showing the structure of the wireless frame used in an NR communication system. Figure 1 In NR, a radio frame is 10 ms long. The radio frame is divided into 10 equal-sized subframes. The NR frame structure supports one or more numberologies, i.e., one or more subcarrier spacings (SCS). In NR, a subframe is 1 ms long, and a time slot consists of 14 symbols, regardless of the subcarrier spacing. Furthermore, the number of time slots in a subframe is one when the subcarrier spacing is 15 kHz; the number of time slots in other subcarrier spacings increases proportionally to the subcarrier spacing (see Non-Patent Document 11 (3GPP TS38.211)).

[0009] Non-Patent Document 2 (Chapter 5) and Non-Patent Document 11 record decisions made in 3GPP related to channel structure in NR systems.

[0010] The Physical Broadcast Channel (PBCH) is a channel used for downlink transmission from a base station (hereinafter sometimes simply referred to as a "base station") to a mobile terminal device (hereinafter sometimes simply referred to as a "communication terminal" or "terminal"). The PBCH is transmitted together with the downlink synchronization signal.

[0011] In NR, the downlink synchronization signal consists of a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS). The synchronization signal is transmitted from the base station as a synchronization signal burst (hereinafter sometimes referred to as an SS burst) at a specified period for a specified duration. An SS burst consists of synchronization signal blocks (hereinafter sometimes referred to as SS blocks) for each beam of the base station.

[0012] During the duration of an SS burst, the base station changes its beam to transmit SS blocks for each beam. An SS block consists of P-SS, S-SS, and PBCH.

[0013] The Physical Downlink Control Channel (PDCCH) is the downlink transmission channel from the base station to the communication terminal. The PDCCH transmits Downlink Control Information (DCI). The DCI includes resource allocation information for the Downlink Shared Channel (DL-SCH), one of the transmission channels described later; resource allocation information for the Paging Channel (PCH), another transmission channel described later; and HARQ (Hybrid Automatic Repeat reQuest) information related to the DL-SCH. Additionally, the DCI sometimes includes Uplink Scheduling Grant. The DCI sometimes includes response signals for uplink transmissions, namely Ack (Acknowledgement) / Nack (Negative Acknowledgement). Furthermore, to allow for flexible DL / UL handover within time slots, the DCI sometimes includes Slot Format Indication (SFI). PDCCH or DCI is also known as the L1 / L2 control signal.

[0014] In NR, there are time-domain and frequency-domain regions that can serve as candidates for containing PDCCH. This region is called the Control Resource Set (CORESET). The communication terminal monitors the CORESET to acquire the PDCCH.

[0015] The Physical Downlink Shared Channel (PDSCH) is the downlink transmission channel from the base station to the communication terminal. The PDSCH maps to both the Downlink Shared Channel (DL-SCH) used as the transport channel and the PCH used as the transport channel.

[0016] The Physical Uplink Control Channel (PUCCH) is the uplink transmission channel from the communication terminal to the base station. PUCCH transmits Uplink Control Information (UCI). UCI includes response signals (Ack / Nack) for downlink transmissions, CSI (Channel State Information), and Scheduling Requests (SRs). CSI is composed of RI (Rank Indicator), PMI (Precoding Matrix Indicator), and CQI (Channel Quality Indicator) reports. RI refers to the rank information of the channel matrix in MIMO (Multiple Input Multiple Output). PMI refers to the information of the precoding matrix used in MIMO. CQI is quality information indicating the quality of received data or the quality of the communication line. UCI is sometimes transmitted via PUSCH (described later). PUCCH or UCI is also referred to as L1 / L2 control signals.

[0017] The Physical Uplink Shared Channel (PUSCH) is the uplink transmission channel from the communication terminal to the base station. The PUSCH maps to the Uplink Shared Channel (UL-SCH), which is one of the transmission channels.

[0018] The Physical Random Access Channel (PRACH) is an uplink transmission channel from a communication terminal to a base station. The PRACH transmits the random access preamble.

[0019] Downlink reference signals (RS) are known symbols in NR (Normally Injectable) communication systems. There are four types of downlink reference signals: UE-specific reference signals (DM-RS), phase tracking reference signals (PT-RS), positioning reference signals (PRS), and channel state information reference signals (CSI-RS). As physical layer measurements for communication terminals, there are measurements of the received power (RSRP) and received quality (RSRQ) of the reference signals.

[0020] The uplink reference signal is also a known symbol in NR communication systems. Three types of uplink reference signals are defined: Demodulation Reference Signal (DM-RS), Phase Tracking Reference Signal (PT-RS), and Sounding Reference Signal (SRS).

[0021] The transport channel described in Non-Patent Document 2 (Chapter 5) will be explained. The broadcast channel (BCH) in the downlink transport channel is broadcast to the entire coverage area of ​​its base station (cell). The BCH is mapped to the physical broadcast channel (PBCH).

[0022] HARQ-based retransmission control is applied to the Downlink Shared Channel (DL-SCH). The DL-SCH can broadcast to the entire coverage area of ​​the base station (cell). The DL-SCH supports dynamic or semi-static resource allocation. Semi-static resource allocation is also known as semi-persistent scheduling. To reduce the power consumption of communication terminals, the DL-SCH supports discontinuous reception (DRX). The DL-SCH is mapped to the Physical Downlink Shared Channel (PDSCH).

[0023] The Paging Channel (PCH) supports DRX (Demand Reduction) of communication terminals to reduce power consumption. The PCH is requested to broadcast over the entire coverage area of ​​the base station (cell). The PCH is mapped to physical resources such as the Physical Downlink Shared Channel (PDSCH), which can be dynamically used for traffic.

[0024] HARQ-based retransmission control is applied to the Uplink Shared Channel (UL-SCH) in the uplink transport channel. UL-SCH supports dynamic or quasi-static resource allocation. Quasi-static resource allocation is also known as Configured Grant. UL-SCH is mapped to the Physical Uplink Shared Channel (PUSCH).

[0025] The Random Access Channel (RACH) is limited to control information. RACH is subject to collision risks. RACH is mapped to the Physical Random Access Channel (PRACH).

[0026] The following explains HARQ. HARQ is a technique that improves the communication quality of a transmission line by combining Automatic Repeat Request (ARQ) and Forward Error Correction. HARQ has the following advantages: even for transmission lines where communication quality changes, retransmission can effectively enable error correction. In particular, during retransmission, the quality can be further improved by combining the initial received result with the retransmitted result.

[0027] Here's an example illustrating the retransmission method. When the receiving side cannot correctly decode the received data—in other words, when a CRC (Cyclic Redundancy Check) error occurs (CRC=NG)—a "Nack" is sent from the receiving side to the sending side. The sending side, upon receiving the "Nack," retransmits the data. When the receiving side can correctly decode the received data—in other words, when no CRC error occurs (CRC=OK)—a "ck" is sent from the receiving side to the sending side. The sending side, upon receiving the "Ack," sends the next data.

[0028] Other examples of retransmission methods are illustrated below. If a CRC error occurs at the receiving end, a retransmission request is sent from the receiving end to the sending end. The retransmission request is made via a switch of the NDI (New Data Indicator). The sending end, upon receiving the retransmission request, retransmits the data. If no CRC error occurs at the receiving end, no retransmission request is sent. If the sending end does not receive a retransmission request within a specified time, it is assumed that no CRC error occurred at the receiving end.

[0029] The logical channel described in Non-Patent Document 1 (Chapter 6) will be explained. The Broadcast Control Channel (BCCH) is a downlink channel used to broadcast system control information. The BCCH, as a logical channel, is mapped to either the broadcast channel (BCH) as a transmission channel or the downlink shared channel (DL-SCH).

[0030] The Paging Control Channel (PCCH) is a downlink channel used to transmit paging information and system information updates. The PCCH, as a logical channel, is mapped to the Paging Channel (PCH), which is used as a transport channel.

[0031] The Common Control Channel (CCCH) is a channel used to transmit control information between a communication terminal and a base station. The CCCH is used when there is no RRC connection between the communication terminal and the network. In the downlink direction, the CCCH is mapped to the Downlink Shared Channel (DL-SCH) used as a transport channel. In the uplink direction, the CCCH is mapped to the Uplink Shared Channel (UL-SCH) used as a transport channel.

[0032] The Dedicated Control Channel (DCCH) is a channel used to transmit dedicated control information between a communication terminal and the network in a one-to-one manner. The DCCH is used when there is an RRC connection between the communication terminal and the network. In the uplink, the DCCH is mapped to the Uplink Shared Channel (UL-SCH), and in the downlink, it is mapped to the Downlink Shared Channel (DL-SCH).

[0033] A Dedicated Traffic Channel (DTCH) is a channel used for sending user information and conducting one-to-one communication with the communication terminal. DTCH exists in both the uplink and downlink. In the uplink, DTCH is mapped to the Uplink Shared Channel (UL-SCH), and in the downlink, it is mapped to the Downlink Shared Channel (DL-SCH).

[0034] Location tracking of a communication terminal is performed on a unit consisting of one or more cells. Location tracking is used to locate the communication terminal even in standby mode, enabling calls to the terminal; in other words, it is performed to enable calls to the communication terminal. The area used for location tracking of this communication terminal is called the Tracking Area (TA).

[0035] In NR, calls from communication terminals within a range smaller than the tracking area are supported. This range is called the RAN Notification Area (RNA). Paging of communication terminals in the RRC_INACTIVE state, as described later, occurs within this range.

[0036] In NR, to support wider transmission bandwidths, carrier aggregation (CA) has been studied, which involves combining two or more component carriers (CCs). CA is described in Non-Patent Literature 1.

[0037] In the case of a CA (Communication Terminal), the UE, as a communication terminal, has a unique RRC (Remote Reference Cell) connection with the network (NW). Within the RRC connection, a serving cell provides NAS (Non-Access Stratum) mobility information and security input. This cell is called the Primary Cell (PCell). Depending on the UE's capabilities, secondary serving cells (SCells) are formed together with the PCell to create a group of serving cells. For a single UE, this constitutes a group of serving cells consisting of one PCell and one or more SCells.

[0038] Furthermore, 3GPP includes dual connectivity (DC), where the UE communicates with two base stations to further increase communication capacity. DC is described in non-patent documents 1 and 22.

[0039] Sometimes, one of the base stations performing dual connectivity (DC) is called the "Master Node (MN)," and the other is called the "Secondary Node (SN)." The serving cells comprised of the Master Nodes are sometimes collectively referred to as the Master Cell Group (MCG), and the serving cells comprised of the Secondary Nodes are sometimes collectively referred to as the Secondary Cell Group (SCG). In DC, the Master Cell in the MCG or SCG is called a Special Cell (SpCell or SPCell). The Special Cell in the MCG is called a PCell, and the Special Cell in the SCG is called the Primary SCG Cell (PSCell).

[0040] In addition, in NR, the base station pre-defines a portion of the carrier frequency band for the UE (hereinafter sometimes referred to as the Bandwidth Part (BWP)). The UE transmits and receives data with the base station in this BWP, thereby reducing the power consumption in the UE.

[0041] Furthermore, 3GPP has explored services (or applications) that support sidelink (SL) communication (also known as PC5 communication) in both the EPS (Evolved Packet System) and 5G core systems (described later) (see Non-Patent Documents 1, 2, 26-28). SL communication involves communication between terminals. Examples of services using SL communication include V2X (Vehicle-to-everything) and proximity services. In SL communication, in addition to direct communication between terminals, communication between the UE and the NW via a relay has also been proposed (see Non-Patent Documents 26, 28).

[0042] The physical channels used for SL (refer to Non-Patent Documents 2, 11) are described below. The Physical Sidelink Broadcast Channel (PSBCH) transmits information related to system synchronization and is sent from the UE.

[0043] The Physical Sidelink Control Channel (PSCCH) transmits control information from the UE for sidelink communication and V2X sidelink communication.

[0044] The Physical Sidelink Shared Channel (PSSCH) transmits data from the UE for sidelink communication and V2X sidelink communication.

[0045] The Physical Sidelink Feedback Channel (PSFCH) transmits HARQ feedback from the UE that received the PSSCH to the UE that sent the PSSCH.

[0046] The transmission channel used for SL (refer to Non-Patent Document 1) will be described. The sidelink broadcast channel (SL-BCH) has a predetermined transmission format and is mapped to the PSBCH, which is the physical channel.

[0047] The Sidelink Shared Channel (SL-SCH) supports broadcast transmission. SL-SCH supports both UE autonomous resource selection and resource allocation scheduled by the base station. While UE autonomous resource selection carries a risk of conflict, there are no conflicts when the UE allocates dedicated resources through the base station. Furthermore, SL-SCH supports dynamic link adaptation by modifying transmit power, modulation, and coding. SL-SCH is mapped to the Physical Channel Sequential Channel (PSSCH).

[0048] The logical channels used for SL (refer to Non-Patent Document 2) will be described. The Sidelink Broadcast Control Channel (SBCCH) is a sidelink channel used to broadcast sidelink system information from one UE to other UEs. The SBCCH is mapped to the SL-BCH, which serves as the transport channel.

[0049] The Sidelink Traffic Channel (STCH) is a one-to-many traffic channel used to send user information from one UE to other UEs. The STCH is used only by UEs with sidelink communication capabilities and UEs with V2X sidelink communication capabilities. One-to-one communication between two UEs with sidelink communication capabilities is also achieved through the STCH. The STCH is mapped to the SL-SCH, which serves as the transport channel.

[0050] The Sidelink Control Channel (SCCH) is a control channel used to send control information from one UE to other UEs. The SCCH is mapped to the SL-SCH, which serves as the transport channel.

[0051] In LTE, SL communication only involves broadcast. In NR, in addition to broadcast, support for unicast and groupcast has also been studied as part of SL communication (see Non-Patent Document 27 (3GPP TS23.287)).

[0052] In SL's unicast and multicast communications, it supports HARQ feedback (Ack / Nack), CSI reports, and more.

[0053] In addition, 3GPP is studying Integrated Access and Backhaul (IAB), which uses wireless methods to serve as both access links between UEs and base stations and backhaul links between base stations (see Non-Patent Literature 2, 20, 29).

[0054] For mobile communication systems, several new technologies have been proposed. For example, to improve communication capacity and reliability, a technology has been proposed that allows a single terminal to connect simultaneously to multiple NWs, thereby improving communication capacity and reliability (see Non-Patent Literature 30, 31). Prior Art Literature

[0055] Non-patent literature

[0056] Non-patent literature 1: 3GPP TS36.300 V17.5.0

[0057] Non-patent document 2: 3GPP TS38.300 V17.6.0

[0058] Non-patent literature 3: "Scenarios, requirements and KPIs for 5G mobile and wireless system", ICT-317669-METIS / D1.1

[0059] Non-patent literature 4: 3GPP TR23.799 V14.0.0

[0060] Non-patent literature 5: 3GPP TR38.801 V14.0.0

[0061] Non-patent document 6: 3GPP TR38.802 V14.2.0

[0062] Non-patent document 7: 3GPP TR38.804 V14.0.0

[0063] Non-patent document 8: 3GPP TR38.912 V16.0.0

[0064] Non-Patent Document 9: 3GPP RP-172115

[0065] Non-patent document 10: 3GPP TS23.501 V18.3.0

[0066] Non-patent document 11: 3GPP TS38.211 V18.0.0

[0067] Non-patent document 12: 3GPP TS38.212 V18.0.0

[0068] Non-patent document 13: 3GPP TS38.213 V18.0.0

[0069] Non-patent document 14: 3GPP TS38.214 V18.0.0

[0070] Non-patent document 15: 3GPP TS38.321 V17.6.0

[0071] Non-patent document 16: 3GPP TS38.322 V17.3.0

[0072] Non-patent document 17: 3GPP TS38.323 V17.5.0

[0073] Non-patent document 18: 3GPP TS37.324 V17.0.0

[0074] Non-patent document 19: 3GPP TS38.331 V17.6.0

[0075] Non-patent document 20: 3GPP TS38.401 V17.6.0

[0076] Non-patent document 21: 3GPP TS38.413 V17.6.0

[0077] Non-patent document 22: 3GPP TS37.340 V17.6.0

[0078] Non-patent document 23: 3GPP TS38.423 V17.6.0

[0079] Non-patent document 24: 3GPP TS38.305 V17.6.0

[0080] Non-patent document 25: 3GPP TS23.273 V18.3.0

[0081] Non-patent document 26: 3GPP TR23.703 V12.0.0

[0082] Non-patent document 27: 3GPP TS23.287 V18.1.0

[0083] Non-patent document 28: 3GPP TS23.303 V17.1.0

[0084] Non-patent document 29: 3GPP TS38.340 V17.5.0

[0085] Non-Patent Document 30: 3GPP SWS-230049

[0086] Non-patent document 31: 3GPP TS23.502 V18.3.0

[0087] Non-patent document 32: 3GPP TS23.503 V18.3.0

[0088] Non-patent document 33: 3GPP TR32.851 V12.2.0

[0089] Non-patent document 34: 3GPP TS28.537 V17.3.0 Summary of the Invention

[0090] The technical problem that the invention aims to solve

[0091] When a UE is simultaneously connected to multiple NWs, failures sometimes occur. However, the handling of NW failure detection in communication systems with multiple NWs connected to the UE simultaneously is not disclosed. Therefore, when the UE is simultaneously connected to multiple NWs, NW failures cannot be detected, and countermeasures against NW failures cannot be implemented. As a result, the reliability of communication systems using multiple NWs cannot be guaranteed, and the availability of communication NWs is reduced.

[0092] In view of the above-mentioned issues, one of the objectives of this disclosure is to enable the detection of network faults in a communication system in which a UE can connect to multiple networks simultaneously.

[0093] Technical means for solving technical problems

[0094] The communication system disclosed herein corresponds to a 5th generation wireless access system, which includes multiple networks comprising a wireless access network and a core network. These multiple networks include: an anchor network connected to a communication terminal, which is a user plane network with direct connection to a data network serving as the data transmission and reception target of the communication terminal; and a non-anchor network connected to the data network via the anchor network. The anchor network obtains information about the communication quality in the non-anchor network from the non-anchor network, performs fault detection in the non-anchor network based on the obtained information, and performs fault detection in its own network based on the information about the communication quality in its own network.

[0095] Invention Effects

[0096] According to this disclosure, a communication system capable of detecting network faults while a UE is simultaneously connected to multiple networks can be obtained.

[0097] The purpose, features, aspects, and advantages of this disclosure will become more apparent from the following detailed description and accompanying drawings. Attached Figure Description

[0098] Figure 1 This is an explanatory diagram showing the structure of a wireless frame used in an NR communication system.

[0099] Figure 2 This is a block diagram showing the overall structure of a communication system 210 using the NR method discussed in 3GPP.

[0100] Figure 3 This is a structural diagram of a DC based on a base station connected to the NG core.

[0101] Figure 4 It is shown Figure 2 The diagram shows the structure of the mobile terminal 202.

[0102] Figure 5 It is shown Figure 2 The diagram shows the structure of base station 213.

[0103] Figure 6 This is a block diagram showing the structure of the 5GC section.

[0104] Figure 7 This is a flowchart illustrating the process from cell search to standby mode in a communication terminal (UE) in an NR-based communication system.

[0105] Figure 8 This is a diagram illustrating an example of cell structure in an NR system.

[0106] Figure 9 This is a connection structure diagram illustrating an example of the connection structure of a terminal in SL communication.

[0107] Figure 10 This is a connection structure diagram illustrating an example of a base station connection structure that supports integrated access and backhaul.

[0108] Figure 11 This is a structural diagram showing an example of the connection of multiple NWs in implementation method 1.

[0109] Figure 12 This is a sequence diagram illustrating an example of QoS monitoring setting actions for implementation method 1.

[0110] Figure 13 It is shown Figure 12 The sequence diagram of the process 1100 is an example.

[0111] Figure 14 It is shown Figure 12 The sequence diagram of an example of process 1111.

[0112] Figure 15 It is shown Figure 12 The sequence diagram of the process 1150 is an example.

[0113] Figure 16 It is shown Figure 12 The sequence diagram of an example of process 1161.

[0114] Figure 17This is a sequence diagram illustrating an example of an NW fault detection operation in Implementation 1.

[0115] Figure 18 This is a sequence diagram showing other examples of QoS monitoring settings actions related to implementation method 1.

[0116] Figure 19 This is a sequence diagram showing other examples of NW fault detection actions related to implementation method 1.

[0117] Figure 20 This is a diagram showing the beginning portion of a sequence of other examples of QoS monitoring setting actions related to implementation method 1.

[0118] Figure 21 This is a diagram of the middle part of a sequence of other examples of QoS monitoring setting actions related to implementation method 1.

[0119] Figure 22 This is a diagram showing the end of a sequence of other examples of QoS monitoring setting actions related to implementation method 1.

[0120] Figure 23 This is a sequence diagram illustrating an example of intermediate UPF switching action in a non-anchor point NW, related to implementation method 2.

[0121] Figure 24 It is shown Figure 23 The sequence diagram of the example process 1625.

[0122] Figure 25 This is a sequence diagram showing another example of intermediate UPF switching action in non-anchor point NW, related to implementation method 2.

[0123] Figure 26 This is a sequence diagram illustrating an example of NW switching action in a non-anchor point NW, related to implementation method 3.

[0124] Figure 27 This is a sequence diagram showing other examples of NW switching actions in a non-anchor NW, relating to implementation method 3.

[0125] Figure 28 This is a sequence diagram showing another example of NW switching action in anchor point NW, which is a variation of implementation 3.

[0126] Figure 29 This is a diagram showing the first half of a sequence of examples of the switching action of the anchor point UPF in implementation method 4.

[0127] Figure 30 This is a diagram showing the latter half of a sequence of examples of the switching action of the anchor point UPF in implementation method 4. Detailed Implementation

[0128] Implementation method 1.

[0129] Figure 2 This is a block diagram illustrating the overall structure of a communication system 210 using the NR method discussed in 3GPP. Figure 2 The following explanation is provided. The radio access network is referred to as NG-RAN (Next Generation Radio Access Network) 211. The communication terminal device, i.e., the mobile terminal device (hereinafter referred to as "user equipment" UE) 202, can wirelessly communicate with the base station device (hereinafter referred to as "NR base station (NG-RAN NodeB) gNB)" 213, and uses wireless communication to transmit and receive signals. NG-RAN 211 consists of one or more NR base stations 213.

[0130] Here, "communication terminal device" includes not only mobile terminal devices such as mobile phone terminals, but also stationary devices such as sensors. In the following description, "communication terminal device" will sometimes be abbreviated as "communication terminal".

[0131] Between UE202 and NG-RAN 211, the AS (Access Stratum) protocol is terminated. AS protocols include, for example, RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical Layer). RRC is used for the control plane (hereinafter sometimes referred to as C-plane, C-Plane, or CP), SDAP is used for the user plane (hereinafter sometimes referred to as U-plane, U-Plane, or UP), and PDCP, MAC, RLC, and PHY are used for both the C-plane and U-plane.

[0132] The Radio Resource Control (RRC) protocol between UE202 and NR base station 213 performs broadcasting, paging, and RRC connection management. The states between NR base station 213 and UE202 in RRC include RRC_IDLE, RRC_CONNECTED, and RRC_INACTIVE.

[0133] During RRC_IDLE, PLMN (Public Land Mobile Network) selection, System Information (SI) broadcasting, paging, cell re-selection, and mobility operations are performed. During RRC_CONNECTED, the mobile terminal has an RRC connection and can send and receive data with the network. Additionally, during RRC_CONNECTED, handover (HO) and neighbor cell determination (measurement) are performed. During RRC_INACTIVE, the connection between the 5G core unit 214 and the NR base station 213 is maintained while simultaneously performing System Information (SI) broadcasting, paging, cell re-selection, and mobility operations.

[0134] The gNB213 connects to the 5G core (hereinafter sometimes referred to as the "5GC unit") 214, which includes Access and Mobility Management Function (AMF), Session Management Function (SMF), or User Plane Function (UPF), via the NG interface. Control information and / or user data communication occurs between the gNB213 and the 5GC unit 214. The NG interface is a collective term for the N2 interface between the gNB213 and AMF220, the N3 interface between the gNB213 and UPF221, the N11 interface between AMF220 and SMF222, and the N4 interface between UPF221 and SMF222. One gNB213 can connect to multiple 5GC units 214. The gNBs213 are connected to each other via the Xn interface, enabling communication of control information and / or user data between them.

[0135] The 5GC unit 214 is a host device, specifically a host node, that controls the connection between the NR base station 213 and the mobile terminal (UE) 202, and allocates paging signals for one or more NR base stations (gNB) 213 and / or LTE base stations (E-UTRAN NodeB: eNB). Additionally, the 5GC unit 214 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, and in the inactive and active states. The 5GC unit 214 initiates the paging protocol by sending paging messages to cells belonging to the registered tracking area of ​​the mobile terminal 202.

[0136] gNB213 can form one or more cells. When one gNB213 forms multiple cells, each cell is configured to communicate with UE202.

[0137] The gNB213 can be divided into a Central Unit (CU) 215 and a Distributed Unit (DU) 216. A CU 215 constitutes one unit within the gNB213. One or more DUs 216 constitute one or more cells within the gNB213. A single DU 216 constitutes one or more cells. The CU 215 connects to the DU 216 via an F1 interface, facilitating communication of control information and / or user data between the CU 215 and DU 216. The F1 interface consists of an F1-C interface and an F1-U interface. The CU 215 handles the functions of various protocols including RRC, SDAP, and PDCP, while the DU 216 handles the functions of various protocols including RLC, MAC, and PHY. One or more Transmission Reception Points (TRPs) 219 are sometimes connected to the DU 216. The TRP 219 transmits and receives radio signals with the UE.

[0138] CU215 can be divided into CU(CU-C)217 for the C-side and CU(CU-U)218 for the U-side. CU-C217 is configured as one unit within CU215. CU-U218 is configured as one or more units within CU215. CU-C217 connects to CU-U218 via an E1 interface, facilitating control information communication between the two units. CU-C217 connects to DU216 via an F1-C interface, facilitating control information communication between the two units. CU-U218 connects to DU216 via an F1-U interface, facilitating user data communication between the two units.

[0139] 5G communication systems may include the Unified Data Management (UDM) function and Policy Control Function (PCF) described in Non-Patent Document 10 (3GPP TS23.501). UDM and / or PCF may be included in... Figure 2 In section 5GC214.

[0140] In a 5G communication system, a Location Management Function (LMF) as described in Non-Patent Document 24 (3GPP TS38.305) can be configured. As disclosed in Non-Patent Document 25 (3GPP TS23.273), the LMF can be connected to the base station via the AMF.

[0141] In 5G communication systems, non-3GPP interworking functions (N3IWF) as described in Non-Patent Document 10 (3GPP TS23.501) may also be included. N3IWF can terminate the access network (AN) between the user and the UE in non-3GPP access.

[0142] Figure 3 This is a diagram illustrating a structure based on a DC (dual-connection) linked to the NG core. Figure 3 In the diagram, solid lines represent U-Plane connections, and dashed lines represent C-Plane connections. Figure 3 In this configuration, the primary base station 240-1 can be either a gNB or an eNB. Similarly, the secondary base station 240-2 can also be either a gNB or an eNB. For example, in... Figure 3 In some contexts, the DC structure where the primary base station 240-1 is a gNB and the secondary base station 240-2 is an eNB is sometimes referred to as NG-EN-DC. Figure 3The example shown illustrates a U-Plane connection between the 5GC unit 214 and the secondary base station 240-2 via the primary base station 240-1, but it can also be established directly between the 5GC unit 214 and the secondary base station 240-2. Additionally, Figure 3 In this configuration, the core network EPC (Evolved Packet Core) connected to the LTE and LTE-A systems can replace the 5GC unit 214 and connect to the main base station 240-1. The U-Plane connection between the EPC and the secondary base station 240-2 can be directly established.

[0143] Figure 4 It is shown Figure 2 The diagram shows the structure of the mobile terminal 202. Figure 4 The transmission processing of the mobile terminal 202 shown will be described. First, control data from the control unit 310 and user data from the application unit 302 are sent to the protocol processing unit 301. Buffering of the control data and user data is possible. This buffering can be set in the control unit 310, the application unit 302, or the protocol processing unit 301. The protocol processing unit 301 performs protocol processing such as SDAP, PDCP, RLC, and MAC, for example, determining the transmission target base station in DC and assigning headers to various protocols. The protocol-processed data is transmitted to the encoding unit 304 for error correction and other encoding processing. Alternatively, data may be output directly from the protocol processing unit 301 to the modulation unit 305 without encoding processing. The data encoded by the encoding unit 304 is modulated in the modulation unit 305. Precoding for MIMO may also be performed in the modulation unit 305. After the modulated data is converted into a baseband signal, it is output to the frequency conversion unit 306 and converted into a wireless transmission frequency. Subsequently, the transmitted signal was sent from antennas 307-1 to 307-4 to base station 213. Figure 4 The example shown has four antennas, but the number of antennas is not limited to four.

[0144] Furthermore, the receiving process of the mobile terminal 202 is performed as follows: Wireless signals from the base station 213 are received via antennas 307-1 to 307-4. The received signal is converted from the wireless receiving frequency to a baseband signal by the frequency conversion unit 306, and demodulation processing is performed in the demodulation unit 308. Waiting calculations and multiplication processes can be performed in the demodulation unit 308. The demodulated data is transmitted to the decoding unit 309 for error correction and other decoding processing. The decoded data is transmitted to the protocol processing unit 301, where protocol processing such as MAC, RLC, PDCP, and SDAP is performed, including actions such as header removal in each protocol. Of the data after protocol processing, control data is transmitted to the control unit 310, and user data is transmitted to the application unit 302.

[0145] The series of processes of the mobile terminal 202 are controlled by the control unit 310. Therefore, although in Figure 4 The details have been omitted, but the control unit 310 is also connected to each of the units 302, 304 to 309.

[0146] Each part of the mobile terminal 202, such as the control unit 310, protocol processing unit 301, encoding unit 304, and decoding unit 309, is implemented, for example, by a processing circuit comprising a processor and a memory. For example, the control unit 310 is implemented by the processor executing a program describing a series of processes of the mobile terminal 202. The program describing the series of processes of the mobile terminal 202 is stored in a memory. Examples of memory are non-volatile or volatile semiconductor memories such as RAM (Random Access Memory), ROM (Read Only Memory), and flash memory. Each part of the mobile terminal 202, such as the control unit 310, protocol processing unit 301, encoding unit 304, and decoding unit 309, can be implemented by dedicated processing circuits such as FPGA (Field Programmable Gate Array), ASIC (Application Specific Integrated Circuit), and DSP (Digital Signal Processor). Figure 4 In this context, the number of antennas used for transmitting and the number of antennas used for receiving in the mobile terminal 202 may be the same or different.

[0147] Figure 5 It is shown Figure 2 The diagram shows the structure of base station 213. Figure 5 The transmission processing of the base station 213 shown 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 (5GC unit 214, etc.). The other base station communication units 402 transmit and receive data with other base stations. The EPC communication unit 401, the 5GC communication unit 412, and the other base station communication units 402 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 units 402 are sent to the protocol processing unit 403. Buffering of control data and user data can be performed. This buffering can be provided in the control unit 411, the EPC communication unit 401, the 5GC communication unit 412, or the other base station communication units 402.

[0148] The protocol processing unit 403 performs protocol processing for SDAP, PDCP, RLC, MAC, etc., such as routing transmitted data in DC and assigning headers to various protocols. The protocol-processed data is transmitted to the encoding unit 405 for error correction and other encoding processing. Alternatively, data may be output directly from the protocol processing unit 403 to the modulation unit 406 without encoding processing. Furthermore, data can be transmitted from the protocol processing unit 403 to other base station communication units 402. For example, in DC, data transmitted from the 5GC communication unit 412 or the EPC communication unit 401 can be transmitted to other base stations, such as auxiliary base stations, via other base station communication units 402. The encoded data undergoes modulation processing in the modulation unit 406. Precoding for MIMO can also be performed in the modulation unit 406. After the modulated data is converted into a baseband signal, it is output to the frequency conversion unit 407 and converted into a wireless transmission frequency. Then, using antennas 408-1 to 408-4, the transmission signal is transmitted to one or more mobile terminals 202. Figure 5 The example shown has four antennas, but the number of antennas is not limited to four.

[0149] Furthermore, the reception processing of base station 213 is performed as follows: Wireless signals from one or more mobile terminals 202 are received by antennas 408-1 to 408-4. The received signals are converted from the wireless receiving frequency to a baseband signal by frequency conversion unit 407, and demodulated in demodulation unit 409. The demodulated data is transmitted to decoding unit 410 for error correction and other decoding processing. The decoded data is transmitted to protocol processing unit 403, where protocol processing such as MAC, RLC, PDCP, and SDAP is performed, including actions such as header removal in each protocol. Of the data after protocol processing, control data is transmitted to control unit 411, 5GC communication unit 412, EPC communication unit 401, or other base station communication unit 402, and user data is transmitted to 5GC communication unit 412, EPC communication unit 401, or other base station communication unit 402. Data sent from other base station communication units 402 can be transmitted to 5GC communication unit 412 or EPC communication unit 401. This data could be, for example, uplink data transmitted from the DC to the 5GC communication unit 412 or the EPC communication unit 401 via other base stations.

[0150] The series of processes of base station 213 are controlled by control unit 411. Therefore, although in Figure 5 The details have been omitted, but the control unit 411 is also connected to the various units 401, 402, 405 to 410, 412.

[0151] The various parts of base station 213, such as control unit 411, protocol processing unit 403, 5GC communication unit 412, EPC communication unit 401, other base station communication unit 402, encoding unit 405, and decoding unit 410, are implemented similarly to those of mobile terminal 202 by processing circuits comprising a processor and memory, or dedicated processing circuits such as FPGA, ASIC, and DSP. Figure 5 In this system, the number of antennas used for transmitting and the number of antennas used for receiving in base station 213 can be the same or different.

[0152] As Figure 2 The example of the structure of CU215 shown, except Figure 5 In addition to the encoding unit 405, modulation unit 406, frequency conversion unit 407, antennas 408-1 to 408-4, demodulation unit 409, and decoding unit 410 shown, a structure with a DU communication unit is sometimes used. The DU communication unit is connected to the protocol processing unit 403. The protocol processing unit 403 in CU215 performs protocol processing for PDCP, SDAP, etc.

[0153] As Figure 2 The example of the structure of DU216 shown, except Figure 5 In addition to the EPC communication unit 401, other base station communication units 402, and 5GC communication unit 412 shown, a structure with a CU communication unit is sometimes used. The CU communication unit is connected to the protocol processing unit 403. The protocol processing unit 403 in DU216 performs protocol processing for PHY, MAC, RLC, etc.

[0154] Figure 6 This is a block diagram showing the structure of the 5GC section. Figure 6 The above is shown in the figure. Figure 2 The structure of the 5GC section 214 shown. Figure 6 It shows in Figure 2 The 5GC section 214 shown includes the structures of AMF, SMF, and UPF. Figure 6In the example shown, the AMF can have the functions of the control plane control unit 525, the SMF can have the functions of the session management unit 527, and the UPF can have the functions of the user plane communication unit 523 and the data network communication unit 521. The data network communication unit 521 performs data transmission and reception between the 5GC unit 214 and the data network. The base station communication unit 522 performs data transmission and reception between the 5GC unit 214 and the base station 21 via the NG interface. User data sent from the data network is transmitted from the data network communication unit 521 to the base station communication unit 522 via the user plane communication unit 523, and then sent to one or more base stations 213. User data sent from the base station 213 is transmitted from the base station communication unit 522 to the data network communication unit 521 via the user plane communication unit 523, and then sent to the data network.

[0155] Control data sent from base station 213 is transmitted from base station communication unit 522 to control plane control unit 525. Control plane control unit 525 can transmit control data to session management unit 527. Control data can be sent from data network. Control data sent from data network can be sent from data network communication unit 521 to session management unit 527 via user plane communication unit 523. Session management unit 527 can send control data to control plane control unit 525.

[0156] The user plane communication unit 523 includes a PDU processing unit 523-1, a mobility anchoring unit 523-2, etc., and performs overall processing for the user plane (hereinafter sometimes referred to as U-Plane). The PDU processing unit 523-1 processes data packets, such as sending and receiving packets with the data network communication unit 521 and sending and receiving packets with the base station communication unit 522. The mobility anchoring unit 523-2 is responsible for anchoring the data path when the UE moves.

[0157] The session management unit 527 manages the PDU sessions set up between the UE and the UPF. The session management unit 527 includes a PDU session control unit 527-1 and a UE IP address allocation unit 527-2. The PDU session control unit 527-1 manages the PDU sessions between the mobile terminal 202 and the 5GC unit 214. The UE IP address allocation unit 527-2 allocates IP addresses for the mobile terminal 202.

[0158] 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 C-Plane). The NAS security unit 525-1 performs security protection for NAS (Non-Access Stratum) messages, etc. The idle state mobility management unit 525-2 performs mobility management in standby state (idle state: RRC_IDLE state, or simply idle), generation and control of paging signals in standby state, addition, deletion, updating, retrieval of tracking areas for one or more mobile terminals 202 within the coverage area, and tracking area list management, etc.

[0159] The series of processes in the 5GC unit 214 are controlled by the control unit 526. Therefore, although in Figure 6 The details are omitted, but the control unit 526 is connected to each of the units 521-523, 525, and 527. The units of the 5GC unit 214 are similar to the control unit 310 of the mobile terminal 202 described above, and are implemented, for example, by a processing circuit comprising a processor and a memory, or by a dedicated processing circuit such as an FPGA, ASIC, or DSP.

[0160] Next, an example of a cell search method in a communication system is shown. Figure 7 This is a flowchart illustrating the process of a communication terminal (UE) in an NR-based communication system from cell search to standby mode. If the communication terminal starts cell search, in step ST601, the first synchronization signal (P-SS) and the second synchronization signal (S-SS) sent from surrounding base stations are used to achieve synchronization of time slot timing and frame timing.

[0161] P-SS and S-SS are collectively referred to as Synchronization Signal (SS). The Synchronization Signal (SS) contains a synchronization code that corresponds one-to-one with the PCI (Physical Cell Identifier) ​​assigned to each cell. In this discussion, the number of PCIs is set to 1008. The communication terminal uses these 1008 PCIs to achieve synchronization and detects (determines) the PCIs of synchronized cells.

[0162] In step ST602, the communication terminal receives the PBCH for the next cell to be synchronized. The BCCH on the PBCH maps to the MIB (Master Information Block), which contains cell structure information. Therefore, by receiving the PBCH and obtaining the BCCH, the MIB can be obtained. Information in the MIB includes, for example, the SFN (System Frame Number), scheduling information of SIB (System Information Block) 1, subcarrier spacing of SIB1, and DM-RS location information.

[0163] Additionally, the communication terminal obtains the SS block identifier via the PBCH. A portion of the bit string of the SS block identifier is contained in the MIB. The remaining bit string is contained in the identifier used to generate the DM-RS sequence accompanying the PBCH. The communication terminal uses the MIB contained in the PBCH and the DM-RS sequence accompanying the PBCH to obtain the SS block identifier.

[0164] Next, in step ST603, the communication terminal measures the received power of the SS block.

[0165] Next, in step ST604, the communication terminal selects the cell with the best reception quality from the more than one cell detected up to step ST603, for example, selecting the cell with the highest reception power, i.e., the optimal cell. Additionally, the communication terminal selects the beam with the best reception quality, for example, selecting the beam with the highest reception power in the SS block, i.e., the optimal beam. The selection of the optimal beam is, for example, using the reception power of the SS block identified by each SS block.

[0166] Next, in step ST605, the communication terminal receives the DL-SCH based on the scheduling information of SIB1 contained in the MIB, and obtains SIB1 (System Information Block) from the broadcast information BCCH. SIB1 contains information related to access to the cell, cell structure information, and scheduling information of other SIBs (SIBk: an integer k ≥ 2). In addition, SIB1 contains the Tracking Area Code (TAC).

[0167] 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 stored by the communication terminal. The tracking area list is also called the TAI list. TAI is identification information used to identify the tracking area, consisting of the MCC (Mobile Country Code), MNC (Mobile Network Code), and TAC (Tracking Area Code). MCC is the country code. MNC is the network code. TAC is the tracking area code number.

[0168] If the comparison result in step ST606 is the same as the TAC received in step ST605, and it is also included in the tracking area list, then the communication terminal enters standby mode in that cell. If the comparison shows that the TAC received in step ST605 is not included in the tracking area list, then the communication terminal requests a change of tracking area from the core network (EPC) containing the MME, etc., through that cell to perform a TAU (Tracking Area Update).

[0169] The apparatus constituting the core network (hereinafter sometimes referred to as "core network-side apparatus") updates the tracking area list based on the TAU request signal and the identification number (UE-ID, etc.) of the communication terminal sent from the communication terminal. The core network-side apparatus sends the updated tracking area list to the communication terminal. The communication terminal rewrites (updates) its own TAC list based on the received tracking area list. Afterward, the communication terminal enters standby mode in the cell.

[0170] Next, examples of random access methods in a communication system are shown. In random access, 4-step random access and 2-step random access are used. Furthermore, for 4-step and 2-step random access, there are conflict-based random access, which may cause timing conflicts with other mobile terminals, and conflict-free random access.

[0171] An example of a conflict-based four-step random access method is shown. As step 1, the mobile terminal sends a random access preamble to the base station. The random access preamble can be selected by the mobile terminal from a predefined range, or it can be assigned separately to the mobile terminal and notified by the base station.

[0172] As a second step, the base station sends a random access response to the mobile terminal. The random access response includes uplink scheduling information used in the third step, and the terminal identifier used in the uplink transmission in the third step.

[0173] As step 3, the mobile terminal sends an uplink transmission to the base station. The mobile terminal uses the information obtained in step 2 in this uplink transmission. As step 4, the base station notifies the mobile terminal whether a conflict has been resolved. Mobile terminals notified of no conflict end the random access process. Mobile terminals notified of a conflict restart the process from step 1.

[0174] The conflict-free 4-step random access method differs from the conflict-based 4-step random access method in the following ways: First, before step 1, the base station pre-assigns a random access preamble and uplink scheduling to the mobile terminal. Second, notification regarding conflict resolution is not required in step 4.

[0175] An example of a collision-based two-step random access method is shown. In step 1, the mobile terminal sends a random access preamble and an uplink transmission to the base station. In step 2, the base station notifies the mobile terminal of whether a collision has occurred. Mobile terminals notified of no collision end the random access process. Mobile terminals notified of a collision restart the process from step 1.

[0176] The conflict-free two-step random access method differs from the conflict-based two-step random access method in the following way: Before step 1, the base station pre-assigns a random access preamble and uplink scheduling to the mobile terminal. Additionally, in step 2, the base station sends a random access response to the mobile terminal.

[0177] Figure 8 This illustrates an example of the structure of a cell in NR. In an NR cell, a narrow beam is formed and its direction is changed for transmission. Figure 8 In the example shown, base station 750 uses beam 751-1 to transmit and receive data with the mobile terminal at certain times. At other times, base station 750 uses beam 751-2 to transmit and receive data with the mobile terminal. Similarly, base station 750 uses one or more of beams 751-3 to 751-8 to transmit and receive data with the mobile terminal. Thus, base station 750 constitutes a wide-range cell 752.

[0178] exist Figure 8 The example shown depicts a base station 750 using 8 beams, but the number of beams can also be different from 8. Additionally, in Figure 8 In the example shown, the number of beams used simultaneously by base station 750 is set to one, but it can also be multiple.

[0179] Beam identification uses the concept of QCL (Quasi-CoLocation) (refer to Non-Patent Document 14 (3GPP TS 38.214)). That is, it is identified by information indicating which reference signal (e.g., SS block, CSI-RS) the beam can be considered to be identical to. This information sometimes includes the type of information about which beams can be considered identical, such as information about Doppler shift, Doppler shift spread, average delay, average delay spread, and spatial Rx parameters (refer to Non-Patent Document 14 (3GPP TS 38.214)).

[0180] In 3GPP, sidelinks (SL) are supported for D2D (Device to Device) communication and V2V (Vehicle to Vehicle) communication (see Non-Patent Document 1 and Non-Patent Document 16). SL is defined through the PC5 interface.

[0181] In SL communication, in addition to broadcasting, support for PC5-S signaling was investigated to support unicast and groupcast (see Non-Patent Document 27 (3GPP TS23.287)). For example, PC5-S signaling was implemented to establish SL, i.e., the link used to implement PC5 communication. This link is implemented in the V2X layer and is also known as a Layer 2 link.

[0182] In addition, support for RRC signaling is being researched in SL communication (see Non-Patent Document 27 (3GPP TS23.287)). RRC signaling in SL communication is also referred to as PC5 RRC signaling. For example, the ability to notify UEs of each other during PC5 communication, and the notification of AS layer settings for using PC5 communication for V2X communication, have been proposed.

[0183] Figure 9 The diagram shows an example of the connection structure of a mobile terminal in SL communication. Figure 9 In the example shown, UE805 and UE806 exist within the coverage area 803 of base station 801. UL / DL communication 805 occurs between base station 801 and UE806. UL / DL communication 808 occurs between base station 801 and UE806. SL communication 810 occurs between UE805 and UE806. UE811 and UE812 exist outside the coverage area 803. SL communication 814 occurs between UE805 and UE811. Additionally, SL communication 816 occurs between UE811 and UE812.

[0184] As an example of communication between the UE and NW via relay in SL communication, Figure 9The UE805 shown relays the communication between UE811 and base station 801.

[0185] UEs that perform relays sometimes use with Figure 4 Same structure. Use Figure 4 The relay processing in the UE will be explained. The relay processing of UE805 in communication from UE811 to base station 801 will be explained. Radio signals from UE811 are received via antennas 307-1 to 307-4. The received signal is converted from the radio receiving frequency to a baseband signal by frequency conversion unit 306, and demodulation processing is performed in demodulation unit 308. In demodulation unit 308, waiting calculations and multiplication processes can be performed. The demodulated data is transmitted to decoding unit 309 for error correction and other decoding processing. The decoded data is transmitted to protocol processing unit 301, where protocol processing for communication with UE811, such as MAC, RLC, etc., is performed, including actions such as header removal in each protocol. Additionally, protocol processing for communication with base station 801, such as RLC, MAC, etc., is performed, including actions such as header assignment in each protocol. In the protocol processing unit 301 of UE811, PDCP and SDAP protocol processing are sometimes also performed. The data that has undergone protocol processing is transmitted to the encoding unit 304 for error correction and other encoding processing. Alternatively, data may be output directly from the protocol processing unit 301 to the modulation unit 305 without undergoing encoding processing. The data encoded by the encoding unit 304 is then modulated in the modulation unit 305. MIMO precoding may also be performed in the modulation unit 305. After the modulated data is converted into a baseband signal, it is output to the frequency conversion unit 306 and converted into a wireless transmission frequency. The transmission signal is then transmitted from antennas 307-1 to 307-4 to the base station 801.

[0186] The above content illustrates an example of UE805 relaying communication from UE811 to base station 801, but the same process is used in the relaying of communication from base station 801 to UE811.

[0187] 5G base stations can support Integrated Access and Backhaul (IAB) (see Non-Patent Documents 2, 20). An IAB-supporting base station (hereinafter sometimes referred to as an IAB base station) consists of a CU (IAB host CU) acting as an IAB host, a DU (IAB host DU) acting as an IAB host, and IAB nodes that connect to the IAB host DU and the UE via radio interfaces. An F1 interface is provided between the IAB nodes and the IAB host CU (see Non-Patent Document 2).

[0188] Figure 10The diagram illustrates an example of IAB base station connections. IAB host CU901 is connected to IAB host DU902. IAB node 903 connects to IAB host DU902 using a radio interface. IAB node 903 connects to IAB node 904 using a radio interface. That is, sometimes multiple levels of IAB node connections are made. UE905 connects to IAB node 904 using a radio interface. UE906 sometimes connects to IAB node 903 using a radio interface, and UE907 sometimes connects to IAB host DU902 using a radio interface. Multiple IAB host DU902s can connect to IAB host CU901, multiple IAB nodes 903 can connect to IAB host DU902, and multiple IAB nodes 904 can connect to IAB node 903.

[0189] In the connections between the IAB host DU and IAB nodes, and between IAB nodes, a BAP (Backhaul Adaptation Protocol) layer is set up (see Non-Patent Document 29). The BAP layer performs actions such as routing received data to the IAB host DU and / or IAB nodes, and mapping it to the RLC channel (see Non-Patent Document 29).

[0190] As an example of the structure of the IAB host CU, the same structure as CU215 is used.

[0191] As an example of the structure of the IAB host DU, it uses the same structure as DU216. In the protocol processing section of the IAB host DU, BAP layer processing is performed, such as assigning BAP headers to downlink data, routing for IAB nodes, and removing BAP headers from uplink data.

[0192] As an example of the structure of IAB nodes, sometimes in addition to Figure 5 The structure shown is excluding the EPC communication unit 401, other base station communication units 402, and 5GC communication unit 412.

[0193] use Figure 5 , Figure 10The transmit / receive processing in the IAB node will be explained. The transmit / receive processing of IAB node 903 in communication between IAB host CU901 and UE905 will be described. In uplink communication from UE905 to IAB host CU901, the radio signal from IAB node 904 is received through antenna 408 (part or all of antennas 408-1 to 408-4). The received signal is converted from the radio receiving frequency to a baseband signal by frequency conversion unit 407, and demodulation processing is performed in demodulation unit 409. The demodulated data is transmitted to decoding unit 410 for error correction and other decoding processing. The decoded data is transmitted to protocol processing unit 403, where protocol processing for communication with IAB node 904, such as MAC, RLC, etc., and actions such as header removal in each protocol, are performed. In addition, routing to the IAB host DU902 using the BAP header is performed, and protocol processing for communication with the IAB host DU902, such as assigning headers to each protocol, is carried out. The protocol-processed data is transmitted to the encoding unit 405 for error correction and other encoding processing. Alternatively, data may be output directly from the protocol processing unit 403 to the modulation unit 406 without encoding processing. The encoded data is modulated in the modulation unit 406. MIMO precoding may also be performed in the modulation unit 406. After the modulated data is converted into a baseband signal, it is output to the frequency conversion unit 407 and converted into a radio transmission frequency. Then, the transmission signal is transmitted to the IAB host DU902 using antennas 408-1 to 408-4. The same processing is performed in downlink communication from the IAB host CU901 to the UE905.

[0194] In IAB node 904, the same send and receive processing is performed as in IAB node 903. In the protocol processing unit 403 of IAB node 903, as part of the BAP layer processing, such as assigning BAP headers in uplink communication and routing to IAB node 904, and removing BAP headers in downlink communication, etc.

[0195] In a 3GPP mobile communication system, a UE can connect to multiple NWs. The connection between the UE and the data network (DN) can be made via an anchor UPF (a UPF directly connected to the DN). An anchor NW (a network with an anchor UPF, hereinafter the same) can connect to one or more of these NWs connected to the UE. In this specification, an NW without an anchor UPF is referred to as a non-anchor NW. Furthermore, the device constituting an anchor NW is referred to as an anchor NW device, and the device constituting a non-anchor NW is referred to as a non-anchor NW device.

[0196] Figure 11 This is a block diagram illustrating an example of a UE connecting to multiple NWs. Figure 11 In the example shown, the UE is connected to both NW1090 and NW1091. Figure 11 In the example shown, 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, while 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 the DN.

[0197] When a UE is simultaneously connected to multiple NWs, failures sometimes occur. However, the handling of NW failure detection in communication systems with multiple NWs connected to the UE simultaneously is not disclosed. Therefore, when a UE is simultaneously connected to multiple NWs, NW failures cannot be detected, and countermeasures against NW failures cannot be implemented, resulting in reliability issues in communication systems using multiple NWs.

[0198] This embodiment discloses a method for solving the above-mentioned problems.

[0199] In this embodiment, the anchor NW detects NW faults. This detection can be performed by the Network Function (NF) within the anchor NW, or by the anchor NW device itself. For example, the SMF (Signaling Function) of the anchor NW (hereinafter sometimes referred to as the anchor SMF) can perform this detection. Thus, for example, NW fault detection and session management can be performed by the same device, resulting in shorter time up to NW fault detection or reduced signaling.

[0200] NW fault detection can utilize QoS (Quality of Service) monitoring reports (see Non-Patent Documents 10, 31) or QoE (Quality of Experience) measurement results (see Non-Patent Document 2). For example, an anchor NW can detect NW faults using QoS-related information, such as QoS monitoring reports, or QoE-related information, such as QoE measurement results. An anchor NW can also detect NW faults using both QoS-related and QoE-related information. QoS-related and QoE-related information are information related to communication quality. QoE measurement results can, for example, be measurement results from the UE. The UE can notify the base station of the measurement results. The base station can notify the measurement results to the OAM (Operation, Administration and Maintenance) (see Non-Patent Document 33) functional unit, the MnS (Management Service) (see Non-Patent Document 34) functional unit, or the NF (e.g., SMF). This notification from the base station to the NF (e.g., SMF) can be done via the AMF or directly.

[0201] NF (e.g., SMF) can obtain QoE measurement results from the base station, or from OAM, or from MnS, or from NWDAF (Network Data Analytics Function) (see Non-Patent Document 10).

[0202] An anchor NW device can request QoS monitoring from a non-anchor NW device. For example, an anchor SMF can request QoS monitoring from a non-anchor NW device. The anchor SMF can make this request to the SMF of the non-anchor NW (hereinafter sometimes referred to as the non-anchor SMF). This request from the anchor SMF to the non-anchor NW device (e.g., the non-anchor SMF) can be made, for example, via SEPP. Signaling transmission and reception between the anchor SMF and the non-anchor SMF can be performed via SEPP.

[0203] QoS monitoring requests can be made by an Application Function (AF). The AF can make QoS monitoring requests to non-anchor NWs via the anchor NW, or directly to the non-anchor NW. This request from the AF can be made to the PCF of the anchor NW and / or non-anchor NW, or to the NEF (Network Exposure Function) (see Non-Patent Document 10), or via the NEF to the PCF.

[0204] QoS monitoring requests from the anchor SMF to the non-anchor NW device can be made either when the PDU session is established or when the PDU session is changed. For example, information related to this request can be included in the signaling of the PDU session establishment request or the signaling of the PDU session change request. The signaling for the PDU session establishment request can, for example, use Nsmf_PDUSession_Establish_Request (see Non-Patent Document 31). The signaling for the PDU session change request can, for example, use Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31).

[0205] A non-anchor SMF can request QoS monitoring from a UPF. This request from the non-anchor SMF to the UPF can be triggered, for example, by a QoS monitoring request from an anchor SMF to a non-anchor SMF, or it can be initiated spontaneously by the non-anchor SMF. The UPF can be, for example, an intermediate UPF (a UPF that is not an anchor UPF). This intermediate UPF can be an intermediate UPF belonging to a non-anchor NW (e.g., Figure 11 (See UPF#2 shown). This UPF can be used to perform QoS monitoring triggered by this request.

[0206] A non-anchor SMF can request QoS monitoring from a base station. This base station can be, for example, a base station belonging to the same NW as the non-anchor SMF. This request from the non-anchor SMF to the base station can be made, for example, via an AMF belonging to the same NW as the non-anchor SMF (hereinafter sometimes referred to as a non-anchor AMF). This request from the non-anchor SMF to the base station can be triggered, for example, by a QoS monitoring request from an anchor SMF to a non-anchor SMF, or it can be initiated spontaneously by the non-anchor SMF. The base station can then perform QoS monitoring triggered by this request.

[0207] Anchor NWs can determine QoS monitoring-related information, such as QoS monitoring policies, within each NW. Each NW can contain anchor NWs or non-anchor NWs. For example, the PCF of an anchor NW (hereinafter sometimes referred to as the anchor PCF) can determine this information. As another example, AFs can determine QoS monitoring-related information. The AF can notify the anchor PCF of this information. Anchor SMFs can obtain this information from the anchor PCF. Anchor SMFs can use QoS monitoring policies to determine QoS monitoring settings. For example, the anchor SMF can determine which device performs QoS monitoring.

[0208] The QoS monitoring strategy may include information disclosed, for example, in section 6.1.3.21 of non-patent document 32 (3GPP TS23.503). For example, it may include information about QoS parameters, information about reporting periods, and information about reporting triggering conditions (e.g., thresholds, minimum waiting time until subsequent reports).

[0209] As another example of determining QoS monitoring-related information in each NW, a non-anchor NW can determine QoS monitoring-related information, such as QoS monitoring policies, within the non-anchor NW. For example, the PCF of the non-anchor NW (hereinafter sometimes referred to as the non-anchor PCF) can determine this information. As another example, an AF can determine QoS monitoring-related information in a non-anchor NW. The AF can notify the non-anchor PCF of this information. The non-anchor SMF can obtain this information from the non-anchor PCF. This AF can exist in a DN, an anchor NW, or a non-anchor NW.

[0210] An anchor NW can determine which NW decides the QoS monitoring settings in other NWs. For example, an anchor NW can determine which NW decides the QoS monitoring settings in non-anchor NWs. An anchor SMF can include information indicating which NW is performing QoS monitoring settings in its QoS monitoring requests to non-anchor SMFs and notify them accordingly. Non-anchor SMFs can use this information to determine which NW is performing QoS monitoring settings. For example, a non-anchor SMF can notify a non-anchor PCF of the QoS monitoring settings decided by the anchor NW upon receiving information indicating that an anchor NW is performing QoS monitoring settings, or it can request QoS monitoring settings from a non-anchor PCF upon receiving information indicating that a non-anchor NW is performing QoS monitoring settings. This, for example, can prevent conflicts between QoS monitoring settings decided by anchor NWs and QoS monitoring settings decided by non-anchor NWs, thus preventing QoS monitoring-related malfunctions.

[0211] As another example, the NW performing QoS monitoring settings can be determined based on whether the QoS monitoring request from the anchor SMF to the non-anchor SMF contains QoS monitoring settings. For example, the anchor NW can be determined to determine the QoS monitoring settings based on whether the request contains QoS monitoring settings, while the non-anchor NW can be determined to determine the QoS monitoring settings based on whether the request contains QoS monitoring settings. The non-anchor SMF can be triggered by the inclusion of QoS monitoring settings in the request to use the QoS monitoring settings determined by the anchor NW, or it can be triggered by the absence of QoS monitoring settings in the request to know whether the non-anchor NW is performing QoS monitoring settings. Thus, for example, the size of the signaling in the QoS monitoring request can be reduced.

[0212] As another example of QoS monitoring settings decisions in each NW, both NWs can determine their QoS monitoring settings. This, for example, avoids complexity in the communication system.

[0213] The priority of which NW (Nest-Wide Controller) determines the QoS monitoring settings can be specified by the standard. For example, the QoS monitoring settings determined by the anchor NW can take precedence over the QoS monitoring settings determined by the non-anchor NW, or the QoS monitoring settings determined by the non-anchor NW can take precedence over the QoS monitoring settings determined by the anchor NW.

[0214] As examples of information included in QoS monitoring settings, the following (1) to (10) are disclosed.

[0215] (1) Information on the conditions for initiating QoS monitoring reports.

[0216] (2) Information about the QoS type of the monitored object.

[0217] (3) Information related to UE.

[0218] (4) Information about PDU sessions.

[0219] (5) Information about QoS flows.

[0220] (6) Information about the entity conducting QoS monitoring.

[0221] (7) Information about the entity that performs NW fault detection.

[0222] (8) Information about QoS monitoring policies.

[0223] (9) Information about upward / downward movement.

[0224] (10) The combination of (1) to (9) above.

[0225] The above (1) may include, for example, information indicating periodic reporting, or information indicating reporting triggered by a specified event.

[0226] Information regarding the reporting cycle may be included in (1) above. This can, for example, prevent unnecessary reporting and consequently reduce the signaling load in the communication system.

[0227] The above (1) may include information about the event. The event may be a QoS below a specified threshold, a QoS below a specified threshold, a QoS above a specified threshold, or a QoS above a specified threshold. For example, the above (1) may include information about the threshold for the event. Information about the period during which QoS measurements are performed may also be included. By including information about the QoS measurement period, for example, over-reporting of QoS monitoring results can be prevented.

[0228] The above (2) can be, for example, packet delay, congestion, data rate, the variation in packet delay, or the round-trip delay of packets. Packet delay can be, for example, uplink packet delay or downlink packet delay. The variation in packet delay can be, for example, the variance of packet delay or the standard deviation of packet delay.

[0229] The above (3) may, for example, be information about the UE related to the data being monitored for QoS. This information may be information about the UE receiving the data or information about the UE sending the data. The above (3) may include, for example, information identifying the UE. Thus, for example, the UPF can quickly identify data traffic that is being monitored for QoS.

[0230] The above (4) may be PDU session information related to the QoS monitoring object data. The above (4) may include, for example, information that identifies the PDU session. Thus, for example, the same effect as described above can be obtained.

[0231] The above (5) may be, for example, information about QoS flows related to the data of the QoS monitoring object. The above (5) may include, for example, information that identifies QoS flows. Thus, for example, the same effect as described above can be obtained.

[0232] The above (6) may include, for example, information about the UPF, base station, and / or UE performing QoS monitoring. The above (6) may include, for example, information identifying the UPF, information identifying the base station, and information identifying the UE. Thus, for example, the UPF, base station, and / or UE can quickly grasp the QoS monitoring status of their own devices.

[0233] As an example of (7) above, the following (7-1) to (7-3) are disclosed.

[0234] (7-1) indicates information about NW fault detection at anchor point NW.

[0235] (7-2) indicates information on NW fault detection for non-anchor point NW.

[0236] (7-3) indicates information about detecting faults in one's own NW.

[0237] 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, information indicating that the anchor AMF (an AMF belonging to the same NW as the anchor SMF) performs the detection, and information indicating that the anchor UPF performs the detection. Non-anchor NWs, such as non-anchor SMFs, can use the information above (7-1) to notify the anchor NW, such as the anchor SMF, of the QoS monitoring report. 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. Thus, for example, rapid NW fault detection in the anchor NW can be achieved.

[0238] 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, information indicating that a non-anchor AMF performs the detection, and information indicating that a non-anchor NW's UPF performs the detection. Anchor NWs, such as anchor SMFs, can use the information above (7-2) to notify non-anchor NWs, such as non-anchor SMFs, of QoS monitoring reports. The QoS monitoring report notified by the anchor NW device may be, for example, a QoS monitoring report received from its own NW's UPF. Thus, for example, rapid NW fault detection in non-anchor NWs can be achieved.

[0239] Through the above (7-3), for example, the complexity in communication systems can be avoided.

[0240] The above (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 (8). Thus, for example, deviations in the QoS monitoring policies between the anchor NW and the non-anchor NW can be prevented, thereby preventing QoS monitoring-related malfunctions.

[0241] The above (9) may include information, for example, indicating whether the QoS monitoring target service is uplink or downlink. Non-anchor NW devices can use this information to perform QoS monitoring of uplink and / or downlink services. Thus, for example, the efficiency related to QoS monitoring can be improved.

[0242] A non-anchor SMF can request QoS monitoring from an intermediate UPF. This request may contain information such as those described in (1) to (10) above. The intermediate UPF may initiate QoS monitoring based on this request.

[0243] A non-anchor SMF can request QoS monitoring from a non-anchor base station (a base station of a non-anchor NW). This request may contain information such as (1) to (10) above. The non-anchor base station can start QoS monitoring triggered by this request.

[0244] Figure 12 This is a sequence diagram illustrating an example of QoS monitoring configuration actions. Figure 12 Shown in Figure 11 The example shown is a sequence of setting actions in a communication system. That is, in Figure 12 In the example shown, base station #1, AMF#1, UPF#1, SMF#1, PCF#1, UDM#1, and anchor point UPF belong to NW1090, while base station #2, AMF#2, UPF#2, SMF#2, PCF#2, and UDM#2 belong to NW1091. The diagrams representing other sequence examples are also set to the same convention. Figure 12 The example shown illustrates the QoS monitoring settings for UPF#1, anchor UPF, and UPF#2. Figure 12 This illustrates the settings for determining QoS monitoring in the anchor point NW. Figure 12 The example shows a scenario where a QoS monitoring request and PDU session establishment occur simultaneously. However, a QoS monitoring request can also occur simultaneously with a PDU session change, and a PDU session change can also be performed for a QoS monitoring request. Figure 12 In the example shown, a PDU session is established in both NW1090 and NW1091.

[0245] exist Figure 12 In process 1100 shown, the connection establishment process with UPF in NW1090 is performed. Process 1100 is described below. Figure 13 It means Figure 12 The sequence diagram of the process 1100 is an example.

[0246] exist Figure 13 In step ST1101 shown, SMF#1 selects UPF. In Figure 13 In the example shown, SMF#1 selects UPF#1 and decides to use UPF#1.

[0247] exist Figure 13 In step ST1102, the process of establishing a session management policy association between SMF#1 and PCF#1 is shown. This process can be, for example, the process disclosed in section 4.16.4 of Non-Patent Document 31 (3GPP TS23.502). In step ST1102, SMF#1 can request a QoS monitoring policy from PCF#1. PCF#1 can notify SMF#1 of the QoS monitoring policy. Step ST1102 can also involve a process of changing the session management policy association. This process can be, for example, the process disclosed in section 4.16.5 of Non-Patent Document 31 (3GPP TS23.502). SMF#1 can use the QoS monitoring policy from PCF#1 to determine the QoS monitoring settings.

[0248] exist Figure 13 In step ST1104, SMF#1 requests N4 session establishment from the anchor UPF. The anchor UPF initiates N4 session establishment, triggered by step ST1104. In step ST1105, the anchor UPF responds to SMF#1 in response to step ST1104.

[0249] exist Figure 13 In step ST1107, SMF#1 requests N4 session establishment from UPF#1. UPF#1 initiates N4 session establishment based on step ST1107. In step ST1108, UPF#1 responds to SMF#1 in response to step ST1107. Requests and responses regarding changes to the N4 session can also be made in steps ST1107 and ST1108.

[0250] return Figure 12 The explanation. In Figure 12 In step ST1110, SMF#1 requests SMF#2 to establish a PDU session. This request can also be a request for PDU session modification. The request can contain information about QoS monitoring policies or QoS monitoring settings. The request can contain the information mentioned in (1) to (10) above, information about the anchor UPF, information about the PDU session (e.g., information about the PDU session of the object to be established), or information about QoS flows (e.g., information about the QoS flows of the object to be established). In step ST1110, the signaling of Nsmf_PDUSession_Establishment_Request (refer to Non-Patent Document 31) or Nsmf_PDUSession_Modification_Request (refer to Non-Patent Document 31) can be used. SMF#2 can start the PDU session establishment action or the PDU session modification action triggered by step ST1110.

[0251] exist Figure 12 In procedure 1111 shown, a PDU session is established in NW1090. A PDU session change in NW1090 can also be performed. Procedure 1111 is described below. Figure 14 It means Figure 12 The sequence diagram of an example of process 1111.

[0252] exist Figure 14In steps ST1113 and ST1114, the information required for establishing a PDU session for the UE is transmitted and received between SMF#1 and AMF#1. Information required for PDU session changes can also be transmitted and received. In step ST1113, an indication for establishing a PDU session from SMF#1 to AMF#1 can be given, or an indication for PDU session changes can be given. This indication can include the aforementioned information. This information can include information about the UE, information about the PDU session, information about QoS flows, information about the UPF, and information about QoS monitoring settings.

[0253] exist Figure 14 In step ST1116, AMF#1 notifies base station #1 of a PDU session establishment request for the UE. A PDU session change request may also be notified. This notification may include QoS monitoring settings. In step ST1117, base station #1 notifies the UE of the PDU session establishment request. A PDU session change request may also be notified. RRC signaling, such as RRC establishment signaling or RRC reconfiguration signaling, may be used in step ST1117. The notification in step ST1117 may include QoS monitoring settings. The UE can use the notification content of step ST1117 to process PDU session establishment or PDU session change.

[0254] exist Figure 14 In step ST1118, the UE responds to base station #1 in response to step ST1117. This response may use RRC signaling, such as RRC establishment completion signaling or RRC reconfiguration completion signaling. In step ST1119, base station #1 responds to AMF #1 in response to step ST1116. This response in step ST1119 may contain N2 session management information.

[0255] exist Figure 14 In step ST1121, AMF#1 notifies SMF#1 of the N2 session management information from base station #1. This notification can be made, for example, using the signaling Nsmf_PDUSession_UpdateSMContext Request (refer to Non-Patent Document 31). In step ST1122, SMF#1 responds to AMF#1 in response to step ST1121. This response can use, for example, the signaling Nsmf_PDUSession_UpdateSMContext Response (refer to Non-Patent Document 31).

[0256] exist Figure 14In step ST1124, SMF#1 requests an N4 session change from the anchor UPF. This request may include, for example, QoS monitoring settings. The anchor UPF can use these settings to begin QoS monitoring. In step ST1125, the anchor UPF responds to SMF#1 in response to step ST1124.

[0257] exist Figure 14 In step ST1128, SMF#1 requests an N4 session change from UPF#1. This request may include, for example, QoS monitoring settings. UPF#1 can use these settings to start QoS monitoring. In step ST1129, UPF#1 responds to SMF#1 in response to step ST1128.

[0258] exist Figure 14 In step ST1131, the UE notifies base station #1 of a positive response to the PDU session establishment request. A positive response to a PDU session change request can also be notified. This notification can be triggered by the completion of PDU session establishment and / or change. In step ST1132, base station #1 notifies AMF #1 of information regarding the positive response. This notification in step ST1132 may include N2 session management information.

[0259] exist Figure 14 In steps ST1133 and ST1134 shown, the same processing as in steps ST1121 and ST1122 is performed.

[0260] exist Figure 14 In steps ST1136 and ST1137, the same processing as in steps ST1124 and ST1125 is performed.

[0261] exist Figure 14 In steps ST1138 and ST1139 shown, the same processing as in steps ST1128 and ST1129 is performed.

[0262] exist Figure 14 The step ST1140 shown is a process for changing the session management policy association between SMF#1 and PCF#1. This process can be, for example, the process disclosed in section 4.16.5 of non-patent document 31 (3GPP TS23.502).

[0263] return Figure 12 The explanation. In Figure 12 In process 1150 shown, the connection establishment process with UPF in NW1091 is performed. Process 1150 is described below. Figure 15 It means Figure 12 The sequence diagram of the process 1150 is an example.

[0264] exist Figure 15 In step ST1151 shown, SMF#2 selects UPF. In Figure 15 In the example shown, SMF#2 selects UPF#2 and decides to use UPF#2. In step ST1152, a process is performed to establish a session management policy association between SMF#2 and PCF#2. This process can be, for example, the process disclosed in section 4.16.4 of Non-Patent Document 31 (3GPP TS23.502). In step ST1152, SMF#2 can notify PCF#2 of the QoS monitoring policy from SMF#1, which received the notification in step ST1110. A process for changing the session management policy association can also be performed in step ST1152. This process can be, for example, the process disclosed in section 4.16.5 of Non-Patent Document 31 (3GPP TS23.502).

[0265] exist Figure 15 In steps ST1154 and ST1155 shown, an AND operation is performed between SMF#2 and UPF#2. Figure 13 The same process applies to steps ST1107 and ST1108 of process 1100 shown.

[0266] return Figure 12 The explanation. In Figure 12 In step ST1158 shown, SMF#2 notifies SMF#1 of information about the intermediate UPF. Figure 12 In the example shown, SMF#2 can notify SMF#1 of information about UPF#2.

[0267] exist Figure 12 In steps ST1159 and ST1160 shown, the following steps are performed: Figure 14 The same processing is applied to steps ST1124 and ST1125 of process 1111 shown. In step ST1159, a connection request to UPF#2 can be sent. The anchor UPF can initiate a connection with UPF#2 triggered by step ST1159.

[0268] exist Figure 12 In procedure 1161 shown, a PDU session is established in NW1091. A PDU session change in NW1091 can also be performed. Procedure 1161 is described below. Figure 16 It means Figure 12 The sequence diagram of an example of process 1161.

[0269] exist Figure 16 In steps ST1163 to ST1174 shown, data is exchanged between SMF#2, AMF#2, base station #2, and UE. Figure 14The same process is applied to steps ST1113 to ST1122 of process 1111 shown.

[0270] exist Figure 16 In steps ST1178 and ST1179 shown, an AND operation is performed between SMF#2 and UPF#2. Figure 14 The same process applies to steps ST1128 and ST1129 of process 1111 shown.

[0271] exist Figure 16 In steps ST1181 to ST1184 shown, interactions are performed between the UE, base station #2, AMF #2, and SMF #2. Figure 14 The same process applies to steps ST1131 to ST1134 of process 1111 shown.

[0272] exist Figure 16 In steps ST1188 to ST1190 shown, the following steps are performed in UPF#2, SMF#2, and PCF#2: Figure 14 The same process is applied to steps ST1138 to ST1140 of process 1111 shown.

[0273] return Figure 12 The explanation. In Figure 12 In step ST1191, SMF#2 responds to SMF#1's request to establish a PDU session. It can also respond to a request to change a PDU session. Step ST1191 can be performed as a response to step ST1110.

[0274] Figure 12 The steps shown in ST1191 can be performed at the following steps. Figure 16 The process shown in step 1161 is performed after step ST1184. Step ST1191 can be performed after step ST1184. Figure 16 The procedure shown in step 1161 is performed before step ST1188. Thus, for example, SMF#2 can quickly execute a response to the establishment / change of a PDU session.

[0275] exist Figure 12 In steps ST1192 to ST1195, data transmission and reception between the UE and DN via NW1090 are performed. Step ST1192 represents data transmission and reception between the UE and base station #1, step ST1193 represents data transmission and reception between base station #1 and UPF #1, step ST1194 represents data transmission and reception between UPF #1 and anchor UPF, and step ST1195 represents data transmission and reception between anchor UPF and DN.

[0276] exist Figure 12In steps ST1196 to ST1199, data transmission and reception between the UE and DN via NW1091 are performed. Step ST1196 represents data transmission and reception between the UE and base station #2, step ST1197 represents data transmission and reception between base station #2 and UPF #2, step ST1198 represents data transmission and reception between UPF #2 and anchor point UPF, and step ST1199 represents data transmission and reception between anchor point UPF and DN.

[0277] A non-anchor NW UPF, such as an intermediate UPF, can send a QoS monitoring report to a non-anchor SMF. The UPF can send the QoS monitoring report, for example, by satisfying the conditions described in (1) above. The report can use, for example, signaling from N4 SessionReport (see Non-Patent Document 31).

[0278] The base station can send QoS monitoring reports to the non-anchor SMF. The base station can send QoS monitoring reports, for example, by triggering the conditions described in (1) above. The reports can be sent, for example, via the non-anchor AMF.

[0279] As an example of the information included in this report from intermediate UPF and / or base stations, the following (A) to (I) are disclosed.

[0280] (A) Information about the entity that conducts QoS monitoring reports.

[0281] (B) Information about QoS types.

[0282] (C) Information about the UE.

[0283] (D) Information about PDU sessions.

[0284] (E) Information about QoS flows.

[0285] (F) Information about time.

[0286] (G) Information about up / down directions.

[0287] (H) Information regarding QoS monitoring measurements.

[0288] (I) The combination of (A) to (H) above.

[0289] The information in (A) above can be, for example, information about its own UPF or information about its own base station. Thus, for example, a non-anchor SMF can quickly determine the location of an NW fault.

[0290] The information in (B) to (E) above can be, for example, the same information as (2) to (5) above.

[0291] The above (F) may include, for example, information about the QoS type that satisfies the conditions in (1) above, and may also include information about the time. Thus, for example, the non-anchor SMF can know the time when the NW fault occurs.

[0292] The above (G) may include information such as whether the service being reported as a QoS monitoring object is uplink or downlink. Thus, for example, the anchor NW device can quickly determine whether the service being reported as a QoS monitoring result is uplink or downlink.

[0293] The above (H) may include, for example, measurement results of QoS monitoring. Thus, for example, the recipient of the QoS monitoring report can obtain detailed measurement results of QoS monitoring.

[0294] Non-anchor SMFs can send QoS monitoring reports to anchor SMFs. This report from a non-anchor SMF to an anchor SMF can be triggered by a QoS monitoring report from a UPF and / or base station to a non-anchor SMF. This report from a non-anchor SMF to an anchor SMF can contain the information described in (A) to (I) above, and can also contain information about the non-anchor NW, such as information about the non-anchor SMF. By including information about the non-anchor NW in the report, it is possible to determine whether the report originated from an anchor NW or a non-anchor NW, and the location of the NW fault can be determined as a result.

[0295] Anchor UPFs can perform QoS monitoring. QoS monitoring of an anchor UPF can be triggered by a QoS monitoring request from an anchor SMF. In QoS monitoring between the anchor UPF and the UE, QoS can be monitored separately for routes not traversed by non-anchor NWs (i.e., via anchor NWs) and routes via non-anchor NWs. QoS monitoring requests from the anchor SMF to the anchor UPF can include information about the traversed NWs. QoS monitoring reports from the anchor UPF to the anchor SMF can also include information about the traversed NWs. Thus, for example, a device (or NF) performing NW fault detection can quickly determine the location of the fault.

[0296] Anchor SMFs can use this information, contained in the report from non-anchor SMFs, to detect NW faults.

[0297] For example, the anchor point SMF can detect the failure of the intermediate UPF of one NW when the QoS between the UE and the intermediate UPF of one NW is abnormal, while the QoS between the UE and the anchor point UPF via the other NW is normal.

[0298] As another example, a fault in the intermediate UPF of one NW can be detected by triggering a QoS anomaly between the UE and the intermediate UPF of one NW, while the QoS between the UE and the intermediate UPF of the other NW is normal.

[0299] As another example, the failure of the anchor UPF can be detected by triggering a situation where the uplink QoS between the UE and the intermediate UPF is normal, but the QoS between the UE and the anchor UPF is abnormal.

[0300] As another example, a fault between the anchor UPF and the DN can be detected when the uplink QoS between the UE and the intermediate UPF and the uplink QoS between the UE and the anchor UPF are normal, but the downlink QoS between the UE and the intermediate UPF and the downlink QoS between the UE and the anchor UPF are abnormal.

[0301] The aforementioned intermediate UPF can be the intermediate UPF of anchor point NW (e.g., Figure 11 The UPF#1 shown can also be an intermediate UPF that is not an anchor point NW (e.g., Figure 11 (See UPF#2). The aforementioned QoS anomaly could be, for example, the QoS being above or exceeding a specified threshold, or the QoS being below or insufficient than a specified threshold. The aforementioned normal QoS could be, for example, the absence of any QoS anomaly. Thus, for example, the anchor point SMF can determine the location of the fault in an NW fault.

[0302] Figure 17 This is a sequence diagram illustrating an example of detection actions for NW faults. Figure 17 This shows an example of a failure that occurs in UPF#2. Figure 17 An example of fault detection at anchor point NW is shown. Figure 17 In the middle, to and Figure 12 The same process is labeled with the same step number, and common descriptions are omitted.

[0303] Figure 17 Steps ST1196 to ST1199 and Figure 12 same.

[0304] exist Figure 17 In step ST1204, the anchor UPF detects QoS degradation. The anchor UPF can, for example, detect QoS degradation in data from NW1091. In step ST1205, the anchor UPF sends a QoS monitoring report to SMF#1. This report can use, for example, signaling such as an N4 session report (refer to Non-Patent Document 31). In step ST1206, SMF#1 responds positively to the anchor UPF with this report. This response can use, for example, signaling such as an N4 session report positive response (refer to Non-Patent Document 31).

[0305] exist Figure 17 In step ST1209, UPF#2 detects QoS degradation. UPF#2 can, for example, detect QoS degradation in data passing through its own UPF. In step ST1210, UPF#2 sends a QoS monitoring report to SMF#2. This report can use, for example, the same signaling as in step ST1205. In step ST1211, SMF#2 responds positively to the report from UPF#2. This response can use, for example, the same signaling as in step ST1206.

[0306] exist Figure 17 In step ST1215, SMF#2 sends a QoS monitoring report to SMF#1. SMF#2 may trigger this report by receiving the information described in (7-2) above from UPF#2. This report may include the information from step ST1210, or it may include 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 responds to the report from SMF#2. Figure 17 In the example shown, the response could be positive.

[0307] exist Figure 17 In step ST1220 shown, SMF#1 detects an NW fault. In Figure 17 In the example shown, SMF#1 detects a fault in UPF#2. SMF#1 can detect a fault in UPF#2 using QoS monitoring reports from the anchor UPF and from UPF#2.

[0308] Figure 17 The example shown is a fault occurring in UPF#2, but it could also be a fault between UPF#2 and the anchor UPF, or a fault between UPF#2 and the base station #2.

[0309] Figure 17 The example shown is a positive response for step ST1216, but the response can also be negative. SMF#2 can trigger a retransmission of the QoS monitoring report with a negative response. Thus, for example, SMF#1 can correct errors in the report content, and as a result, NW faults can be appropriately detected.

[0310] Other solutions are disclosed. Detect NW faults within the NW where an NW fault occurs. This NW can be an anchored NW or a non-anchored NW. For example, this detection can be performed in both anchored and non-anchored SMFs.

[0311] Each NW can determine QoS monitoring-related information, such as QoS monitoring policies. For example, the PCF (Process Control Function) of each NW can determine this information. As another example, an Application Function (AF) can determine QoS monitoring-related information. The AF can notify the PCF of each NW of this information. The SMF (Service Control Function) of each NW can obtain the QoS monitoring policy from the PCF of the NW as this information. The aforementioned NWs may include non-anchor NWs. The SMF of each NW can use the obtained QoS monitoring policy to determine the QoS monitoring settings.

[0312] As another example, an anchor NW can determine QoS monitoring-related information in a non-anchor NW. For example, an anchor PCF can determine this information. As another example, an AF can determine QoS monitoring-related information. The AF can notify the anchor PCF of this information. The anchor SMF can obtain this information from the anchor PCF. The anchor SMF can notify the non-anchor NW device, such as a non-anchor SMF, of this information.

[0313] Each NW's SMF can send a QoS monitoring request to its own NW's UPF. For example, each NW's SMF can send this request to its own NW's UPF. The request may include QoS monitoring settings. The request may include the information related to (1) to (10) above.

[0314] Each NW's SMF can send a QoS monitoring request to each NW's base station. This request can be made, for example, via each NW's AMF. The request can include QoS monitoring settings. The request can include the information related to (1) to (10) above.

[0315] Figure 18 This is a sequence diagram illustrating other examples of QoS monitoring configuration actions. Figure 18 The example shown illustrates the QoS monitoring settings for UPF#1, anchor UPF, and UPF#2. Figure 18 This illustrates the scenario where QoS monitoring settings are determined within a non-anchor NW. Figure 18 The example shows a scenario where a QoS monitoring request and PDU session establishment occur simultaneously. However, a QoS monitoring request can also occur simultaneously with a PDU session change, and a PDU session change can also be performed for a QoS monitoring request. Figure 18 In the example shown, a PDU session is established in both NW1090 and NW1091. Figure 18 In the middle, to and Figure 12 The same processing is labeled with the same number, and common explanations are omitted.

[0316] Figure 18 The process 1100 and Figure 12and Figure 13 same.

[0317] exist Figure 18 In step ST1310, SMF#1 requests SMF#2 to establish a PDU session. Step ST1310 can be, for example, a request for PDU session change. This request may or may not include information indicating a QoS monitoring policy and / or QoS monitoring settings determined in NW1091. The request may include information about the UE, information about the anchor UPF, information about the PDU session, and information about QoS flows. Step ST1310 can use... Figure 12 The same signaling as step ST1110. SMF#2, triggered by step ST1310, can initiate the PDU session establishment action or the PDU session change action. SMF#2 can also be triggered by step ST1310 to initiate the QoS monitoring setting decision action in NW1091.

[0318] Figure 18 The process 1111 and Figure 12 and Figure 14 same.

[0319] Figure 18 Step ST1151 and Figure 12 and Figure 15 same.

[0320] exist Figure 18 In step ST1352, the process of establishing a session management policy association between SMF#2 and PCF#2 is shown. This process can be, for example, the process disclosed in section 4.16.4 of Non-Patent Document 31 (3GPP TS23.502). In step ST1352, SMF#2 can request a QoS monitoring policy from PCF#2. This request can be triggered by step ST1310. The request for the QoS monitoring policy can be triggered, for example, by the request in step ST1310 containing information indicating that a QoS monitoring policy and / or QoS monitoring settings are determined in NW1091, or it can be triggered by the request in step ST1310 not containing a QoS monitoring policy and / or QoS monitoring settings. PCF#2 can notify SMF#2 of the QoS monitoring policy. SMF#2 can use the QoS monitoring policy to determine the QoS monitoring settings. In step ST1352, the process of changing the session management policy association can also be performed. The process of changing the associated session management policy can be, for example, the process disclosed in section 4.16.5 of non-patent document 31 (3GPP TS23.502).

[0321] Figure 18Steps ST1154, ST1155 and Figure 12 and Figure 15 same.

[0322] Figure 18 Steps S1158 to S1160 and Figure 12 same.

[0323] Figure 18 The process shown in 1161 and Figure 12 and Figure 16 same.

[0324] exist Figure 18 In step ST1386, SMF#2 responds to SMF#1's request to establish a PDU session. It can also respond to a request to change a PDU session. Step ST1386 ​​can be performed as a response to step ST1310. This response in step ST1386 ​​may include a QoS monitoring policy and / or QoS monitoring settings. These QoS monitoring policies and / or settings can be, for example, the QoS monitoring policy determined by PCF#2 in step ST1352, or the QoS monitoring settings determined by SMF#2.

[0325] Figure 18 Steps ST1192 to ST1199 and Figure 12 same.

[0326] Each NW's UPF can send a QoS monitoring report to each NW's SMF. The UPF can send the QoS monitoring report, for example, by satisfying the conditions described in (1) above. The report can use, for example, the signaling of an N4 Session Report (see Non-Patent Document 31).

[0327] Each NW's base station can send a QoS monitoring report to its respective NW's SMF. The base station can send the QoS monitoring report, for example, by meeting the conditions described in (1) above. The report can be sent, for example, via each NW's AMF.

[0328] The report from each NW's UPF and / or base station to the SMF may contain the same information as described in (A) to (I) above.

[0329] The non-anchor SMF can use the information included in the report to detect NW faults. For example, the non-anchor SMF can detect an intermediate UPF fault triggered by a QoS anomaly between the UE and the intermediate UPF, or it can detect an anchor UPF fault triggered by a normal QoS between the UE and the intermediate UPF, but a QoS anomaly between the UE and the anchor UPF. The intermediate UPF mentioned above can be, for example, the intermediate UPF of a non-anchor NW. The QoS anomaly mentioned above can be, for example, the QoS being above or exceeding a specified threshold, or the QoS being below or insufficient. The normal QoS mentioned above can be, for example, the QoS having no anomalies. Thus, for example, the non-anchor SMF can determine the location of the fault in the NW fault.

[0330] Anchor SMFs can send QoS monitoring reports to non-anchor SMFs. For example, an anchor SMF can send this report to a non-anchor SMF triggered by the presence of a QoS monitoring report from its own NW's anchor UPF, or triggered by the absence of QoS monitoring from an intermediate UPF, or both. Non-anchor SMFs can use the information contained in this report to detect NW faults. Thus, for example, in a non-anchor SMF, faults can be detected only in the intermediate UPFs of the non-anchor NW.

[0331] Figure 19 This is a sequence diagram representing other examples of detection actions for NW faults. Figure 19 This shows an example of a failure that occurs in UPF#2. Figure 19 An example of fault detection using a non-anchor point NW is shown. Figure 19 In the middle, to and Figure 12 and Figure 17 The same process is labeled with the same step number, and common descriptions are omitted.

[0332] Figure 19 Steps ST1196 to ST1199 and Figure 12 same.

[0333] Figure 19 Steps ST1204 to ST1211 and Figure 17 same.

[0334] exist Figure 19In step ST1415, SMF#1 sends a QoS monitoring report to SMF#2. SMF#1 may trigger this report by sending the information described in (7-2) above to SMF#2. This report may include the information reported in step ST1205, information about the UPF, or information about the NW via which the report is sent from the anchor UPF's QoS monitoring report. The information about the UPF may be, for example, information about the UPF that sent the QoS monitoring report. In step ST1416, SMF#2 responds to the report from SMF#1. Figure 19 In the example shown, the response could be positive.

[0335] exist Figure 19 In step ST1420 shown, SMF#2 detects an NW fault. In Figure 19 In the example shown, SMF#2 detects a fault in UPF#2. SMF#2 can detect a fault in UPF#2 using QoS monitoring reports from the anchor UPF and from UPF#2.

[0336] exist Figure 19 In step ST1425, as shown, SMF#2 can notify SMF#1 of information regarding an NW fault. This notification may include information about the fault location, information about the PDU session, and information about QoS flows. Figure 19 In the example shown, the information about the fault location could be information about UPF#2. SMF#1 can be triggered by step ST1425 to detect the NW fault.

[0337] Figure 19 The example shown is a fault occurring in UPF#2, but it could also be a fault between UPF#2 and the anchor UPF, or a fault between UPF#2 and the base station #2.

[0338] Figure 19 The example shown is a positive response for step ST1416, but the response can also be negative. SMF#1 can trigger a retransmission of the QoS monitoring report with a negative response. Thus, for example, SMF#2 can correct errors in the report content, and as a result, NW faults can be appropriately detected.

[0339] Requests for PDU session changes to the UE can be made from the anchor NW. For example, the anchor NW can notify the UE of information about PDU sessions that are not handled by the anchor NW.

[0340] Non-anchor NWs, such as non-anchor SMFs, can notify anchor NWs, such as anchor SMFs, of information regarding PDU session changes for the UE. This notification can use signaling such as Nsmf_PDUSession_Modification_Response (see Non-Patent Document 31). The notification may contain information, for example, regarding NAS signaling (hereinafter sometimes referred to as NAS signaling information). This NAS signaling can be, for example, NAS signaling related to PDU session changes. This NAS signaling can be, for example, NAS signaling from a non-anchor AMF to the UE.

[0341] A non-anchor SMF can request NAS signaling information from a non-anchor AMF. This NAS signaling can be, for example, NAS signaling related to PDU session changes. A non-anchor AMF can also notify a non-anchor SMF of the NAS signaling information. This notification from a non-anchor AMF to a non-anchor SMF can be triggered by this request from the non-anchor SMF to the non-anchor AMF.

[0342] The NAS signaling may contain information about RRC signaling (hereinafter sometimes referred to as RRC signaling information). This RRC signaling may be, for example, RRC signaling related to PDU session changes. This RRC signaling may be RRC signaling from a non-anchor base station to the UE. A non-anchor AMF may request RRC signaling information from a non-anchor base station. A non-anchor base station may notify a non-anchor AMF of the RRC signaling information. This notification from a non-anchor base station to a non-anchor AMF may be triggered by a request from a non-anchor AMF to a non-anchor base station.

[0343] QoS monitoring requests from an anchor NW (e.g., an anchor SMF) to a non-anchor NW (e.g., a non-anchor NW) may include information indicating that a PDU session change request for the UE is being sent from the anchor NW. The non-anchor NW (e.g., a non-anchor SMF) may, upon receiving this information, notify the anchor NW (e.g., the anchor SMF) of the PDU session change for the UE.

[0344] The anchor SMF can notify the anchor AMF of PDU session changes. The anchor AMF can then notify the UE of the PDU session changes. This notification can be sent via the base station of the anchor NW (hereinafter sometimes referred to as the anchor base station). The UE can use this notification as a trigger to change its own PDU session settings.

[0345] This notification from the anchor SMF to the anchor AMF can be triggered by a notification from a non-anchor SMF to the anchor SMF regarding a PDU session request. This notification from the anchor SMF to the anchor AMF may include information about NAS signaling. This NAS signaling may include NAS signaling from the anchor NW or from a non-anchor NW. Thus, for example, the UE can change the PDU session settings regarding the anchor NW and non-anchor NW, resulting in improved communication efficiency in the communication system.

[0346] Figure 20 , Figure 21 and Figure 22 This is a sequence diagram representing other examples of QoS monitoring configuration actions. Figure 20 Indicates the beginning of the sequence. Figure 21 Indicates the middle part of the sequence. Figure 22 Indicates the end of the sequence. Figure 20 , Figure 21 and Figure 22 This represents a series of actions (QoS monitoring configuration actions). In Figure 20 , Figure 21 and Figure 22 The example shown illustrates the QoS monitoring settings for UPF#1, anchor UPF, and UPF#2. Figure 20 , Figure 21 and Figure 22 This illustrates the scenario where QoS monitoring settings are determined at the anchor point NW. Figure 20 , Figure 21 and Figure 22 The example shows a scenario where a QoS monitoring request and PDU session establishment occur simultaneously. However, a QoS monitoring request can also occur simultaneously with a PDU session change, and a PDU session change can also be performed for a QoS monitoring request. Figure 20 , Figure 21 and Figure 22 In the example shown, a PDU session is established in both NW1090 and NW1091. Figure 20 , Figure 21 and Figure 22 In the example shown, a notification of a PDU session establishment / change request from NW1091 to the UE is sent from NW1190. Figure 20 , Figure 21 and Figure 22 In the middle, to and Figure 12 The same processing is labeled with the same number, and common explanations are omitted.

[0347] Figure 20 The process shown is 1100 and Figure 12 and Figure 13 same.

[0348] exist Figure 20 In step ST1510 shown, SMF#1 requests SMF#2 to establish a PDU session. This request may include information indicating that a PDU session establishment / change request is being sent to the UE from the anchor point NW, or it may include information related to... Figure 12 The information included in the request sent in step ST1110 is the same as the information described above. Step ST1510 can use the same... Figure 12 The same signaling is used in step ST1110 shown.

[0349] Figure 20 The steps ST1151 to ST1160 shown are... Figure 12 and Figure 15 same.

[0350] exist Figure 20 In step ST1563, SMF#2 requests NAS signaling information from AMF#2. This 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. This 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 by base station #2 in step ST1567.

[0351] exist Figure 20 In step ST1570, SMF#2 notifies SMF#1 of information regarding the PDU session change. This notification can be made as a NAS signaling transmission request, or it can be included in the notification. The notification and / or the request can contain information about the NAS signaling. This information about the NAS signaling can include the information notified in step ST1568.

[0352] exist Figure 21 In steps ST1513 and ST1114 shown, the following steps are performed: Figure 12 and Figure 14 The same processing is applied to steps ST1113 and ST1114 shown. The signaling in step ST1513 may include NAS signaling information contained in the request received in step ST1570, or it may include RRC signaling information.

[0353] exist Figure 21 In steps ST1516 and ST1517 shown, the following steps are performed: Figure 12 and Figure 14The same processing is applied to steps ST1116 and ST1117. Steps ST1516 and ST1517 may include NAS signaling information contained in the request received in step ST1570, or they may include RRC signaling information.

[0354] exist Figure 21 In steps ST1518 to ST1521 shown, the following steps are performed: Figure 12 and Figure 14 The same processing is applied to steps ST1118 to ST1121. The UE may include RRC signaling to base station #2 or NAS signaling to AMF #2 in step ST1518. Steps ST1519 and ST1521 may include RRC signaling to base station #2 or NAS signaling to AMF #2.

[0355] Figure 21 The steps ST1122 shown are... Figure 12 and Figure 14 same.

[0356] exist Figure 21 In step ST1571, SMF#1 responds to SMF#2's request to send NAS signaling. This response can be performed as a response to step ST1570. Step ST1571 may contain RRC signaling directed to base station #2, or it may contain NAS signaling directed to AMF#2.

[0357] exist Figure 21 In step ST1572, SMF#2 forwards NAS signaling to AMF#2. This NAS signaling may include the RRC signaling for base station #2 included in the response of step ST1571, or it may include the NAS signaling for AMF#2. AMF#2 obtains the NAS signaling from the UE through step ST1572.

[0358] exist Figure 21 In step ST1573, AMF#2 forwards RRC signaling to base station #2. This RRC signaling may be, for example, the RRC signaling directed to base station #2 included in step ST1571. Base station #2 obtains the RRC signaling from the UE through step ST1573.

[0359] exist Figure 21 In step ST1574, base station #2 responds to AMF#2 in step ST1573. In step ST1575, AMF#2 responds to SMF#2 in step ST1572.

[0360] Figure 21 The steps ST1178, ST1179 and shown are Figure 12 and Figure 16 same.

[0361] Figure 21 The steps ST1124 to ST1129 shown are... Figure 12 and Figure 14 same.

[0362] exist Figure 21 In steps ST1531 to ST1533 shown, the following steps are performed: Figure 12 and Figure 14 The same processing is applied to steps ST1131 to ST1133. The UE may include RRC signaling to base station #2 or NAS signaling to AMF #2 in step ST1531. Steps ST1532 and ST1533 may include either RRC signaling to base station #2 or NAS signaling to AMF #2.

[0363] Figure 21 The steps ST1134 shown are... Figure 12 and Figure 14 same.

[0364] exist Figure 22 In steps ST1585 to ST1589 shown, the following steps are performed: Figure 21 The same process applies to steps ST1571 to ST1575.

[0365] Figure 22 The steps ST1136 to ST1140 shown are... Figure 12 and Figure 14 same.

[0366] Figure 22 The steps ST1188 to ST1199 shown are... Figure 12 and Figure 16 same.

[0367] The NW that determines the QoS monitoring strategy can be the same as the NW that determines the QoS monitoring settings. This, for example, avoids complexity in the communication system.

[0368] As another example, the NW that determines the QoS monitoring policy can be different from the NW that determines the QoS monitoring settings. For example, the QoS monitoring policy can be determined by the anchor NW (e.g., the anchor PCF), and the QoS monitoring settings can be determined by the non-anchor NW (e.g., the non-anchor SMF). Alternatively, the QoS monitoring policy can be determined by the anchor NW (e.g., the anchor PCF), and the QoS monitoring settings can be determined by the non-anchor NW (e.g., the non-anchor SMF). The anchor SMF can notify the non-anchor SMF of the QoS monitoring policy. This notification can be included in, for example... Figure 12In step ST1110, the non-anchor SMF can use this QoS monitoring policy to determine the QoS monitoring settings. The non-anchor SMF can notify the intermediate UPF and / or base station within its own NW of the QoS monitoring settings. Thus, for example, mismatches in QoS monitoring policies between NWs can be avoided, and the QoS monitoring settings can be determined in each NW, resulting in improved flexibility in QoS monitoring.

[0369] QoS monitoring reports can be sent to the NWDAF. This NWDAF can be, for example, the NWDAF of the anchor NW. This report to the NWDAF can be made by the SMF, AMF, UPF, or the base station. The NWDAF can use this report to detect NW faults and their locations. The NWDAF can also use this report to modify the NW structure. Thus, for example, the NW structure can be modified based on the NW fault status, resulting in improved robustness of the communication system.

[0370] QoS monitoring settings for base stations can be configured directly from the SMF, and QoS monitoring reports from the base station can also be used directly on the SMF. The interface between the base station and the SMF can be configured. This, for example, can reduce the processing load on the AMF.

[0371] The NW used for NW fault detection can be the same as the NW used to determine QoS monitoring policies. This, for example, avoids complexity in the communication system.

[0372] As another example, the NW performing NW fault detection can be different from the NW determining the QoS monitoring policy, and the NW performing NW fault detection can also be different from the NW determining the QoS monitoring settings. This, for example, can improve the flexibility of the communication system.

[0373] The NW used for detecting NW faults can vary depending on the configuration of the PDU session. For example, if the PDU session is configured to branch into multiple NWs, NW faults can be detected by an anchor NW device (e.g., an anchor SMF). As another example, if the PDU session is configured to switch between NWs, NW faults can be detected in each NW. This, for example, avoids the complexity of the communication system.

[0374] According to this embodiment 1, the location of the NW fault in the communication system can be determined, and as a result, recovery from the NW fault can be performed.

[0375] Variation 1 of Implementation Method 1.

[0376] It can perform Uu interface fault detection. For example, it can perform Uu interface fault detection when the UE is connected to multiple NWs.

[0377] The UE can detect faults in the Uu interface. This detection can use methods similar to those used for Radio Link Failure (RLF) detection.

[0378] The UE can notify the base station of a Uu interface failure. This notification from the UE can be sent to a base station of an NW that is not experiencing a failure. This base station can be an anchor base station or a non-anchor base station. The notification from the UE to the base station can use RRC signaling, MAC signaling, or L1 / L2 signaling. The notification can contain information about the UE, the NW experiencing the failure, the PDU session, and QoS flows.

[0379] The base station can notify the AMF of this information from the UE. As another example, the base station can notify the SMF of this information from the UE. This notification from the base station to the SMF can be done via the AMF or directly.

[0380] As another example, the UE can notify the AMF of a Uu interface failure. This notification from the UE to the AMF can use, for example, NAS signaling. The notification from the UE can also be made to the AMF of a non-faulty NW. This AMF can be an anchor AMF or a non-anchor AMF. The notification can contain information about the UE, information about the base station, information about the faulty NW, information about the PDU session, and information about QoS flows. The notification can be made via the base station.

[0381] The AMF can notify the SMF of information regarding a Uu interface failure of the UE. This notification may contain information similar to, for example, information included in a Uu interface failure notification from the UE. The target SMF may, for example, be an SMF with the same NW as the AMF. This notification may, for example, be a forwarding of the aforementioned information from the UE to the AMF. The SMF can be alerted to the Uu interface failure upon receiving this notification.

[0382] The SMF can notify other NWs' SMFs of information regarding a Uu interface failure of the UE. This notification may contain information similar to that included in a Uu interface failure notification from the UE. The other NW's SMF could be, for example, the SMF of the NW experiencing the Uu interface failure, an SMF performing NW failure detection, or an anchor SMF. This notification can be, for example, a forwarding of the aforementioned information from the AMF to the SMF. The other NW's SMF can be triggered by this notification to acquire knowledge of the Uu interface failure. The other NW's SMF can be triggered by this notification to perform NW recovery processing. This processing can be, for example, the method disclosed in Embodiment 2 or later.

[0383] The SMF of another NW can notify its own AMF of information regarding a Uu interface failure of the UE. This notification may contain information identical to, for example, information contained in a Uu interface failure notification from the UE. This notification may be, for example, a forwarding of the aforementioned information from the SMF of the other NW. The AMF can be triggered by this information to recognize the Uu interface failure. The AMF can be triggered by this information to perform processing for connection restoration with the UE. For example, the AMF can initiate a service request process. This processing may be as disclosed in section 4.2.3.3 of Non-Patent Document 31 (3GPP TS23.502).

[0384] According to this variation 1, a Uu interface fault can be detected in the communication NW, and the result can be quickly executed for recovery from the Uu interface fault of the UE.

[0385] Implementation method 2.

[0386] In Implementation 2, a method for recovering from an NW fault is disclosed.

[0387] Switching of intermediate UPFs is possible. This intermediate UPF can be, for example, a non-anchor NW intermediate UPF. The switching can be triggered, for example, by detecting a fault in the non-anchor NW intermediate UPF.

[0388] The handover process can be performed by the NW device or NF that detects the NW fault. For example, it can be performed by the SMF that detects the NW fault. As another example, the NW device or NF that detects the NW fault can request the handover process from the SMF.

[0389] An anchor point NW can initiate the handover process. For example, an anchor point SMF can initiate the handover process. The anchor point SMF can request a UPF handover from a non-anchor point SMF. This request can be made, for example, as a PDU session change request. This request can use, for example, signaling such as Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31).

[0390] The request can include information about the failure of the intermediate UPF. This information can be included in the request as information about the reason. Thus, for example, a non-anchor SMF can quickly detect the occurrence of an intermediate UPF failure.

[0391] Non-anchor SMFs can select a new intermediate UPF (hereinafter sometimes referred to as the post-switching intermediate UPF). Non-anchor SMFs can establish a connection with the post-switching intermediate UPF.

[0392] The non-anchor SMF can request connection establishment from the intermediate UPF after handover. This request can use, for example, N4 Session Establishment Request signaling (see Non-Patent Document 31). This request can include information about the UE, information about the PDU session, information about QoS flows, information about QoS monitoring disclosed in Implementation 1, and information about the anchor UPF. For example, by including information about the anchor UPF, the connection between the intermediate UPF and the anchor UPF after handover can be quickly established.

[0393] After the handover, the intermediate UPF can respond to the connection establishment request from the non-anchor SMF. This response can use signaling such as the N4 Session Establishment Response (see Non-Patent Document 31). The non-anchor SMF can use this response as a trigger to know that the connection of the intermediate UPF has been completed after the handover.

[0394] A non-anchor SMF can request the release of a connection from an intermediate UPF (hereinafter sometimes referred to as a faulty intermediate UPF) that has detected a fault. This request can use signaling such as an N4 Session Release Request (see Non-Patent Document 31). The request may include information about the UE, information about the PDU session to be released, and information about the QoS flow to be released. The faulty intermediate UPF can use this information to release resources associated with the PDU session and / or QoS flow.

[0395] The intermediate UPF can respond to the connection release request from the non-anchor SMF. This response can use signaling such as the N4 Session Release Response (see Non-Patent Document 31). The non-anchor SMF can use this response as a trigger to know that the release of the intermediate UPF has been completed.

[0396] A change in the PDU session can be notified to the UE from the communication NW. This notification can, for example, be made from an NW that has undergone an intermediate UPF handover. Alternatively, a notification of the PDU session change can be made to the UE from a non-anchor NW. This notification can also be made to the UE from a non-anchor AMF. The non-anchor SMF can request this notification from the non-anchor AMF. The notification can be triggered by this request.

[0397] The non-anchor SMF can respond to the UPF handover request from the anchor SMF. This response can use signaling such as Nsmf_PDUSession_Modification_Response (see Non-Patent Document 31). The response can contain information about the intermediate UPF after the handover. Thus, for example, the anchor SMF can quickly obtain information about the intermediate UPF after the handover.

[0398] The anchor SMF can notify the anchor UPF that the intermediate UPF has been switched, or it can request to switch the connection with the intermediate UPF. This request may include information about the switched intermediate UPF, information about the UE, information about the PDU session, information about QoS flows, and information about QoS monitoring settings disclosed in Implementation 1. This request can use, for example, signaling such as an N4 Session Modification Request (see Non-Patent Document 31). The anchor UPF can switch the connection with the intermediate UPF triggered by this request. For example, triggered by this request, the anchor UPF can release the N9 interface with the faulty intermediate UPF (see Non-Patent Document 10) or establish the N9 interface with the switched intermediate UPF.

[0399] The anchor UPF can notify the anchor SMF that the connection switchover with the intermediate UPF is complete. This notification can use signaling such as an N4 Session Modification Response (see Non-Patent Document 31). The anchor SMF can use this notification as a trigger to know that the connection switchover with the intermediate UPF is complete.

[0400] Figure 23 This is a sequence diagram representing an example of an intermediate UPF switching action in a non-anchor point NW. Figure 23This illustrates an example where the anchor point NW detects an NW fault and determines the UPF switching. Figure 23 In the example shown, the intermediate UPF of NW1091 is switched from UPF#2-1 to UPF#2-2. Figure 23 In the example shown, for and Figure 12 , Figure 17 The same processing is labeled with the same number, and common explanations are omitted.

[0401] Figure 23 The steps ST1196 to ST1199 shown are... Figure 12 same.

[0402] Figure 23 The steps ST1220 shown are... Figure 17 same.

[0403] exist Figure 23 In step ST1621 shown, SMF#1 determines the switching of UPF.

[0404] exist Figure 23 In step ST1623 shown, SMF#1 requests a UPF handover from SMF#2. This request may include information about an intermediate UPF failure, information about the UPF handover request, information about the UE, information about the PDU session, and information about QoS flows.

[0405] exist Figure 23 In process 1625 shown, processing related to the intermediate UPF after switching is performed. Process 1625 is described below. Figure 24 It means Figure 23 The sequence diagram of the example process 1625.

[0406] Figure 24 The steps ST1151, ST1152 and shown are Figure 12 and Figure 15 The steps ST1151 and ST1152 of process 1150 shown are the same. Figure 24 In step ST1151 shown, SMF#2 is selected as UPF#2-2.

[0407] exist Figure 24 In step ST1654, SMF#2 requests N4 session establishment from UPF#2-2. UPF#2-2 initiates N4 session establishment, triggered by step ST1654. In step ST1655, UPF#2-2 responds to SMF#2's response to step ST1654.

[0408] exist Figure 24In step ST1656, SMF#2 requests N4 session release from UPF#2-1. UPF#2-1 performs N4 session release triggered by step ST1656. In step ST1657, UPF#2-1 responds to SMF#2's response to step ST1656.

[0409] return Figure 23 The explanation, Figure 23 The steps ST1158 to ST1160 shown are... Figure 12 Same. Figure 23 In step ST1158 shown, information about UPF#2-2 is provided.

[0410] Figure 23 The process shown in 1161 and Figure 12 and Figure 16 Same. Figure 23 In the process 1161 shown, UPF#2 can be replaced with UPF#2-2.

[0411] Figure 23 The steps shown in ST1191 and Figure 12 same.

[0412] exist Figure 23 In steps ST1696 to ST1699 shown, connections are made between the UE, base station #2, UPF #2-2, anchor point UPF, and DN. Figure 12 The same process applies to steps ST1196 to ST1199.

[0413] As another example of a PDU session change notification to the UE, the notification can be sent from the anchor point NW to the UE. For example, the anchor point AMF can send this notification to the UE. This notification from the anchor point AMF to the UE can use the methods disclosed in Implementation 1, for example... Figures 20-22 The method disclosed in the document.

[0414] An anchor SMF can request this notification to the UE from the anchor AMF. This notification from the anchor AMF to the UE can be triggered by this request. Alternatively, the anchor SMF can send this request to the anchor AMF as a response to a UPF handover request from a non-anchor SMF to the anchor SMF.

[0415] Other solutions are disclosed. The intermediate UPF switching process can be initiated by the NW to which the intermediate UPF belongs. For example, the intermediate UPF switching process for a non-anchor NW can be initiated by the non-anchor NW. For example, a non-anchor SMF can initiate the switching process.

[0416] A non-anchor SMF can select a switching intermediate UPF, establish a connection with the switching intermediate UPF, and release the connection with a faulty intermediate UPF. This action in a non-anchor SMF can be performed in the same way as described above.

[0417] The non-anchor SMF can notify the anchor SMF of information regarding UPF handover. This notification can be, for example, a request for PDU session modification. This notification from the non-anchor SMF to the anchor SMF can use signaling such as Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31). The notification can include information about the intermediate UPF failure, information about the UE, information about the PDU session, information about QoS flows, information about the failed intermediate UPF, information about the intermediate UPF after handover, and information about QoS monitoring settings disclosed in Implementation 1.

[0418] An anchor SMF can notify the anchor UPF that the intermediate UPF has been switched, or it can request a switch of connection with the intermediate UPF. This notification and / or request from the anchor SMF to the anchor UPF can be, for example, the same as described above. The anchor UPF can notify the anchor SMF that the connection switch with the intermediate UPF is complete. This notification from the anchor UPF to the anchor SMF can be, for example, the same as described above.

[0419] The anchor SMF can respond to the aforementioned notification to a non-anchor SMF. This response can be, for example, a response to a PDU session change request. This response from the anchor SMF to the non-anchor SMF can use, for example, signaling such as Nsmf_PDUSession_Modification_Response (see Non-Patent Document 31).

[0420] Figure 25 This is a sequence diagram representing other examples of intermediate UPF switching actions in non-anchor point NW. Figure 25 The example shown illustrates how a non-anchor NW detects NW faults and determines UPF switching. Figure 25 In the example shown, the intermediate UPF of NW1091 is switched from UPF#2-1 to UPF#2-2. Figure 25 In the example shown, with Figure 12 , Figure 17 , Figure 19 , Figure 23 The same process is labeled with the same step number, and common explanations are omitted.

[0421] Figure 25 The steps ST1196 to ST1199 shown are... Figure 12 same.

[0422] Figure 25 The steps shown in ST1420 and Figure 19 same.

[0423] Figure 25 The process shown in 1625 and Figure 23 and Figure 24 same.

[0424] exist Figure 25 In step ST1758, SMF#2 requests a PDU session change from SMF#1. This request in ST1758 can be a notification regarding UPF handover information. ST1758 can use signaling such as Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31). This request can include information about intermediate UPF failures, information about the UE, information about the PDU session, information about QoS flows, information about the failed intermediate UPF, information about the intermediate UPF after handover, and information about QoS monitoring settings disclosed in Embodiment 1. SMF#1 can initiate connection processing between the anchor UPF and UPF#2-2, triggered by step ST1758.

[0425] Figure 25 The steps ST1159, ST1160 and shown are Figure 12 same.

[0426] exist Figure 25 In step ST1761, SMF#1 responds to SMF#2's request for a PDU session modification. Step ST1761 can be performed as a response to step ST1758. Step ST1761 can use signaling such as Nsmf_PDUSession_Modification_Response.

[0427] Figure 25 The process shown in 1161 and Figure 12 and Figure 16 Same. Figure 25 In the middle, it is also possible to skip it. Figure 12 The process shown is ST1191.

[0428] Figure 25 The steps ST1696 to ST1699 shown are... Figure 23 same.

[0429] The NW that detects an NW failure can be different from the NW that initiates the intermediate UPF handover process. For example, an NW failure can be detected by the anchor NW, and the intermediate UPF handover process can be initiated by a non-anchor NW. The anchor SMF can notify the non-anchor SMF of information about the NW failure. This notification can include information about the failed intermediate UPF, information about the PDU session, and information about QoS flows. The non-anchor SMF can then initiate the intermediate UPF handover process based on this notification.

[0430] The NW that initiates the intermediate UPF switching process can be predetermined by the standard. For example, it can be set to initiate the intermediate UPF switching process when an NW fault is detected. Thus, for example, the intermediate UPF switching process can be executed quickly. As another example, it can be set to initiate the intermediate UPF switching process when an NW fault occurs.

[0431] As another example, the anchor point NW can determine the NW that initiates the intermediate UPF switching process. The anchor point NW can, for example, be triggered by detecting an NW fault, or it can be triggered by receiving a notification from a non-anchor point regarding an NW fault.

[0432] An anchor NW can notify non-anchor NWs of information about an NW that has initiated intermediate UPF handover processing. As another example, it is possible to determine which NW initiates intermediate UPF handover processing based on information contained in the signaling transmitted from the anchor SMF to the non-anchor SMF. For example, it can be determined that the anchor NW initiated intermediate UPF handover processing by including a UPF handover request, or by including information about an NW fault. Thus, for example, the size of the signaling from the anchor NW to the non-anchor NW can be reduced.

[0433] As another example, the UE can decide which NW to initiate intermediate UPF handover processing. The UE can notify the anchor AMF of information about the NW that will initiate intermediate UPF handover processing. This information can be, for example, from the UE's preference information. The anchor AMF can then notify the anchor SMF of this information. Thus, for example, the UE can select an NW with lower latency between itself and the UE, resulting in a faster intermediate UPF handover process.

[0434] A PDU session change request for the UE can be made from the anchor NW. For example, the anchor NW can notify the UE of information regarding PDU sessions conducted through non-anchor NWs. The PDU session change request from the anchor NW can be made using, for example, the same method disclosed in Implementation 1. For example, it can be made using... Figures 20-22The method disclosed herein. Thus, for example, it is possible to prevent competition between PDU session requests sent to the UE from the anchor point NW and PDU session requests sent to the UE from the non-anchor point NW, thereby preventing malfunctions of the UE.

[0435] Faulty intermediate UPFs can be released. This release can, for example, be applied when a UE connects to an anchor UPF via multiple intermediate UPFs from a non-anchor NW, and a portion of these intermediate UPFs fails. The UE can connect to the anchor UPF via an intermediate UPF that has not failed. The response to a UPF handover request from a non-anchor SMF to the anchor SMF, and / or the notification of information regarding the UPF handover, can include information about the non-faulty intermediate UPFs, and may also include information about the base station of the non-anchor NW. Thus, for example, the flexibility of path handover in the event of a fault in the communication system can be improved.

[0436] Non-anchor base stations and anchor UPFs can be directly connected. For example, this direct connection can be triggered by a failure of an intermediate UPF in a non-anchor NW. The non-anchor SMF can instruct the non-anchor base station to connect to the anchor UPF. This instruction can be given via the non-anchor AMF. The instruction can include information about the anchor UPF (e.g., its address). The non-anchor base station can initiate a connection with the anchor UPF based on this instruction. The non-anchor SMF can notify the anchor SMF of information about the non-anchor base station. The anchor SMF can notify the anchor UPF of information about the non-anchor base station. The anchor UPF can initiate a connection with the non-anchor base station based on this notification. Thus, for example, latency in the non-anchor NW can be reduced.

[0437] Non-anchor base stations and anchor UPFs can be connected via SEPP. The method for this connection can be the same as the method used for the direct connection between a non-anchor base station and an anchor UPF described above.

[0438] According to this embodiment 2, recovery can be achieved from intermediate UPF faults in non-anchor point NW.

[0439] Implementation method 3.

[0440] In Implementation 3, other examples of methods for recovering from NW faults are disclosed.

[0441] The NW used as the data path can be switched. For example, in data transmission and reception via a non-anchor NW, the data transmission and reception path can be switched to the anchor NW as a trigger when a fault is detected in the intermediate UPF of the non-anchor NW.

[0442] An anchor NW can initiate this switchover for an NW that serves as a path. For example, an anchor NW can initiate this switchover by detecting a fault in a non-anchor NW. For example, an anchor SMF can initiate this switchover.

[0443] The anchor SMF can notify the non-anchor NW of information regarding NW handover, and can also request the release of a faulty intermediate UPF. This notification and / or request can be made, for example, to the non-anchor SMF. This notification and / or request can be made, for example, as a PDU session modification request, or as a PDU session release request. This notification and / or request can use, for example, signaling such as Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31), or signaling such as Nsmf_PDUSession_Release_Request (see Non-Patent Document 31). This notification and / or request can include information about NW faults, information about faulty intermediate UPFs, information about the UE, information about PDU sessions, and information about QoS flows.

[0444] Non-anchored network (NW) can release resources of a failed intermediate network (UPF). For example, a non-anchored network (SMF) can request the release of a connection from a failed intermediate UPF. This request can be made using, for example, the same method disclosed in Implementation 2.

[0445] A non-anchor SMF can notify a non-anchor AMF of the release of resources in a faulty intermediate UPF. This notification may include a request for NAS signaling information. This NAS signaling may be, for example, NAS signaling related to PDU session changes. The non-anchor AMF can also notify a non-anchor SMF of this NAS signaling information. This notification from a non-anchor AMF to a non-anchor SMF can be triggered by this request from the non-anchor SMF to the non-anchor AMF.

[0446] The NAS signaling may contain information about RRC signaling. This RRC signaling may be, for example, RRC signaling related to PDU session changes. A non-anchor AMF may request RRC signaling information from a non-anchor base station. A non-anchor base station may notify a non-anchor AMF of the RRC signaling information. This notification from the non-anchor base station to the non-anchor AMF may be triggered by this request from the non-anchor AMF to the non-anchor base station.

[0447] The non-anchor SMF can notify the anchor SMF of the release of the faulty intermediate UPF. This notification can be, for example, a response to a PDU session change request or a PDU session release request. The notification can use, for example, signaling of Nsmf_PDUSession_Modification_Response (see Non-Patent Document 31) or Nsmf_PDUSession_Release_Response (see Non-Patent Document 31). The notification can include, for example, information about NAS signaling. This NAS signaling can be, for example, NAS signaling related to PDU session change. This NAS signaling can be, for example, NAS signaling obtained from the non-anchor AMF. This NAS signaling can include RRC signaling. This RRC signaling can be, for example, RRC signaling related to PDU session release. This RRC signaling can be, for example, RRC signaling obtained from the non-anchor base station.

[0448] The anchor SMF can be configured with a UPF. This UPF can be, for example, an intermediate UPF of the anchor NW or an anchor UPF. This UPF configuration can be, for example, securing resources for the UPF for UE communication. In this UPF configuration, for example, some or all of the processing disclosed in PDU session establishment (non-patent document 31 4.3.2) can be performed.

[0449] The anchor point SMF can configure NW switching settings for the anchor point UPF. For example, the anchor point SMF can instruct the anchor point UPF to release the connection with the faulty intermediate UPF. The anchor point UPF can then release the connection with the faulty intermediate UPF based on this instruction.

[0450] The anchor SMF can notify the anchor AMF of PDU session changes. The anchor AMF can then notify the UE of the PDU session changes. This notification can be sent via the base station of the anchor NW (hereinafter sometimes referred to as the anchor base station). The UE can use this notification as a trigger to change its own PDU session settings.

[0451] This notification from the anchor SMF to the anchor AMF can be triggered by a notification from the non-anchor SMF to the anchor SMF regarding the release of a fault intermediate UPF. This notification from the anchor SMF to the anchor AMF may include information about NAS signaling. This NAS signaling may include NAS signaling from the anchor NW or from the non-anchor NW. Thus, for example, the UE can change the PDU session settings regarding the anchor NW and the non-anchor NW, resulting in improved communication efficiency in the communication system.

[0452] Figure 26This is a sequence diagram representing an example of NW switching actions in a non-anchor NW. Figure 26 This illustrates an example of how the anchor point NW detects NW faults and determines NW switching. Figure 26 In the example shown, NW switches from NW1091 to NW1090. In Figure 26 In the example shown, for and Figure 12 , Figure 17 The same processing is labeled with the same number, and common explanations are omitted.

[0453] Figure 26 The steps ST1196 to ST1199 shown are... Figure 12 same. Figure 26 The steps ST1220 shown are... Figure 17 same.

[0454] exist Figure 26 In step ST1806 shown, SMF#1 decides to switch the NW as the data path. Figure 26 In the example shown, SMF#1 decides to switch the data path via UPF#2 to NW1090.

[0455] exist Figure 26 In step ST1810, SMF#1 requests SMF#2 to release the PDU session. This request may include information about the UE, the PDU session, QoS flows, NW faults, and handover information about the NW as a path. The NW fault information may include information about the UPF that is the target of the NW fault. Step ST1810 may use the signaling Nsmf_PDUSession_Release_Request (see Non-Patent Document 31). SMF#2 may initiate the PDU session release action triggered by step ST1810.

[0456] Figure 26 The processes 1100, 1111 and shown are Figure 12 , Figure 13 and Figure 14 same.

[0457] Figure 26 The steps ST1656, ST1657 and shown are Figure 23 and Figure 24 same.

[0458] exist Figure 26 In the process shown in 1861, the following is performed: Figure 12 and Figure 16The process is the same as in procedure 1161. In procedure 1861, PDU session release can be performed instead of a PDU session establishment / modification request. In procedure 1861, the same signaling as in procedure 1161 can be used. Figure 16 The step ST1190 of process 1161 shown corresponds to step ST1190 of process 1861, which is the process of ending the session management policy association between SMF#2 and PCF#2. This process can be, for example, the process disclosed in section 4.16.6 of non-patent document 31 (3GPP TS23.502).

[0459] exist Figure 26 In step ST1891, SMF#2 responds to SMF#1's request to release the PDU session. Step ST1891 can be performed as a response to step ST1810.

[0460] Figure 26 The steps ST1192 to ST1195 shown are... Figure 12 same.

[0461] Other solutions are disclosed. A non-anchor NW can initiate this switchover for an NW that is a path. For example, an anchor NW can initiate the switchover based on the detection of a fault in a non-anchor NW, or based on a notification of a fault in an NW from an anchor NW.

[0462] A non-anchor NW can request a handover from an anchor NW. This request can, for example, occur between a non-anchor SMF and an anchor SMF. The request can include information about the faulty intermediate UPF, information about the UE, information about the PDU session, and information about QoS flows. The anchor NW can trigger UPF configuration based on this request. This configuration can, for example, secure resources for UPF communication for the UE. The UPF configuration within the anchor NW can be the same as described above.

[0463] Figure 27 This is a sequence diagram representing other examples of NW switching actions in non-anchor NW. Figure 27 The example shown illustrates how a non-anchor NW detects NW faults and determines NW switching. Figure 27 In the example shown, NW switches from NW1091 to NW1090. In Figure 27 In the example shown, with Figure 12 , Figure 17 , Figure 19 , Figure 23 , Figure 24 , Figure 26 The same process is labeled with the same step number, and common explanations are omitted.

[0464] Figure 27 The steps ST1196 to ST1199 shown are... Figure 12 same. Figure 27 The steps shown in ST1420 and Figure 19 same.

[0465] exist Figure 27 In step ST1906 shown, SMF#2 decides to switch the NW as the data path. Figure 27 In the example shown, SMF#2 decides to switch the data path via UPF#2 to NW1901.

[0466] exist Figure 27 In step ST1910, SMF#2 requests a PDU session modification from SMF#1. This request may include information about the UE, information about the PDU session, information about QoS flows, information about NW faults, and information about the handover of the NW as a path. The information about NW faults may include information about the UPF that is the target of the NW fault. Step ST1910 may use the signaling of Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31).

[0467] exist Figure 27 In step ST1910 shown, a request to establish a PDU session can also be made. For example, the signaling Nsmf_PDUSession_Establishment_Request can be used (see Non-Patent Document 31).

[0468] Figure 27 The processes 1100, 1111 and shown are Figure 12 , Figure 13 and Figure 14 same.

[0469] Figure 27 The steps ST1656, ST1657 and shown are Figure 23 and Figure 24 same.

[0470] exist Figure 27 In step ST1961, SMF#1 responds to SMF#2's request for a PDU session change. Step ST1961 can be performed as a response to step ST1910.

[0471] Figure 27 The process shown in 1861 and Figure 26 Same. Steps ST1192 to ST1195 are the same. Figure 12 same.

[0472] The NW that detects an NW fault can be different from the NW that initiates the NW handover process. For example, the NW fault can be detected by the anchor NW, and the NW handover process can be initiated by a non-anchor NW. The anchor SMF can notify the non-anchor SMF of information about the NW fault. This notification can include information about the intermediate UPF during the fault, information about the PDU session, and information about QoS flows. The non-anchor SMF can then initiate the NW handover process based on this notification.

[0473] The NW that initiates the NW handover process can be predetermined by the standard. For example, it can be set to initiate the NW handover process when an NW fault is detected. Thus, for example, the NW handover process can be executed quickly. As another example, it can be set to initiate the NW handover process when an NW fault occurs.

[0474] As another example, the anchor NW can determine the NW that initiates the NW handover process. The anchor NW can decide to initiate the NW handover process, for example, triggered by the detection of an NW fault, or triggered by receiving a notification from a non-anchor NW regarding an NW fault.

[0475] An anchor NW can notify non-anchor NWs of information about an NW that has initiated NW handover processing. As another example, the information contained in the signaling transmitted from the anchor SMF to the non-anchor SMF can be used to determine which NW has initiated NW handover processing. For example, the presence of an NW handover request can indicate that an anchor NW has initiated NW handover processing, while the presence of information about an NW fault can indicate that a non-anchor NW has initiated NW handover processing. This, for example, can reduce the size of the signaling from the anchor NW to the non-anchor NW.

[0476] As another example, the UE can decide on the NW (Network Wireless) to initiate NW handover processing. The UE can notify the anchor AMF (Anchor Element Filter) of information about the NW to initiate handover processing. This information can be, for example, from the UE's preference information. The anchor AMF can then notify the anchor SMF (Anchor Element Filter). Thus, for example, the UE can select an NW with lower latency between itself and the UE, resulting in faster NW handover processing.

[0477] A priority order can be set between the intermediate UPF switching disclosed in Embodiment 2 and the NW switching disclosed in Embodiment 3.

[0478] For example, intermediate UPF switching can be prioritized. This, for example, can prevent the load on other NWs from increasing.

[0479] As another example, NW switching can be prioritized. This, for instance, allows for service distribution across NWs.

[0480] As another example, the UE can decide which handover process to prioritize. The UE can notify the anchor AMF of this information. This information could be, for example, from the UE's preference information. The anchor AMF can then notify the anchor SMF of this information. Thus, for example, a less complex process for the UE can be implemented, resulting in reduced UE power consumption.

[0481] As another example, the priority of which switching process can be determined by the anchor NW, the NW that detects the fault, or the NW that experiences the fault.

[0482] The decision on which handover process to perform can be made each time. This decision can be made by the anchor NW device, such as the anchor SMF, or by the non-anchor NW device, such as the non-anchor SMF. For example, the anchor SMF can make this decision using information about the QoS and / or QoE of the non-anchor NW, information about its own NW, or both. As another example, the non-anchor SMF can make this decision using information about the QoS and / or QoE of the anchor NW, information about its own NW, or both.

[0483] Information about QoS and / or QoE may include, for example, information about the QoS and / or QoE supported in the NW, information about the measurement results of QoS and / or QoE, and information about the QoS and / or QoE required by the service.

[0484] Non-anchor NWs can notify anchor NWs of their own QoS and / or QoE information. Anchor NWs can request QoS and / or QoE information from non-anchor NWs. This notification from a non-anchor NW to an anchor NW can be triggered by this request from an anchor NW to a non-anchor NW.

[0485] As another example, an anchor NW can notify a non-anchor NW of information about its own QoS and / or QoE. A non-anchor NW can request information about QoS and / or QoE from an anchor NW. This notification from the anchor NW to the non-anchor NW can be triggered by this request from the non-anchor NW to the anchor NW.

[0486] In the NW handover disclosed in this embodiment 3, the PDU session of the anchor NW can be changed, or the PDU session can be established.

[0487] The method disclosed in Embodiment 3 can be used both when a PDU session has been established in the anchor point NW and when no PDU session has been established in the anchor point NW. For example, PDU session changes during NW handover processing can be performed when a PDU session has been established in the anchor point NW. As another example, PDU session establishment during NW handover processing can be performed when no PDU session has been established in the anchor point NW.

[0488] According to this embodiment 3, recovery from NW failure can be achieved, and the load of NW can be distributed.

[0489] Variation 1 of Implementation Method 3.

[0490] In this variation 1, other examples regarding NW switching are disclosed.

[0491] The NW, which serves as the data path, can switch from the anchor NW to a non-anchor NW. For example, in data transmission and reception via the anchor NW, the data transmission and reception path can be switched to a non-anchor NW triggered by the detection of a fault in the intermediate UPF of the anchor NW.

[0492] An anchor NW can initiate this switch for an NW that serves as a path. For example, an anchor NW can initiate this switch if it detects a fault in its own NW. For example, an anchor SMF can initiate this switch.

[0493] An anchor NW can initiate the handover using information about the QoS and / or QoE of the non-anchor NW, information about its own NW, or both.

[0494] Information about QoS and / or QoE may include, for example, information about the QoS and / or QoE supported in the NW, information about the measurement results of QoS and / or QoE, and information about the QoS and / or QoE requested by the service.

[0495] Non-anchor NWs can notify anchor NWs of their own QoS and / or QoE information. Anchor NWs can request QoS and / or QoE information from non-anchor NWs. This notification from a non-anchor NW to an anchor NW can be triggered by this request from an anchor NW to a non-anchor NW.

[0496] Within the anchor point (NW), PDU sessions can be released and modified. Within the non-anchor point (NW), PDU sessions can be established and modified.

[0497] The anchor SMF can notify the non-anchor NW of NW handover information. This notification can be made, for example, to the non-anchor SMF. The notification can be made, for example, as a request to establish a PDU session or as a request to modify a PDU session. The notification and / or the request can use, for example, signaling such as Nsmf_PDUSession_Establishment_Request (see Non-Patent Document 31) or Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31). The notification and / or the request can include information about NW faults, information about intermediate UPFs during faults, information about the UE, information about the PDU session, and information about QoS flows.

[0498] Anchor points (NW) can release resources from failed intermediate UPFs. For example, anchor points (SMF) can request the release of connections from failed intermediate UPFs.

[0499] The non-anchor point (NW) can determine the intermediate UPF after the switch and can initiate a connection with the intermediate UPF after the switch.

[0500] Non-anchor point NWs can notify anchor point NWs of information about the intermediate UPF after the handover. Anchor point SMFs can instruct anchor point UPFs to initiate a connection with the intermediate UPF after the handover.

[0501] Figure 28 This is a sequence diagram representing an example of NW switching actions in anchor point NW. Figure 28 The example shown illustrates how anchor point NW detects NW faults and determines NW switching. Figure 28 In the example shown, NW switches from NW1090 to NW1091. In Figure 28 In the example shown, with Figure 12 , Figure 17 , Figure 18 , Figure 23 , Figure 26 The same process is labeled with the same step number, and common explanations are omitted.

[0502] Figure 28 The steps ST1192 to ST1195 shown are... Figure 12 Same. Step ST1220 and Figure 17 Same. Step ST1806 and Figure 26 Same. Figure 28 In step ST1806 shown, SMF#1 decides to switch the data path through UPF#1 to NW1091.

[0503] exist Figure 28In step ST2010, SMF#1 requests SMF#2 to establish a PDU session. It can also request a modification of the PDU session. This request may include information about the UE, information about the PDU session, information about QoS flows, information about NW faults, and information about handover of the NW as a path. The information about NW faults may include information about the UPF that is the target of the NW fault. Step ST2010 can use either the signaling of Nsmf_PDUSession_Establish_Request (see Non-Patent Document 31) or the signaling of Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31).

[0504] Figure 28 The process shown is 1150 and Figure 12 and Figure 15 same.

[0505] exist Figure 28 In steps ST2056 and ST2057 shown, an AND operation is performed between SMF#1 and UPF#1. Figure 23 and Figure 24 The same processing is applied to steps ST1656 and ST1657 of process 1625 shown.

[0506] exist Figure 28 In the process shown in 2011, the following steps are performed: Figure 12 and Figure 14 The process is the same as in procedure 1111. In procedure 2011, PDU session release can be performed instead of a PDU session establishment / modification request. In procedure 2011, the same signaling as in procedure 1161 can be used. Figure 14 The step ST1140 of process 1111 shown corresponds to step ST1140 of process 2011, which is the process of ending the session management policy association between SMF#1 and PCF#1. This process can be, for example, the process disclosed in section 4.16.6 of non-patent document 31 (3GPP TS23.502).

[0507] Figure 28 The steps ST1158 to ST1160 shown are... Figure 12 Same. Process 1161 and Figure 12 and Figure 16 Same. Step ST1386 ​​and Figure 18 Same. Steps 1196 to ST1199 are the same. Figure 12 same.

[0508] A priority order can be set between the intermediate UPF switching within the anchor point NW and the NW switching disclosed in this variation 1.

[0509] For example, intermediate UPF switching can be prioritized. This, for example, can prevent the load on non-anchor point NWs from increasing.

[0510] As another example, NW switching can be prioritized. This, for instance, allows for service distribution across NWs.

[0511] As another example, the UE can decide which handover process to prioritize. The UE can notify the anchor AMF of this information. This information could be, for example, from the UE's preference information. The anchor AMF can then notify the anchor SMF of this information. Thus, for example, a less complex process for the UE can be implemented, resulting in reduced UE power consumption.

[0512] As another example, the anchor point NW can determine which handover process takes precedence. For instance, the anchor point SMF can determine which handover process takes precedence, or the anchor point PCF can determine it.

[0513] The decision on which handover process to perform can be made each time. This decision can be made by the anchor NW device, such as the anchor SMF. For example, the anchor SMF can make this decision using information about the QoS and / or QoE of the non-anchor NW, information about the QoS and / or QoE of its own NW, or both.

[0514] Information regarding QoS and / or QoE may include, for example, information about the QoS and / or QoE that the NW can support, information about the measurement results of QoS and / or QoE, and information about the QoS and / or QoE required by the service.

[0515] Non-anchor NWs can notify anchor NWs of their own QoS and / or QoE information. Anchor NWs can request QoS and / or QoE information from non-anchor NWs. This notification from a non-anchor NW to an anchor NW can be triggered by this request from an anchor NW to a non-anchor NW.

[0516] In the NW handover disclosed in this variation 1, PDU session changes for non-anchor NWs can be performed, as well as PDU session establishment.

[0517] The method disclosed in this variation 1 can be used both when a PDU session has been established in a non-anchor NW and when a PDU session has not been established in a non-anchor NW. For example, a PDU session change during NW handover processing can be performed when a PDU session has been established in a non-anchor NW. As another example, PDU session establishment during NW handover processing can be performed when a PDU session has not been established in a non-anchor NW.

[0518] According to this variation 1, recovery from NW faults can be achieved, while simultaneously distributing the load of NW.

[0519] Implementation method 4.

[0520] In Implementation 4, other examples of methods for recovering from NW faults are disclosed.

[0521] Anchor point UPF switching is possible. For example, this switching can be triggered by detecting a fault in the anchor point UPF. The anchor point SMF can perform this detection.

[0522] The anchor point SMF determines the new anchor point UPF (sometimes referred to as the post-switching anchor point UPF). The anchor point SMF establishes the connection with the post-switching anchor point UPF.

[0523] The anchor SMF can request connection establishment from the post-handover anchor UPF. This request can use signaling such as an N4 Session Establishment Request (see Non-Patent Document 31). This request can include information about the UE, information about the PDU session, information about QoS flows, information about QoS monitoring disclosed in Implementation 1, and information about the intermediate UPF. For example, by including information about the intermediate UPF, the connection between the post-handover anchor UPF and the intermediate UPF can be quickly established.

[0524] After the switchover, the anchor UPF can respond to the anchor SMF to establish a connection. This response can use signaling such as the N4 Session Establishment Response (see Non-Patent Document 31). The anchor SMF can use this response as a trigger to confirm the connection completion of the anchor UPF after the switchover.

[0525] Anchor SMFs can request to release connections from faulty anchor UPFs (hereinafter sometimes referred to as faulty anchor UPFs). This request can use signaling such as an N4 Session Release Request (see Non-Patent Document 31). The request may contain information about the UE, information about the PDU session to be released, and information about the QoS flow to be released. The faulty anchor UPF can use this information to release resources associated with the PDU session and / or QoS flow.

[0526] The faulty anchor point UPF can respond to the anchor point SMF's connection release request. This response can use signaling such as the N4 Session Release Response (see Non-Patent Document 31). The anchor point SMF can use this response as a trigger to know that the release of the faulty anchor point UPF has been completed.

[0527] Anchor SMFs can request connection changes from intermediate UPFs. This request can use signaling such as 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 QoS flows, information about QoS monitoring disclosed in Implementation 1, and information about the post-handover anchor UPF. Using this information, the intermediate UPF can initiate a connection with the post-handover anchor UPF or terminate a connection with a faulty anchor UPF. As another example, the intermediate UPF can use this information to change the anchor UPF to which the connection is targeted.

[0528] Anchor SMFs can notify non-anchor SMFs of UPF switching. They can also request UPF switching. This notification and / or request can use signaling such as Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31). The notification and / or request can contain information about the anchor UPF after the switch. Thus, for example, non-anchor SMFs can quickly learn that the anchor UPF has been switched.

[0529] A non-anchor SMF can request a switchover connection target from an intermediate UPF. This request may include information about the new anchor UPF, information about the UE, information about the PDU session, information about QoS flows, and information about QoS monitoring settings disclosed in Implementation 1. This request can use, for example, signaling such as an N4 Session Modification Request (see Non-Patent Document 31). The intermediate UPF can switch its connection with the anchor UPF triggered by this request. For example, triggered by this request, the intermediate UPF can release the N9 interface with the faulty anchor UPF (see Non-Patent Document 10) or establish an N9 interface with the new anchor UPF.

[0530] The intermediate UPF can notify the non-anchor SMF that the connection handover with the anchor UPF is complete. This notification can use signaling such as an N4 Session Modification Response (see Non-Patent Document 31). The non-anchor SMF can use this notification as a trigger to know that the connection handover between the intermediate UPF and the anchor UPF after the handover is complete.

[0531] The non-anchor NW can notify the UE of changes to the PDU session. This notification can be made, for example, from the non-anchor SMF or via the non-anchor AMF. As another example, the notification can be made from the non-anchor AMF. The UE can then use this notification as a trigger to perform settings related to the anchor UPF handover.

[0532] The non-anchor SMF can respond to the UPF handover request from the anchor SMF. This response can use signaling such as Nsmf_PDUSession_Modification_Response (see Non-Patent Document 31). Thus, for example, the anchor SMF can quickly ascertain the completion of the connection between the intermediate UPF of the non-anchor NW and the anchor UPF after the handover.

[0533] Notification of anchor point UPF handover from anchor point NW to non-anchor point NW can be made even if a PDU session has not been established in the non-anchor point NW. The non-anchor point NW device can maintain information about the anchor point UPF handover. This maintenance can be performed, for example, by the non-anchor point SMF. This information can be used, for example, for PDU session establishment in the non-anchor point NW. Thus, for example, PDU session establishment in the non-anchor point NW can be performed quickly.

[0534] Figure 29 and Figure 30 This is a sequence diagram illustrating an example of the switching action of the anchor point UPF. Figure 29 This represents the first half of the sequence. Figure 30This represents the latter half of the sequence. Figure 29 and Figure 30 This represents a series of actions (the switching action of the anchor point UPF). In Figure 29 and Figure 30 In the example shown, anchor point UPF#1 is switched to anchor point UPF#2 within the same NW. In Figure 29 and Figure 30 The example shown illustrates how anchor point NW detects NW faults and how anchor point NW determines anchor point UPF switching. Figure 29 and Figure 30 In the example shown, with Figure 12 , Figure 17 , Figure 23 The same process is labeled with the same step number, and common explanations are omitted.

[0535] Figure 29 The steps ST1192 to ST1199 shown are... Figure 12 Same. Step ST1220 and Figure 17 Same. Figure 29 In step S1220, SMF#1 detects a fault in anchor point UPF#1. Step ST1621 and... Figure 23 Same. Figure 29 In step ST1621, SMF#1 determines the switching of the anchor point UPF. Steps ST1101 and... Figure 12 and Figure 13 Same. Figure 29 In step ST1101, SMF#1 selects anchor point UPF#2. Step ST1102 and... Figure 12 and Figure 13 same.

[0536] exist Figure 29 In step ST2104, SMF#1 requests N4 session establishment from anchor UPF#2. Anchor UPF#2 initiates N4 session establishment, triggered by step ST2104. In step ST2105, anchor UPF#2 responds to SMF#1 in response to step ST2104.

[0537] exist Figure 29 In step ST2106, SMF#1 requests N4 session release from anchor UPF#1. Anchor UPF#1 initiates N4 session release triggered by step ST2106. In step ST2107, anchor UPF#1 responds to SMF#1 in response to step ST2106.

[0538] exist Figure 29In step ST2108, SMF#1 requests an N4 session change from UPF#1. This request may include information about changes to the target UPF. It may also include information about the anchor UPF#2. UPF#1 can switch its target UPF, triggered by step ST2108. In step ST2109, UPF#1 responds to SMF#1 in response to step ST2108.

[0539] exist Figure 29 In step ST2110, SMF#1 requests a PDU session modification from SMF#2. This request may include information about the UE, the PDU session, QoS flows, NW faults, UPF handover, and the UPF after the handover. The NW fault information may include information about the UPF that became the NW fault target. Step ST2110 may use the signaling of Nsmf_PDUSession_Modification_Request (see Non-Patent Document 31).

[0540] exist Figure 30 In the process 2111 shown, it is possible to perform with Figure 12 and Figure 14 The same process is shown in process 1111. In Figure 30 In the process 2111 shown, it can replace Figure 12 and Figure 14 The anchor point UPF shown is processed, and anchor point UPF#2 is processed.

[0541] exist Figure 30 In steps ST2154 and ST2155 shown, an AND operation is performed between SMF#2 and UPF#2. Figure 29 The steps ST2108 and ST2109 shown are processed in the same way.

[0542] Figure 30 The process shown in 1161 and Figure 12 and Figure 16 same.

[0543] exist Figure 30 In step ST2186, SMF#2 responds to SMF#1's request for a PDU session change. Step ST2186 can be used as a response to... Figure 29 The response to step ST2110 shown is used.

[0544] exist Figure 30In steps ST1192, ST1193, ST2194, and ST2195, data transmission and reception between the UE and DN via NW1090 are performed. Step ST1192 represents data transmission and reception between the UE and base station #1, step ST1193 represents data transmission and reception between base station #1 and UPF #1, step ST2194 represents data transmission and reception between UPF #1 and anchor point UPF #2, and step ST2195 represents data transmission and reception between anchor point UPF #2 and DN.

[0545] exist Figure 30 In steps ST1196, ST1197, ST2198, and ST2199, data transmission and reception between the UE and DN via NW1091 are performed. Step ST1196 represents data transmission and reception between the UE and base station #2, step ST1197 represents data transmission and reception between base station #2 and UPF #2, step ST2198 represents data transmission and reception between UPF #2 and anchor point UPF #2, and step ST2199 represents data transmission and reception between anchor point UPF #2 and DN.

[0546] Intermediate UPF switching can be performed. Intermediate UPF switching can be triggered by anchor UPF switching. The intermediate UPF that becomes the new intermediate UPF after switching (post-switching intermediate UPF) can be, for example, an intermediate UPF with high communication capacity with the post-switching anchor UPF, or an intermediate UPF with low latency in communication with the post-switching anchor UPF. Intermediate UPF switching can be performed at the anchor NW or at a non-anchor NW. Intermediate UPF switching can be performed using, for example, the same method disclosed in Embodiment 2. For example, the operation of each device in the non-anchor NW in Embodiment 2 can be performed in each device in the anchor NW. Therefore, for example, communication efficiency in the communication system can be improved.

[0547] Other solutions are disclosed. Other NW's UPF can be used as anchor UPFs. Anchor AMF, anchor SMF, and anchor PCF do not need to be switched. This, for example, improves the flexibility related to data transmission in the communication system.

[0548] As an alternative solution, anchor-point NW and non-anchor-point NW can be switched. This, for example, avoids the complexity of the communication system.

[0549] The handover can be determined by the anchor SMF. The anchor SMF can request the handover from the non-anchor SMF. The non-anchor SMF can respond to the anchor SMF's request. The anchor SMF can notify the anchor AMF of the anchor NW handover. The anchor AMF can use this notification as a trigger to perform processing during the handover from the anchor NW to the non-anchor NW. This processing may, for example, be a PDU session change. This processing can occur between the anchor base station and the UE. The non-anchor SMF can notify the non-anchor AMF of the non-anchor NW handover. The non-anchor AMF can use this notification as a trigger to perform processing during the handover from the non-anchor NW to the anchor NW. This processing may, for example, be a PDU session change. This processing can occur between the non-anchor base station and the UE.

[0550] The handover request from the anchor SMF to a non-anchor SMF can include information about the DN (Domain Name) or the UE (User Equipment). The DN information can include the DN address. The address information can include the IP address or information about the FQDN (Full Qualified Domain Name). The UE information can include the UE's address (e.g., IP address), the UE's identifier, and information about the UE's slice.

[0551] The non-anchor point SMF can notify the switched anchor point UPF of this information about the DN and / or the UE. Thus, for example, the switched anchor point UPF can quickly establish a connection with the DN.

[0552] In the anchor point UPF switching disclosed in this embodiment 4, the PDU session in the anchor point UPF after switching can be changed, or the PDU session can be established.

[0553] The anchor UPF change disclosed in Embodiment 4 can be performed either when a PDU session has been established in the anchor UPF or when no PDU session has been established in the anchor UPF. For example, the PDU session change of the anchor UPF can be performed when a PDU session has been established in the anchor UPF. As another example, the PDU session establishment of the anchor UPF can be performed when no PDU session has been established in the anchor UPF.

[0554] According to this embodiment 4, recovery can be achieved from the failure of the anchor point UPF, which can improve the availability of data communication in the communication NW.

[0555] The NW device in this disclosure can be an NF of an NW. For example, an anchor NW device can be an NF of an anchor NW. A non-anchor NW device can be an NF of a non-anchor NW. Thus, for example, the method shown in this disclosure can be applied even when multiple NFs of an NW are housed in the same device.

[0556] The method shown in this disclosure can be used in situations other than NW failure. For example, it can be used when QoS deteriorates. The NW failure detection shown in this disclosure can be QoS deterioration detection. Thus, for example, UPF handover and / or NW handover actions can be performed before communication is interrupted, resulting in improved availability of the communicating NW.

[0557] As another example, the method shown in this disclosure can be used under specified conditions. These specified conditions could be, for example, an increase in the load on the UPF or an increase in the load on the AMF. Thus, for example, further increases in the load on the UPF and / or AMF can be prevented, thereby preventing NW failure.

[0558] In this disclosure, signaling between different NWs can be performed via SEPP (refer to Non-Patent Document 10). This, for example, ensures the security of the signaling.

[0559] In this disclosure, the IPUPS (Inter PLMN User Plane Security) function (refer to Non-Patent Document 10) can be used in the forwarding of user data between different NWs. Thus, for example, security in user data forwarding can be ensured.

[0560] Transmission and reception between the base station and CN nodes (excluding the AMF) can be performed via the AMF. Alternatively, transmission and reception between the base station and CN nodes (excluding the AMF) can be performed without using the AMF. By bypassing the AMF, signaling traffic can be reduced, and the load on the AMF can be decreased.

[0561] In this specification, a node can be a function.

[0562] In the communication system disclosed herein, one gNB constitutes one or more cells. In this disclosure, it is referred to as gNB or cell, but unless otherwise specified, it can be either gNB or cell.

[0563] In this disclosure, gNB can be either MCG or SCG.

[0564] The above embodiments and their modifications are merely illustrative, and the embodiments and their modifications can be freely combined. Furthermore, any structural elements of the embodiments and their modifications can be appropriately modified or omitted.

[0565] For example, in the above embodiments and their variations, a time slot is an example of a time unit for communication in a 5G communication system. A time slot can be a scheduling unit. In the above embodiments and their variations, processing can be performed by recording in time slot units, such as TTI units, subframe units, sub-time slot units, and micro-time slot units.

[0566] For example, the methods disclosed in the above embodiments and their variations can be applied to IABs. They can be applied to communication between the IAB host and IAB nodes. They can also be applied to the processing of Uu within an IAB.

[0567] Label Explanation

[0568] 202 Communication terminal device (mobile terminal)

[0569] 210 Communication System

[0570] 213, 240-1, 240-2, 750 Base Station Equipment (NR Base Station, Base Station)

[0571] 214 5G Core Unit

[0572] 215 Central Unit

[0573] 216 Distributed Units

[0574] 217 Control plane central unit

[0575] 218 User-facing Central Unit

[0576] 219 TRP

[0577] 301 and 403 Protocol Processing Department

[0578] 302 Application Department

[0579] 304 and 405 coding sections

[0580] Modulation sections 305 and 406

[0581] 306, 407 Frequency Conversion Section

[0582] Antennas 307-1 to 307-4 and 408-1 to 408-4

[0583] 308, 409 De-escalation Department

[0584] Decoding sections 309 and 410

[0585] Control Departments 310, 411, and 526

[0586] 401 EPC Communications Department

[0587] 402 Other Base Station Communications Department

[0588] 412 5GC Communications Department

[0589] 521 Data Network Communications Department

[0590] 522 Base Station Communications Department

[0591] 523 User Plane Communications Department

[0592] 523-1 PDU Processing Department

[0593] 523-2 Moving Anchoring Unit

[0594] 525 Control Panel Control Unit

[0595] 525-1 NAS Security Department

[0596] 525-2 Idle Status Mobility Management Department

[0597] 527 Session Management Department

[0598] 527-1 PDU Session Control Unit

[0599] 527-2 UE IP Address Allocation Department

[0600] 751-1~751-8 Beams

[0601] 752 Community.

Claims

1. A communication system corresponding to a 5th generation wireless access system, characterized in that, This includes multiple networks comprising wireless access networks and core networks. The plurality of networks include: an anchor network connected to a communication terminal, which is a user plane network having direct connection to a data network of a target data transmission and reception device of the communication terminal; and a non-anchor network connected to the data network via the anchor network. The anchor network obtains information about the communication quality in the non-anchor network from the non-anchor network, performs fault detection in the non-anchor network based on the obtained information, and performs fault detection in its own network based on the information about the communication quality in its own network.

2. A communication system corresponding to a 5th generation wireless access system, characterized in that, This includes multiple networks comprising wireless access networks and core networks. The plurality of networks include: an anchor network connected to a communication terminal, which is a user plane network having direct connection to a data network of a target data transmission and reception device of the communication terminal; and a non-anchor network connected to the data network via the anchor network. The non-anchor network obtains information about the communication quality in the anchor network from the anchor network, performs fault detection in the anchor network based on the obtained information, and performs fault detection in its own network based on the information about the communication quality in its own network.

3. The communication system as described in claim 1, characterized in that, When the anchor network detects a fault in the non-anchor network, it requests the non-anchor network to switch the data transmission path within the non-anchor network. When it detects a fault in its own network, it switches the data transmission path within its own network.

4. The communication system as described in claim 1 or 3, characterized in that, When the anchor network detects a fault in a network device that is directly connected to and transmits data to the data network, it switches the network device that is directly connected to and transmits data to the data network.

5. The communication system as described in claim 1, characterized in that, When the anchor network detects a fault in the non-anchor network, it requests the non-anchor network to switch the transmission path of data sent and received via the non-anchor network to the transmission path via its own network. When it detects a fault in its own network, it switches the transmission path of data sent and received via its own network to the transmission path via the non-anchor network.

6. The communication system as described in claim 2, characterized in that, When the non-anchor network detects a fault in the anchor network, it requests the anchor network to switch the data transmission path within the anchor network. When it detects a fault in its own network, it switches the data transmission path within its own network.

7. The communication system as described in claim 2 or 6, characterized in that, When the non-anchor network detects a fault in a network device that is directly connected to and transmits data to the data network, it requests the anchor network to switch the network device that is directly connected to and transmits data to the data network.

8. The communication system as described in claim 2, characterized in that, When the non-anchor network detects a fault in the anchor network, it requests the anchor network to switch the transmission path of data sent and received via the anchor network to the transmission path via its own network. When it detects a fault in its own network, it switches the transmission path of data sent and received via its own network to the transmission path via the anchor network.

Images