Base station device, base station device switching method, and program
The base station device addresses the vulnerability of mobile communication systems to transport network failures by transferring MM and SM contexts during handovers, ensuring continuous communication services even in the event of transport network failures.
Patent Information
- Application Number
- PCT/JP2024/039185
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-11-21
- Filing Date
- 2024-11-05
- Publication Date
- 2025-05-30
AI Technical Summary
Current mobile communication systems are vulnerable to transport network failures, which can disrupt communication services and prevent terminals from receiving application services even if the base station itself is functioning correctly.
A base station device equipped with a context holding unit to store Mobility Management (MM) and Session Management (SM) contexts for each terminal, and a context transfer unit to seamlessly transfer these contexts to a target base station during handover, ensuring continuous communication service even in the event of transport network failures.
The solution enables the provision of communication services that are highly resistant to transport network failures, ensuring that terminals can continue to receive application services and maintain connectivity during handovers, even if the transport network is disrupted.
Smart Images

Figure JP2024039185_30052025_PF_FP_ABST
Abstract
Description
Base station device, base station device switching method and program
[0001] The present disclosure relates to a base station device, a base station device switching method, and a program, and relates to a base station device, a base station device switching method, and a program that enable the provision of communication services that are highly resistant to failures in a transport network.
[0002] With the spread of multi-access edge computing (MEC), terminals (UEs) are increasingly receiving application services from MEC servers. By using MEC, it is possible to reduce response delays of application services, for example.
[0003] Generally, each terminal in a mobile communication system communicates with an MEC server via a UPF, which is one of the network function units of a core network. Therefore, for example, if the UPF is located in a specific data center, the advantages of the MEC cannot be utilized. Therefore, in the future, it is highly likely that multiple UPFs will be located near base stations (RANs: Radio Access Networks).
[0004] Furthermore, a technology has been proposed for providing seamless streaming even when a handover occurs in the MEC architecture (see, for example, Patent Document 1). By adopting such an MEC architecture, it becomes possible to provide a stable, low-latency network service.
[0005] Japanese Patent Application Publication No. 2022-51973
[0006] A base station device according to one aspect of the present disclosure is a base station device of a mobile communication network, and includes: a context holding unit that stores an MM (Mobility Management) context and an SM (Session Management) context for each terminal connected to the base station device; and a context transfer unit that, when a handover of the terminal is detected, transfers the MM context and SM context of the terminal to a base station device that is a target of the handover.
[0007] A base station device switching method according to one aspect of the present disclosure is a base station device switching method for a mobile communication network, which stores an MM (Mobility Management) context and an SM (Session Management) context for each terminal connected to a base station device, and, when a handover of the terminal is detected, transfers the MM context and SM context of the terminal to a base station device that is a target of the handover.
[0008] Each aspect of the present disclosure may be realized by a computer, in which case a program that causes a computer to execute each step of the above method, and a computer-readable recording medium on which the program is recorded, also fall within the scope of the present disclosure.
[0009] 1 is a diagram illustrating a configuration of a general 5G mobile communication system. FIG. 2 is a block diagram illustrating an example of a functional configuration of the core network and base station device of FIG. 1. FIG. 3 is a block diagram illustrating an example of a functional configuration of the core network and base station device of a 5G mobile communication system according to an embodiment. FIG. 4 is a block diagram illustrating an example of a detailed configuration of a U-plane processing unit. FIG. 5 is a diagram illustrating processing related to Registration between a terminal, a base station, and a core network. FIG. 6 is another diagram illustrating processing related to Registration between a terminal, a base station, and a core network. FIG. 7 is yet another diagram illustrating processing related to Registration between a terminal, a base station, and a core network. FIG. 8 is a diagram illustrating processing related to PDU Session Establishment between a terminal, a base station, and a core network. FIG. 1 is a diagram explaining communication between a UE and a DN when a failure occurs in a transport network. FIG. 2 is a diagram explaining handover of a UE 200 performed between two RANs. FIG. 3 is an arrow chart explaining a sequence of Registration. FIG. 4 is an arrow chart explaining a sequence of PDU Session Establishment. FIG. 5 is an arrow chart explaining a sequence of Xn Handover. FIG. 6 is a diagram showing an example of the configuration of a computer that executes instructions of a program that is software that realizes each function.
[0010] With the spread of multi-access edge computing (MEC), terminals (UEs) are increasingly receiving application services from MEC servers. By using MEC, it is possible to reduce response delays of application services, for example.
[0011] Generally, each terminal in a mobile communication system communicates with an MEC server via a UPF, which is one of the network function units of a core network. Therefore, for example, if the UPF is located in a specific data center, the advantages of the MEC cannot be utilized. Therefore, in the future, it is highly likely that multiple UPFs will be located near base stations (RANs: Radio Access Networks).
[0012] On the other hand, current mobile communication systems are vulnerable to disconnection between the RAN and the core network due to a transport network failure, etc. For example, if communication on the C-plane (N2 interface, SCTP, etc.) between the RAN and the core network is cut off, the RAN stops the cell.
[0013] In such a situation, for example, if a failure occurs in the transport network connecting the RAN and a data center where servers corresponding to each network function unit of the core network are located, the terminals accommodated in the cells of the RAN will be unable to communicate. In such a case, for example, even if communication between the RAN and the UPF is possible, the UE will not be able to receive application services.
[0014] An object of one aspect of the present disclosure is to realize a technology that enables the provision of communication services that are highly resistant to failures in a transport network.
[0015] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. Fig. 1 is a diagram illustrating the configuration of a general 5G mobile communication system.
[0016] 1, there is shown a RAN 12a, which is a base station that performs wireless communication with a terminal (UE: User Equipment) 13 within a cell. Similar RANs 12b and 12c are also shown, and each base station is connected to a core network (CN) 11.
[0017] In addition, in the figure, routers are indicated by oval symbols. RAN 12a and RAN 12b are connected to Router #a, and are connected to the core network 11 via Router #b. RAN 12c is connected to the core network 11 via Router #c. The communication path connecting the base station and the core network 11 is called a backhaul or a transport network (TN).
[0018] (Functional Configuration of Core Network and Base Station Device) Fig. 2 is a block diagram showing an example of the functional configuration of the core network (CN) 11 and base station device (RAN) 12 in Fig. 1. Here, the configurations of RAN 12a, RAN 12b, and RAN 12c are collectively shown as the configuration of RAN 12.
[0019] In the example of FIG. 2 , the core network 11 includes a Subscriber DB (UDR: User Data Repository) 31 , a UPF (User Plane Function) 32 , and an AMF (Access and Mobility Management Function) 33 .
[0020] The UDR 31 is a functional block that mainly stores and reads subscriber data and session policies. The UPF 32 is a functional block that mainly performs session anchor, mobility anchor, packet forwarding, access control, etc. The AMF 33 is a functional block that mainly performs N2 interface termination, N1 interface termination, registration management, mobility management, etc.
[0021] In addition, the actual core network 11 includes other network function units such as a Session Management Function (SMF), a Unified Data Management (UDM), and a Policy Control Function (PCF) in addition to the UDR 31, the UPF 32, and the AMF 33. The illustration of the other network function units is omitted in Fig. 2 .
[0022] 2, the base station device 12 is configured to include a gNB CU (Central Unit) 61, a gNB DU (Distributed Unit) 62, and a gNB RU (Radio Unit) 63. Note that "gNB" refers to a gNodeB (base station) in a 5G mobile communication network. The gNB CU 61, gNB DU 62, and gNB RU 63 will be referred to as CU 61, DU 62, and RU 63, respectively, hereinafter, as appropriate.
[0023] The RU 63 is a functional block that controls the antenna and communicates with the terminal via radio waves, and also controls, for example, MIMO and beamforming. The DU 62 is a functional block that performs signal modulation and demodulation, MAC layer communication control, etc. The CU 61 is a functional block that controls the DU 62 and RU 63, connects to the core network, processes PDCP (Packet Data Convergence Protocol) that encrypts packets, and RRC (Radio Resource Control) that manages the terminal's radio resources.
[0024] Furthermore, in the example of FIG. 2, the AMF 33 includes an N2 processing unit 41, an N1 processing unit 42, a UE N1-MM / SM Context cache 43, an SCTP processing unit 44, and an SBI (Service Based Interface) 45.
[0025] The N2 processing unit 41 is a functional block that terminates the N2 interface, which is a connection interface between the RAN and the AMF, and controls or manages communication of the N2 interface (e.g., sending and receiving NGAP messages).
[0026] The N1 processing unit 42 is a functional block that controls or manages the termination of the N1 interface, which is an interface between the UE and the AMF, and communication of the N1 interface (for example, transmission and reception of NAS messages). The N1 processing unit 42 also performs processing related to the generation and update of Mobility Management Context, which is mobility management information transmitted and received as NAS messages, and Session Management Context, which is session management information.
[0027] The UE N1-MM / SM Context cache 43 is a cache memory that stores the Mobility Management Context and the Session Management Context that are transmitted and received as NAS messages.
[0028] The SCTP processing unit 44 is a functional block that terminates and manages an SCTP (Stream Control Transmission Protocol) session in communication between the core network 11 and the base station device 12 .
[0029] The SBI 45 is an interface for calling various network functions within the core network connected by the service-based architecture.
[0030] 2 , the CU 61 includes an SCTP processing unit 71 and a UPF 72. The SCTP processing unit 71 is a functional block that terminates and manages SCTP sessions in communications between the core network 11 and the base station device 12. The UPF 72 is a functional block that implements functions related to the UPF of the core network 11 in the base station device 12.
[0031] 2 , for example, the base station device 12 includes a UPF 72 in consideration of a case where a terminal receives application services provided on an MEC server. A terminal authenticated by the core network can then receive application services from an MEC server or the like located outside the core network 11 via the UPF 72 included in the CU 61 of the base station device 12, without going through the transport network. In this way, it is possible to provide communication services with lower latency than when going through the transport network.
[0032] The SCTP processing unit 71 includes an NGAP processing unit 81 and an Xn processing unit 82. The NGAP processing unit 81 is a functional block that performs processes such as generating, encrypting, and decrypting NGAP messages. The Xn processing unit is a functional block that controls or manages communications over the Xn interface, which is an interface that connects base station devices 12 to each other.
[0033] For example, if a fault occurs in the transport network, the SCTP session between the SCTP processing unit 44 and the SCTP processing unit 71 is disconnected, and it becomes impossible to send and receive NGAP messages between the N2 processing unit 41 and the NGAP processing unit 81. In this case, the base station device 12 stops transmitting radio waves related to its own cell, and the terminal 13 that had been accommodated in its own cell until then becomes disconnected from both the core network 11 and the base station device 12.
[0034] On the other hand, the CU 61 of the base station includes a UPF 72, and the terminal 13 that has already been authenticated by the core network 11 should then be able to receive application services from the MEC server or the like via the UPF 72 of the base station device 12, without going through the transport network. However, in reality, when a failure occurs in the transport network and the SCTP association is disconnected, the current base station software executes processing to cause the base station device 12 to stop transmitting radio waves related to its own cell, and therefore the terminal 13 will not be able to receive application services even if no failure occurs in the base station device 12 itself.
[0035] To avoid such a situation, it is not enough to simply avoid the suspension of radio wave transmission related to the cell; for example, it is necessary to continue communication normally even when a handover occurs.
[0036] That is, while conventional mobile communication networks aim to provide low-latency communication services by implementing UPF functions in base station devices, they have a problem of low tolerance to transport network failures.
[0037] First Embodiment FIG. 3 is a block diagram showing an example of the functional configuration of a core network (CN) 110 and a base station device (RAN) 120 in a 5G mobile communication system according to this embodiment.
[0038] (Functional Configuration of Core Network) The core network 110 shown in the figure includes a subscriber DB (UDR) 131. Network function units other than the UDR 131, such as a UPF and an AMF, may or may not be included in the core network 110.
[0039] (Functional configuration of RAN) The base station device 120 in Figure 3 is configured to include a gNB CU (Central Unit) 161, a gNB DU (Distributed Unit) 162, and a gNB RU (Radio Unit) 163. Note that the base station device 120 will be referred to as RAN 120 as appropriate hereinafter, and the gNB CU 161, gNB DU 162, and gNB RU 163 will be referred to as CU 161, DU 162, and RU 163, respectively, as appropriate hereinafter.
[0040] (CU (Central Unit)) The CU 161 is a functional block that controls the DU 162 and RU 163 (described later), connects to a core network, processes PDCP (Packet Data Convergence Protocol) that encrypts packets, and RRC (Radio Resource Control) that manages radio resources of terminals, etc. As an example, the functions of the CU 161 are realized by software such as a program executed by a computer.
[0041] In the example of FIG. 3, the CU 161 includes an SBI 171 , an MM / SM processing unit 172 , a C-plane processing unit 173 , a context holding unit 174 , an SCTP processing unit 175 , and a U-plane processing unit 180 .
[0042] As an example, SBI 171, MM / SM processing unit 172, C-plane processing unit 173, context holding unit 174, SCTP processing unit 175, and U-plane processing unit 180 may be configured as instances generated by calling a function in software that executes processing corresponding to the function of CU 161.
[0043] As will be described later, each functional block included in the CU 161 executes various processes corresponding to AMF, SMF, UPF, etc. That is, in this embodiment, the base station device 120 executes processes that are executed by a network function unit of a core network such as AMF, SMF, or UPF in a conventional 5G mobile communication system.
[0044] (SBI) The SBI 171 is a functional block similar to the SBI 45 in Fig. 2, and is an interface for receiving services from various network function units connected by the service-based architecture. In the example of Fig. 3, the SBI 171 is connected to the UDR 131 of the core network 110 by the service-based architecture.
[0045] (MM / SM Processing Unit) The MM / SM processing unit 172 is a functional block that executes processing similar to that executed by the N1 processing unit 42 in Fig. 2. That is, the MM / SM processing unit 172 controls or manages the termination of the N1 interface and communication over the N1 interface (e.g., sending and receiving NAS messages). The MM / SM processing unit 172 also executes processing related to the generation and updating of Mobility Management Context, which is mobility management information sent and received as NAS messages, and Session Management Context, which is session management information.
[0046] The MM / SM processing unit 172 performs processing performed by network function units such as AMF and SMF in conventional 5G mobile communication systems on behalf of the AMF, SMF, etc.
[0047] The MM / SM processing unit 172 may be an instance generated by calling a function to cause a computer to execute the above-described processing, or may be part of a calculation process executed in software that realizes the functions of the CU 161.
[0048] (C-plane processing unit) The C-plane processing unit 173 is a functional block that executes processing related to procedures such as UE Registration and PDU Session Establishment. As an example, the C-plane processing unit 173 executes processing such as decoding a Subscription Concealed Identifier (SUCI) when executing Registration and generating an Authentication Request message. In addition, the C-plane processing unit 173 executes processing such as decoding a PDU Session Establishment Request message and assigning an IP address when executing PDU Session Establishment.
[0049] The C-plane processing unit 173 performs processing performed by network function units such as UDM and PCF in conventional 5G mobile communication systems on behalf of the UDM, PCF, etc.
[0050] The C-plane processing unit 173 may be an instance generated by calling a function to cause a computer to execute the above-described processing, or may be part of a process executed in software that realizes the functions of the CU 161.
[0051] (Context Maintaining Unit) The context maintaining unit 174 is a functional block similar to the UE N1-MM / SM Context cache 43 in Fig. 2. That is, the context maintaining unit 174 is a cache memory that stores Mobility Management Context and Session Management Context that are transmitted and received as NAS messages.
[0052] (SCTP processing unit) The SCTP processing unit 175 is a functional block corresponding to the SCTP processing unit 71 in Fig. 2. The Xn processing unit 191 is a functional block that executes processing similar to that of the Xn processing unit 82 in Fig. 2. Unlike the SCTP processing unit 71 in Fig. 2, the SCTP processing unit 175 in Fig. 3 does not have a functional block corresponding to the NGAP processing unit 81. That is, in the 5G mobile communication system according to this embodiment, communication via the N2 interface, that is, communication between the RAN 120 and the AMF of the core network 110, is not required.
[0053] (U-plane processing unit) The U-plane processing unit 180 is a functional block that executes various processes related to communication of data related to UE application services, etc., and may be, for example, a functional block that executes the same processes as the UPF 72 in Fig. 2. The U-plane processing unit 180 may be an instance generated by calling a function that causes a computer to execute the same processes as the UPF 72 in Fig. 2. Alternatively, it may be part of a process executed in software that realizes the functions of the CU 161.
[0054] (DU (Distributed Unit) and RU (Radio Unit)) DU162 and RU163 are functional blocks similar to DU62 and RU63 in FIG. 2 . That is, RU163 is a functional block that controls antennas to communicate with terminals via radio waves, and also controls, for example, MIMO and beamforming. DU162 is a functional block that modulates and demodulates signals, controls MAC layer communications, and so on.
[0055] In the example of FIG. 3, only the UDR 131 is shown in the core network 110, but the core network 110 may include other network function units.
[0056] (Detailed Configuration of U-plane Processing Unit) Fig. 4 is a block diagram showing a detailed configuration example of the U-plane processing unit 180 in Fig. 3. In this example, the U-plane processing unit 180 includes a Session Anchor 181, a Mobility Anchor 182, a Packet Forward 183, and an Access Control 184.
[0057] The Session Anchor 181 and Mobility Anchor 182 are functional blocks that terminate PDU sessions. The Packet Forward 182 is a functional block that executes processing related to forwarding U-plane packets. The Access Control 184 is a functional block that performs control related to the session rule, which will be described later.
[0058] (Registration) Next, we will explain Registration in the 5G mobile communication system according to this embodiment. Figures 5 to 8 are diagrams explaining the processing related to Registration between a terminal, a base station, and a core network. Figures 5 to 8 show two base stations, RAN 120A (denoted as RAN #A in the figures) and RAN 120B (denoted as RAN #B in the figures). Both RAN #A and RAN #B are assumed to have the functional configuration described above with reference to Figure 3.
[0059] 5, a Registration Request message ("reg.req" in the figure) is transmitted to RAN 120A from UE 200 (denoted as UE #1 in the figure), which is a terminal connected to RAN 120A. CU 161A of RAN #A acquires a Subscription Concealed Identifier (SUCI) included in the Registration Request message.
[0060] In conventional 5G mobile communication systems, such processing was performed by the AMF, but in the 5G mobile communication system according to this embodiment, it is performed by the CU161A of the RAN120A.
[0061] 6, the CU 161A decrypts the SUCI ("decrypt SUCI" in the figure) and queries the UDR 131 to acquire subscriber information ("get subscriber info" in the figure). The CU 161A determines whether the user of the UE 200 is a registered subscriber based on the acquired subscriber information. If it is determined that the user is a registered subscriber, the CU 161A transmits an Authentication Request message ("auth req" in the figure) to the UE 200. At this time, a Mobility Management context (MM#1 in the figure) is held in a context holding unit (denoted as MM / SM Ctx in the figure) 174A of the CU 161A.
[0062] Note that a Mobility Management context is generated and stored for each UE that has transmitted a Registration Request message. In this embodiment, "#1" is used as a subscript to indicate that the context relates to UE #1. In this case, since the Registration Request message was transmitted from UE #1, MM #1 is stored in the context storage unit.
[0063] 7, UE 200 transmits an Authentication Response message ("auth res" in the figure) to RAN 120A. CU 161A, which has received the Authentication Response message, generates a key for encrypting a signal path used in communication with UE 200, and adds information about the key to MM#1.
[0064] CU 161A transmits a Security Mode Command message ("sec.mod.comm." in the figure) including information related to key generation to UE 200. UE 200 generates a key for encrypting the signal path based on the received Security Mode Command message, and transmits a Security Mode Complete message ("sec.mod.comp." in the figure) to CU 161A.
[0065] 8, the CU 161A of the RAN 120A updates the information stored in the UDR 131 of the core network 110. That is, the information indicating the status of the UE #1 stored in the UDR 131 is updated to indicate that authentication by the network has been completed ("registered" in the figure).
[0066] Then, CU 161A of RAN 120A transmits a Registration Accept message ("reg.accept" in the figure) to UE 200. UE 200, which has received the Registration Accept message, transmits a Registration Complete message ("reg.comp." in the figure) to RAN 120A. This completes the registration for UE #1.
[0067] In this way, RAN 120A is connected to the core network via a transport network, and has a Service Based Interface (SBI) 171 in a Central Unit (CU) 161. When RAN 120A receives a Registration Request message from UE 200, it receives a service from a User Data Repository (UDR) 131 of the core network 110 via the SBI 171, and a context holding unit 174 stores the MM context of UE 200.
[0068] (PDU Session Establishment) Next, PDU Session Establishment in the 5G mobile communication system according to this embodiment will be described. Figures 9 and 10 are diagrams illustrating processing related to PDU Session Establishment between a terminal, a base station, and a core network. Figures 9 and 10 show two base stations, RAN 120A and RAN 120B.
[0069] 9, a PDU Session Establishment Request message ("PDU sess.estab.req" in the figure) is transmitted from UE 200, for which registration has been completed, to RAN 120A. The PDU Session Establishment Request message includes an MM / SM message, and CU 161A of RAN #A references the SM (Session Management) message in the MM / SM message to obtain the session policy of UE #1 from UDR 131 ("get session policy" in the figure).
[0070] In conventional 5G mobile communication systems, such processing was performed by the SMF, but in the 5G mobile communication system according to this embodiment, it is performed by CU161A of RAN120A.
[0071] CU161A, which has acquired the session policy of UE#1, generates a session rule for UE#1 based on the session policy using the U-plane processing unit ("insert sess.rule" in the figure). As a result, U-plane data for UE#1 is transmitted based on this session rule. At this time, the Session Management context (SM#1 in the figure) is held in the context holding unit of CU161A, and a PDU session (e.g., PDU#001) for UE#1 is established.
[0072] In this way, when the RAN 120A receives a PDU session establishment request message from the UE 200, the RAN 120A receives a service from the UDR of the core network via the SBI 171, and the context maintaining unit 174 stores the SM context of the UE 200.
[0073] After this, the UE 200 can transmit and receive data to and from a DN (Data Network) by using PDU#001, as shown in Fig. 10. That is, the UE 200 can receive application services from a server on the DN.
[0074] As described above, the CU 161A of the RAN 120A includes the U-plane processing unit 180 described above with reference to Figures 3 and 4, so the UE 200 can transmit and receive data to and from the DN without going through the core network 110. It is assumed that the RAN 120A is connected to an MEC server, Internet exchange, a satellite communication system, etc. In other words, the RAN 120A having the U-plane processing unit 180 is connected to a connection interface with the DN.
[0075] In this way, CU161A executes processing corresponding to processing executed by UPF (User Plane Function), which is a network function part of the core network, and RAN120A is connected to a connection interface with DN (Data Network).
[0076] As a result, for example, as shown in Figure 11, even if a failure occurs in the transport network, UE200 can continue to transmit and receive data with the DN. In the example of Figure 11, the symbol "X" in the figure indicates that a failure has occurred in the transport network connecting RAN120A and RAN120B. As such, in the 5G mobile communication system according to this embodiment, even if communication between the RAN and the core network is disconnected due to a failure in the transport network, a UE that has already completed registration can continue to receive application services.
[0077] (Handover) Next, a handover in the 5G mobile communication system according to this embodiment will be described. Fig. 12 is a diagram illustrating a handover of the UE 200 performed between the RAN 120A and the RAN 120B.
[0078] As shown in the figure, it is assumed that UE200 moves and the connection destination of UE200 is switched from RAN#A to RAN#B. In this case, Xn handover is performed between RAN#A and RAN#B. Note that RAN#A, which is the base station device from which the switch is made, is called the source base station device, and RAN#B, which is the base station device to which the switch is made, is called the target base station device.
[0079] As described above, in the 5G mobile communication system according to this embodiment, a context holding unit is provided in the CU of the base station device. In this case, the Mobility Management context (MM#1) and Session Management context (SM#1) of UE#1 are held in the context holding unit 174A of the CU 161A of the RAN 120A.
[0080] For this reason, when UE #1 performs an Xn handover from RAN #A to RAN #B, MM #1 and SM #1 must be transmitted from RAN #A to RAN #B. MM #1 and SM #1 are transmitted and received between RAN #A and RAN #B using the Xn interface. That is, contexts such as MM #1 and SM #1 are transmitted and received between RAN 120A and RAN 120B without going through the core network 110.
[0081] Since RAN 120B has the same configuration as RAN 120A, the context transmitted from RAN 120A is held in context holding unit 174B of CU 161B of RAN 120B. MM#1 and SM#1, which are the contexts of UE#1 held in context holding unit 174A of RAN 120A, are invalidated (denoted as expired in the figure).
[0082] RAN#B continues to use PDU#0001, which is the PDU session established for UE#1, to provide a communication path between UE#1 and the DN. That is, based on SM#1 transmitted from RAN#A, data related to UE#1's U-Plane communication is transmitted using PDU#0001, and the data is transmitted based on the session rule.
[0083] In this way, the base station device 120A according to this embodiment stores an MM (Mobility Management) context and an SM (Session Management) context for each terminal connected to the base station device 120, and when it detects a handover of a terminal (e.g., UE200), it transfers the MM context and SM context of the UE200 to the base station device 120B, which is the target of the handover.
[0084] This allows handover to be performed even when a failure occurs in the transport network, as shown in Fig. 12. In the example of Fig. 12, the symbol "X" in the figure indicates that a failure has occurred in the transport network connecting RAN 120A and RAN 120B to the core network 110. Furthermore, UE 200 can continue to transmit and receive data to and from the DN at the target base station (RAN #B).
[0085] In this way, in the 5G mobile communication system according to this embodiment, even if communication between the RAN and the core network is interrupted due to a failure in the transport network, a UE that has already completed registration can continue to receive application services. In this case, even if a handover occurs due to the movement of the UE, the UE can continue to receive application services.
[0086] (Registration Sequence) Next, a registration sequence, which is one of the system procedures executed in the 5G mobile communication system according to this embodiment, will be described. Fig. 13 is an arrow chart illustrating the registration sequence.
[0087] In this arrow chart, the entities that execute each step are shown as UE 200 (UE #1), CU 161A, CN-C 170A, context maintaining unit 174A, and UDR 131. CU 161A, CN-C 170A, and context maintaining unit 174A are included in RAN 120A. CN-C 170A is an entity corresponding to MM / SM processing unit 172 and C-plane processing unit 173 described above with reference to FIG. 3, and may be, for example, an instance generated by CU 161A calling a predetermined function.
[0088] In practice, various messages transmitted from UE 200 are acquired by CU 161A via DU 162A of RAN 120A. Similarly, various messages transmitted from CU 161A to RAN 120A are transmitted via DU 162A. Here, for simplicity of explanation, description of the processing executed by DU 162 is omitted.
[0089] In the figure, first, a system procedure called RRCSetup is executed between UE 200 and RAN 120A. After that, Registration actually starts ("begin Registration").
[0090] In step S111, UE 200 transmits a Registration Request message to RAN 120A, which is received by CU 161A of RAN 120A in step S131.
[0091] In step S132, the CU 161A calls a function for executing various processes related to the MM / SM processing unit 172 and the C-plane processing unit 173. Here, the function is called (func.call) with SUCI#1 as an argument, and in step S161, for example, CN-C 170A is generated as an instance corresponding to the MM / SM processing unit 172 and the C-plane processing unit 173.
[0092] In step S162, the CN-C 170A executes the HTTP method "GET Subsc.Info of UE#1." This causes the UDR 131 to search for subscriber information for UE#1 in step S191.
[0093] In step S192, UDR 131 provides the subscriber information (Sub#1) of UE#1 to CN-C 170, which is acquired by CN-C 170A in step S163.
[0094] In step S164, the CN-C 170A executes "Store UE#1 context" using the protocol specified by the context maintaining unit 174A. As a result, in step S181, the Mobility Management context of UE#1 is maintained in the context maintaining unit 174A.
[0095] In step S165, CN-C 170A generates an "Authentication Request" as a return value for the function call in step S132, and in step S133, this is acquired by CU 161A.
[0096] In step S134, CU 161A transmits an Authentication Request message to UE 200, which is received by UE 200 in step S112.
[0097] In step S113, UE 200 transmits an Authentication Response message to RAN 120A, which is received by CU 161A in step S135.
[0098] In step S136, CU 161A calls a function for executing various processes related to MM / SM processing unit 172 and C-plane processing unit 173. Here, a function call (func.call) is executed with AMF-UE-NGAP-ID#1 as an argument, and in step S166, for example, CN-C 170A is generated as an instance corresponding to MM / SM processing unit 172 and C-plane processing unit 173. Then, a system procedure called Authentication is executed, and UE#1 is authenticated.
[0099] In step S167, CN-C 170A generates a "Security mode command" as a return value for the function call in step S136, and in step S137, this is acquired by CU 161A.
[0100] In step S138, CU 161A transmits a Security mode command message to UE 200, which is received by UE 200 in step S114.
[0101] In step S115, UE 200 transmits a Security mode complete message to RAN 120A, which is received by CU 161A in step S139.
[0102] In step S140, the CU 161A calls a function for executing various processes related to the MM / SM processing unit 172 and the C-plane processing unit 173. Here, the function call (func.call) is executed with the AMF-UE-NGAP-ID#1 as an argument, and in step S168, for example, CN-C 170A is generated as an instance corresponding to the MM / SM processing unit 172 and the C-plane processing unit 173.
[0103] In step S182, the context maintaining unit 174A executes "Load UE#1 context" using the specified protocol, which causes the context related to UE#1 held by the context maintaining unit 174A to be read by the CN-C 170A in step S169.
[0104] In step S170, the CN-C 170A executes a handle registration request process, thereby obtaining the location information of the UE#.
[0105] In step S171, the CN-C 170A executes "Update the state of UE#1" using the protocol specified by the context maintaining unit 174A. As a result, the subscriber information of UE#1 is updated in the UDR 131 in step S193.
[0106] Furthermore, in step S172, the CN-C 170A executes "Store UE#1 context" using the protocol specified by the context maintaining unit 174A. As a result, the Mobility Management context of UE#1 updated in step S183 is maintained by the context maintaining unit 174A.
[0107] In step S173, CN-C 170A generates "Registration Accept" as a return value for the function call in step S140, and in step S141, this is acquired by CU 161A.
[0108] In step S142, CU 161A transmits a Registration Accept message to UE 200, which is received by UE 200 in step S116.
[0109] In step S117, UE 200 transmits a Registration complete message to RAN 120A, which is received by CU 161A in step S143.
[0110] In step S144, the CU 161A calls a function for executing various processes related to the MM / SM processing unit 172 and the C-plane processing unit 173. Here, the function call (func.call) is executed with the AMF-UE-NGAP-ID#1 as an argument, and in step S174, for example, CN-C 170A is generated as an instance corresponding to the MM / SM processing unit 172 and the C-plane processing unit 173.
[0111] In step S175, the CN-C 170A executes a handle registration complete process, which stops a predetermined timer used when registering UE #1, for example.
[0112] In step S176, the CN-C 170A generates a return value for the function call in step S144, and in step S145, this is acquired by the CU 161A. In this case, for example, the return value may be Null.
[0113] Then, the registration is ended ("end Registration").
[0114] In the 5G mobile communication system according to this embodiment, registration as a system procedure is executed in this manner.
[0115] (Sequence of PDU Session Establishment) Next, a sequence of PDU Session Establishment, which is one of the system procedures executed in the 5G mobile communication system according to this embodiment, will be described. Fig. 14 is an arrow chart illustrating the sequence of PDU Session Establishment.
[0116] In this arrow chart, entities that execute each step are shown as UE 200 (UE #1), CU 161A, CN-C 170A, context maintaining unit 174A, U-Plane processing unit 180A, and UDR 131. CU 161A, CN-C 170A, context maintaining unit 174A, and U-Plane processing unit 180A are included in RAN 120A.
[0117] The CN-C 170A is an entity corresponding to the MM / SM processing unit 172 and the C-plane processing unit 173 described above with reference to Fig. 3, and may be, for example, an instance generated by the CU 161A calling a predetermined function. The U-Plane processing unit 180A is an entity corresponding to the U-Plane processing unit 180 described above with reference to Fig. 3, and may be, for example, an instance generated by the CU 161A calling a predetermined function.
[0118] In practice, various messages transmitted from UE 200 are acquired by CU 161A via DU 162A of RAN 120A. Similarly, various messages transmitted from CU 161A to RAN 120A are transmitted via DU 162A. Here, for simplicity of explanation, description of the processing executed by DU 162 is omitted.
[0119] Prior to the execution of PDU Session Establishment, the Registration described above with reference to Fig. 13 is executed. After the Registration is completed, a system procedure called PFCP (Packet Forwarding Control Protocol) Association Setup is executed, and after the PFCP Association Setup is completed, the process of step S201 is executed.
[0120] In step S201, the UE 200 executes a Gen. PDU Session ID process, thereby generating an ID (e.g., ID #1) of the PDU Session used by the UE 200 itself.
[0121] In step S202, UE 200 transmits a PDU session establishment request message to RAN 120A, which is received by CU 161A of RAN 120A in step S221.
[0122] In step S222, the CU 161A calls a function for executing various processes related to the MM / SM processing unit 172 and the C-plane processing unit 173. Here, the function call (func.call) is executed with the AMF-UE-NGAP-ID#1 as an argument, and in step S241, for example, CN-C 170A is generated as an instance corresponding to the MM / SM processing unit 172 and the C-plane processing unit 173.
[0123] In step S271, the context maintaining unit 174A executes "Load UE#1 context" using a specified protocol. As a result, in step S242, the context related to UE#1 maintained by the context maintaining unit 174A is read by the CN-C 170A.
[0124] In step S243, the CN-C 170A executes a handle PDU session establishment request process. In this process, the CN-C 170A acquires the session policy of UE #1 from the UDR 131. This determines whether or not an uplink PDU session can be established. Here, it is assumed that it is determined that an uplink PDU session can be established.
[0125] Thereafter, a system procedure called PFCP session establishment is executed, whereby an uplink session rule is inserted into the U-Plane processing unit 180A of the CU 161A.
[0126] In step S244, CN-C 170A executes "Store UE#1 context" using the protocol specified by the context maintaining unit 174A. As a result, in step S181, the Session Management context (SM#1) of UE#1 is maintained by the context maintaining unit 174A.
[0127] In step S245, CN-C 170A generates "PDU session establishment accept" as a return value for the function call in step S222, and in step S223, this is acquired by CU 161A.
[0128] In step S224, the CU 161A transmits a PDU session establishment accept message to the UE 200, which is received by the UE 200 in step S203.
[0129] In step S204, UE 200 transmits First Uplink Data to U-plane processing unit 180A, which is received by U-plane processing unit 180A in step S291.
[0130] In step S225, the CU 161A calls a function for executing various processes related to the MM / SM processing unit 172 and the C-plane processing unit 173. Here, the function call (func.call) is executed with the AMF-UE-NGAP-ID#1 as an argument, and in step S246, for example, CN-C 170A is generated as an instance corresponding to the MM / SM processing unit 172 and the C-plane processing unit 173.
[0131] In step S273, the context maintaining unit 174A executes "Load UE#1 context" using the specified protocol, thereby causing the context related to UE#1 held by the context maintaining unit 174A to be read by the CN-C 170A.
[0132] In step S248, the CN-C 170A executes a handle PDU session resource setup request process. This determines whether a downlink PDU session can be established. Here, it is assumed that it is determined that a downlink PDU session can be established.
[0133] Thereafter, a system procedure called PFCP session modification is executed, whereby a Downlink session rule is inserted into the U-Plane processing unit 180A of the CU 161A.
[0134] In step S249, CN-C 170A executes "Store UE #1 context" using the protocol specified by the context maintaining unit 174 A. As a result, in step S274, the Session Management context of UE #1 updated in conjunction with the execution of PFCP session modification is maintained by the context maintaining unit 174 A.
[0135] In step S250, CN-C 170A generates a "PDU session resource setup response" as a return value for the function call in step S225, and in step S226, this is acquired by CU 161A.
[0136] In step S292, U-plane processing unit 180A transmits First Downlink Data to UE 200, which is received by UE 200 in step S205.
[0137] In the 5G mobile communication system according to this embodiment, PDU Session Establishment as a system procedure is executed in this manner.
[0138] (Handover Sequence) Next, a description will be given of an Xn Handover sequence, which is a process related to base station switching executed in the 5G mobile communication system according to this embodiment. Fig. 15 is an arrow chart illustrating the Xn Handover sequence.
[0139] In this arrow chart, the entities that execute each step are shown as UE 200 (UE #1), CU 161A, U-Plane processing unit 180A, CU 161B, CN-C 170B, context maintaining unit 174B, and U-Plane processing unit 180B. CU 161A and U-Plane processing unit 180A are included in RAN 120A. CU 161B, CN-C 170B, context maintaining unit 174B, and U-Plane processing unit 180B are included in RAN 120B.
[0140] CN-C170B is an entity corresponding to the MM / SM processing unit 172 and C-plane processing unit 173 described above with reference to Fig. 3, and may be, for example, an instance generated by CU161B calling a predetermined function. Also, U-Plane processing unit 180A and U-Plane processing unit 180B are entities corresponding to the U-Plane processing unit 180 described above with reference to Fig. 3, and may be, for example, an instance generated by CU161A and CU161B calling a predetermined function.
[0141] In practice, various messages transmitted from UE 200 are acquired by CU 161A via DU 162A of RAN 120A. Similarly, various messages transmitted from CU 161A to RAN 120A are actually transmitted via DU 162A. Here, for simplicity of explanation, description of the processing executed by DU 162A is omitted.
[0142] When it is detected that the base station to which UE 200 is connected has switched from RAN 120A to RAN 120B, a system procedure called Handover preparation is executed between RAN 120A and RAN 120B. After that, Xn Handover actually starts ("begin Xn Handover").
[0143] In step S331, the CU 161A transmits an RRC Reconfiguration message to the UE 200, which is received by the UE 200 in step S301.
[0144] In step S312, the control unit 161A executes a buffer downlink data process, thereby buffering data (downlink data) to be transmitted to UE #1 from the DN with which UE #1 is currently communicating.
[0145] In step S313, CU 161A transmits the SN (Serial Number) to RAN 120B (SN status Transfer in the figure), which is received by CU 161B of RAN 120B in step S331.
[0146] In step S314, the CU 161A transfers the context of UE #1 stored in the context storage unit 174A, i.e., the Session Management context and the Mobility Management context, to the CU 161B, which then acquires the context in step S331. At this time, the transfer of the context of UE #1 may be performed using the Xn interface, or may be performed using another method. As an example, the transfer of the context of UE #1 may be performed using gRPC (Remote Procedure Calls).
[0147] In step S333, the control unit 161B executes an Associate UE context process, thereby associating the SN status received in step S331 with the context of UE #1 acquired in step S332.
[0148] In step S334, the CU 161B calls a function for executing various processes related to the MM / SM processing unit 172 and the C-plane processing unit 173. Here, the function is called (func.call) with the CP UE Context Handover as an argument, and in step S361, for example, a CN-C 170B is generated as an instance corresponding to the MM / SM processing unit 172 and the C-plane processing unit 173.
[0149] In step S362, the CN-C 170B executes "Restore UE context of source CN-C" using the protocol specified by the context maintaining unit 174B. As a result, in step S381, the context of UE #1 is maintained by the context maintaining unit 174B.
[0150] In step S363, CN-C 170B generates a "CP UE Context Handover response" as a return value for the function call in step S334, and in step S335, this is acquired by CU 161B.
[0151] In step S336, the CU 161B calls a function for executing various processes related to the MM / SM processing unit 172 and the C-plane processing unit 173. Here, the function is called (func.call) with the UP UE Context Handover as an argument, and in step S391, for example, the U-Plane processing unit 180B is generated as an instance.
[0152] In step S392, the U-Plane processing unit 180B executes an Insert session rule process, whereby the Downlink session rule is inserted into the U-Plane processing unit 180B of the CU 161B.
[0153] In step S393, the U-Plane processing unit 180B generates a "UP UE Context Handover response" as a return value for the function call in step S336, and in step S337, this is acquired by the CU 161B.
[0154] In step S338, CU 161B transmits a UE Context Handover response message to RAN 120A, which is received by CU 161A of RAN 120A in step S315.
[0155] In step S316, CU 161A transmits the Downlink data buffered by the processing in step S312 to RAN 120B, and in step S339, this is received by CU 161B of RAN 120B.
[0156] In steps S302 and S340, the Random Access Procedure is executed by UE 200 and CU 161B of RAN 120B.
[0157] Then, Xn Handover is ended ("end Xn Handover").
[0158] In the 5G mobile communication system according to this embodiment, Xn Handover is executed in this manner.
[0159] (Effects of the first embodiment) As described above, according to this embodiment, the RAN 120 includes the U-plane processing unit 180, so that the UE 200 can transmit and receive data with the DN without going through the core network 110.
[0160] In this embodiment, at the time of registration, other than communication with the UDR 131 for acquiring and updating subscriber information, there is no need for communication between the RAN 120 and the core network 110. Furthermore, the process related to PDU Session Establishment does not require communication between the RAN 120 and the core network 110 other than communication with the UDR 131 for acquiring the session policy.
[0161] Therefore, according to the present embodiment, even if communication between the RAN and the core network is interrupted due to a failure in the transport network, the UE that has already completed registration can continue to receive application services. Therefore, for example, the advantages of MEC can be fully utilized.
[0162] Furthermore, according to this embodiment, all processes related to Xn handover are also executed by the RAN 120. Therefore, according to this embodiment, even if communication between the RAN and the core network is cut off due to a failure in the transport network, the UE can move freely.
[0163] Furthermore, in this embodiment, as described above, there is no need for communication via the N2 interface, i.e., communication between the RAN 120 and the AMF of the core network 110. Therefore, for example, when a failure occurs in the transport network and many UEs simultaneously resume communication, it is possible to avoid an increase in the processing load of the core network due to the concentration of communication via the N2 interface to the AMF of the core network. In other words, it is possible to suppress the occurrence of congestion caused by an increase in the processing load of the core network due to the occurrence of a failure in the transport network, which has been a conventional problem.
[0164] As described above, according to this embodiment, it is possible to realize a technology that enables the provision of communication services that are highly resistant to faults in the transport network.
[0165] Second Embodiment As described above, in the RAN 120, processes that are executed by network function units of a core network, such as AMF, SMF, and UPF, in conventional 5G mobile communication systems can be executed by the CU 161. This makes it possible to flexibly determine the division of functions between the base station device and the core network.
[0166] That is, in the first embodiment described above, among the network function units of the core network 110, only the UDR 131 is configured to be called from the RAN 120 via the SBI 171, but other network function units may also be configured to be called from the RAN 120 via the SBI 171.
[0167] For example, among the network function units of the core network 110, in addition to the UDR 131, a UDM (Unified Data Management) may be called from the RAN 120 via the SBI 171. Also, for example, all of the processes executed by the network function units of the core network other than the UDR may be executed by the CU 161.
[0168] Alternatively, for example, a network function unit that processes highly confidential information, such as a user's personal information, may be placed in the core network 110 and called from the RAN 120 via the SBI 171, and processing related to other network function units may be performed by the CU 161.
[0169] Alternatively, the UPF may be provided separately from the RAN 120. For example, a server or the like used as the UPF may be placed in a station building where the RAN 120 is placed, and the RAN 120 and the UPF may be connected by a LAN or the like. In this case, the CU 161 of the RAN 120 may not include the U-Plane processing unit 180.
[0170] <Example of Software Implementation> The above-described base station device 120 can be realized by a program for causing a computer to function, and by a program for causing a computer to function as the base station device 120. In this case, the base station device 120 includes a computer having at least one control device (e.g., a processor) and at least one storage device (e.g., a memory) as hardware for executing the program. An example of such a computer is shown in FIG. 16 .
[0171] The computer 500 includes at least one processor 501 and at least one memory 502. The memory 502 stores a program 520 for causing the computer 500 to operate as the base station device 120. In the computer 500, the processor 501 reads and executes the program 520 from the memory 502, thereby realizing each function of the base station device 120.
[0172] The processor 501 may be, for example, a CPU (Central Processing Unit), a GPU (Graphic Processing Unit), a DSP (Digital Signal Processor), an MPU (Micro Processing Unit), an FPU (Floating point number Processing Unit), a PPU (Physics Processing Unit), a microcontroller, or a combination of these.
[0173] The memory 502 may be, for example, a flash memory, a hard disk drive (HDD), a solid state drive (SSD), or a combination of these.
[0174] The computer 500 may further include a RAM (Random Access Memory) for expanding the program 520 during execution and for temporarily storing various data. The computer 500 may also include a communication interface for transmitting and receiving data to and from other devices. The computer 500 may also include an input / output interface for connecting input / output devices such as a keyboard, a mouse, a display, and a printer.
[0175] Furthermore, the program 520 for causing the computer 500 to operate as the base station device 120 can be recorded on a non-transitory, tangible recording medium 530 that can be read by the computer 500. Such a recording medium 530 can be, for example, a tape, a disk, a card, a semiconductor memory, or a programmable logic circuit. The computer 500 can acquire the program 520 via such a recording medium 530.
[0176] Furthermore, the program 520 for causing the computer 500 to operate as the base station device 120 can be transmitted via a transmission medium. Such a transmission medium can be, for example, a communication network or broadcast waves. The computer 500 can also acquire the program 520 via such a transmission medium.
[0177] In addition, some or all of the functions of the base station device 120 can be realized by logic circuits. For example, an integrated circuit in which a logic circuit that functions as each of the above control blocks is formed is also included in the scope of the present disclosure. In addition, the functions of each of the above control blocks can also be realized by, for example, a quantum computer.
[0178] Furthermore, in each of the above-described embodiments, examples of applying the present disclosure to a 5G communication system have been described, but the present disclosure can also be applied to communication systems from 6G onwards, as long as the communication system can be configured in NF units.
[0179] According to each aspect of the present disclosure described above, the above-mentioned effects can be achieved, thereby contributing to the achievement of Goal 9 of the Sustainable Development Goals (SDGs), "Build resilient infrastructure for inclusive and sustainable industrialization and innovation."
[0180] The present disclosure is not limited to the above-described embodiments, and various modifications are possible within the scope of the claims. Embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present disclosure.
[0181] [Summary] A base station device according to aspect 1 of the present disclosure is a base station device of a mobile communication network, and includes: a context maintaining unit that stores an MM (Mobility Management) context and an SM (Session Management) context for each terminal connected to the base station device; and a context transferring unit that, when a handover of the terminal is detected, transfers the MM context and SM context of the terminal to a base station device that is a target of the handover.
[0182] In the base station device according to aspect 2 of the present disclosure, in the above aspect 1, when the terminal requests the start of a system procedure, the CU (Central Unit) of the base station device executes processing corresponding to the processing executed by the network function unit of the core network by calling a function to cause a computer to execute the processing required in the system procedure.
[0183] A base station device according to aspect 3 of the present disclosure is the same as that of aspect 2 above, except that the CU of the base station device executes processing corresponding to processing executed by a UPF (User Plane Function), which is a network function unit of a core network, and the base station device is connected to a connection interface with a DN (Data Network).
[0184] A base station device according to aspect 4 of the present disclosure is, in the above-described aspect 2 or 3, connected to a core network via a transport network, has a service-based interface (SBI) in the CU, and when a registration request message is received from the terminal, receives a service from a user data repository (UDR) of the core network via the SBI, and the context maintenance unit stores the MM context of the terminal.
[0185] In the base station device according to aspect 5 of the present disclosure, when a PDU session establishment request message is received from the terminal in the above-described aspect 4, a service is provided from a UDR of a core network via the SBI, and the context maintaining unit stores an SM context of the terminal.
[0186] A base station device according to a sixth aspect of the present disclosure is the base station device of any one of the first to fourth aspects above, wherein the handover is an Xn handover.
[0187] A base station device according to aspect 7 of the present disclosure is the same as aspect 6 above, in which the context transfer unit uses gRPC to transfer the MM context and SM context of the terminal to the base station device that is the target of the handover.
[0188] A base station device switching method according to aspect 8 of the present disclosure is a base station device switching method for a mobile communication network, which stores an MM (Mobility Management) context and an SM (Session Management) context for each terminal connected to a base station device, and, when a handover of the terminal is detected, transfers the MM context and SM context of the terminal to a base station device that is a target of the handover.
[0189] A program according to a ninth aspect of the present disclosure causes a computer to function as a base station device of a mobile communication network, the base station device including: a context maintaining unit that stores an MM (Mobility Management) context and an SM (Session Management) context for each terminal connected to the base station device; and a context transferring unit that, when a handover of the terminal is detected, transfers the MM context and the SM context of the terminal to a base station device that is a target of the handover.
[0190] REFERENCE SIGNS LIST 110 Core network 120 Base station device 131 UDR 161 CU 162 DU 163 RU 170 CN-C 171 SBI 172 MM / SM processing unit 173 C-Plane processing unit 174 Context holding unit 175 SCTP processing unit 180 U-Plane processing unit 181 Session Anchor 182 Mobility Anchor 183 Packet Forward 184 Access Control
Claims
1. A base station device of a mobile communication network comprising: a context holding unit that stores an MM (Mobility Management) context and an SM (Session Management) context for each terminal connected to the base station device; and a context transfer unit that, when a handover of the terminal is detected, transfers the MM context and SM context of the terminal to a base station device that is a target of the handover.
2. The base station device according to claim 1, wherein, when the start of a system procedure is requested from the terminal, a CU (Central Unit) of the base station device executes processing corresponding to processing executed by a network function unit of a core network by calling a function for causing a computer to execute processing required in the system procedure.
3. The base station device according to claim 2, wherein the CU of the base station device executes processing corresponding to processing executed by a UPF (User Plane Function), which is a network function unit of a core network, and the base station device is connected to a connection interface with a DN (Data Network).
4. The base station device according to claim 2 or 3, which is connected to a core network via a transport network, has a service based interface (SBI) in the CU, and when a registration request message is received from the terminal, receives a service from a user data repository (UDR) of the core network via the SBI, and the context holding unit stores an MM context of the terminal.
5. The base station apparatus according to claim 4, wherein, when a PDU session establishment request message is received from the terminal, a service is provided from a UDR of a core network via the SBI, and the context maintaining unit stores an SM context of the terminal.
6. The base station device according to any one of claims 1 to 4, wherein the handover is an Xn handover.
7. The base station device according to claim 6, wherein the context transfer unit transfers the MM context and SM context of the terminal to a base station device that is a target of handover, using gRPC.
8. A base station switching method for a mobile communications network, comprising: storing an MM (Mobility Management) context and an SM (Session Management) context for each terminal connected to the base station; and, upon detecting a handover of the terminal, transferring the MM context and SM context of the terminal to a base station that is the target of the handover.
9. A program that causes a computer to function as a base station device of a mobile communications network, the base station device having: a context holding unit that stores an MM (Mobility Management) context and an SM (Session Management) context for each terminal connected to the base station device; and a context transfer unit that, when a handover of the terminal is detected, transfers the MM context and SM context of the terminal to a base station device that is the target of the handover.
Citation Information
Patent Citations
Information processing device, information processing method, and program
JP2022051973A
Association management method and network node
EP3570491A1
Paging area identification method, access network node and core network node
JP2019535219A
EPS bearer ID allocation method, device, SMF and PCF
JP2020511887A
Handover method, mobility management network element, and communications system
US20200245218A1