Automatic upgrades and fallback across multiple operating system instances

Abstract

Generally, the present subject matter relates to automatic upgrade and fallback across multiple operating system ("OS") instances. In some implementations, automatic upgrade and fallback across multiple OS instances may include attempting to boot the OS from a first basic input / output system (BIOS) pre-stored in a first partition of the memory of a communication device within a wireless communication system. The OS may be operable on the communication device in response to the OS successfully booting from the first BIOS, and the method may further include automatically attempting to boot the OS from a second BIOS pre-stored in a second partition of the memory of the communication device in response to the OS not successfully booting from the first BIOS.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority to Indian Patent Application No. 202241055504, filed on September 28, 2022, entitled "Automated Upgrade and Fallback Across Multiple Operating System Instances", the disclosure of which is incorporated herein by reference in its entirety.

[0002] In some implementations, the subject matter relates to a telecommunications system, and more particularly, to automated upgrade and fallback across multiple operating system ("OS") instances, such as for communication devices within a wireless communication system.

Background Art

[0003] In today's world, cellular networks provide on - demand communication capabilities to individuals and enterprises. Typically, a cellular network is a wireless network that can be distributed over a terrestrial area, called a cell. Each such cell is served by at least one fixed - location transceiver, called a cell site or base station. Each cell can use a different set of frequencies from its neighboring cells to avoid interference and provide improved service within each cell. When multiple cells are combined together, they provide wireless coverage over a wide geographical area, thereby enabling a large number of mobile phones, and / or other wireless devices or portable transceivers to communicate with each other, as well as with some fixed transceiver and telephone somewhere in the network. Such communication is carried out via the base station and is achieved even when the mobile transceiver is moving through two or more cells during transmission. Major wireless communication providers have deployed such cell sites worldwide, thereby enabling communication mobile phones and mobile computing devices to connect to the public switched telephone network and the public Internet.

[0004] A mobile phone is a cell phone that can receive and / or transmit phone and / or data communications via a cell site or transmitting tower by using radio waves to transfer signals to and from other mobile phones. Given the large number of mobile phone users, the current mobile phone network provides limited shared resources. In this regard, cell sites and handsets can change frequencies and use low-power transmitters to enable simultaneous use of the network by many callers with less interference. Cell site coverage can depend on a particular geographical location and / or the number of users who can potentially use the network. For example, in urban areas, a cell site may have a range of up to about half a mile, in rural areas the range may be as much as 5 miles, and in some areas users can receive signals from cell sites 25 miles away.

[0005] The following are some examples of digital cellular technologies used by telecommunications providers, namely, Global System for Mobile Communications ("GSM"), General-Purpose Packet Radio Service ("GPRS"), cdmaOne, CDMA2000, Advanced Data Optimization ("EV-DO"), GSM Advanced High-Speed ​​Data Rate ("EDGE"), Universal Mobile Communications System ("UMTS"), Digital Enhanced Cordless Communications ("DECT"), Digital AMPS ("IS-136 / TDMA"), and Integrated Digital Enhanced Network ("iDEN"). Long-Term Evolution, or 4G LTE, developed by the Third Generation Partnership Project ("3GPP®") standards body, is a standard for high-speed wireless data communication for mobile phones and data terminals. Currently, 5G standards are being developed and deployed. 3GPP cellular technologies such as LTE and 5G NR are advancements of earlier 3GPP technologies such as GSM / EDGE and UMTS / HSPA digital cellular technologies, enabling increased capacity and speed through improvements to the core network and the use of different radio interfaces.

[0006] A cellular network can be divided into a radio access network and a core network. The radio access network (RAN) may include network functions capable of handling radio layer communication processing. The core network may include network functions capable of handling higher layer communications, such as Internet Protocol (IP), the transport layer, and the application layer. In some cases, the RAN functions may be divided into baseband unit functions and radio unit functions, for example, radio units connected to baseband units via a fronthole network may be responsible for lower layer processing of the radio physical layer, while the baseband units may be responsible for higher layer radio protocols, such as MAC and RLC.

[0007] Computer systems in a cell, such as base stations and / or base station components, run an operating system ("OS") to manage their operation, including the management of their hardware components and software resources. The OS can be installed on the computer system initially used when the hardware is deployed to the cell. However, at some point during the operation of the computer system, the OS may experience an error that partially or completely impairs the operation of the computer system. Thus, the computer system may become partially or completely inoperable, thereby impairing the functionality of the cell site while the computer system experiences downtime. Furthermore, traditionally, maintenance personnel physically visit cell sites to assess errors and repair the OS, which may include reinstalling the OS on the computer system, such as in the case of an OS boot failure. Waiting for maintenance personnel to reach the cell site and then address the OS error results in extended downtime. While some computer systems may allow for remote OS repair or reinstallation, such remote access to the computer system may be insecure and still require manual intervention by maintenance personnel.

[0008] Furthermore, operating systems typically need to be updated over time to address various issues, such as bugs in newly deployed software, and to provide improved security. Traditionally, cell site computer systems had to be taken offline while the OS was being updated, thereby compromising the functionality of the cell site while the computer systems experienced downtime. [Overview of the project] [Means for solving the problem]

[0009] In some implementations, this subject relates to a computer implementation method. This method may include attempting to boot an operating system (OS) from a first basic input / output system (BIOS) pre-stored in a first partition of the memory of a communication device in a wireless communication system. The OS can operate on the communication device in response to the OS successfully booting from the first BIOS, and this method may further include automatically attempting to boot the OS from a second BIOS pre-stored in a second partition of the memory of the communication device in response to the OS failing to successfully boot from the first BIOS.

[0010] In some implementations, this subject may include one or more of the following optional features.

[0011] In some implementations, the OS can operate on the communication device in response to the OS successfully booting from the second BIOS, and this method may further include automatically booting the OS from a third BIOS pre-stored in a third partition of the communication device's memory in response to the OS failing to successfully boot from the second BIOS. Furthermore, the third BIOS may be pre-stored in a third partition of memory during the manufacturing of the communication device. In addition, the first and second BIOSes can each be configured to be upgradeable, while the third BIOS cannot be upgraded.

[0012] In some implementations, the method may further include upgrading a second BIOS while the OS is running on the communication device, and automatically rebooting the OS from the upgraded second BIOS in response to the successful upgrade of the second BIOS. Furthermore, the method may further include upgrading the first BIOS after the reboot and while the OS is running on the communication device, and automatically rebooting the OS from the upgraded first BIOS in response to the successful upgrade of the first BIOS.

[0013] In some implementations, the first BIOS may be pre-stored in a first partition of memory during the manufacturing of the communication device, the second BIOS may be pre-stored in a second partition of memory during the manufacturing of the communication device, the second BIOS may be configured to be upgraded during the operation of an OS that has been successfully booted from the first BIOS, and the first BIOS may be configured to be upgraded during the operation of an OS that has been successfully booted from the second BIOS.

[0014] In some implementations, attempting to boot the OS from a first BIOS may include attempting to boot a first boot loader, and the method may further include automatically attempting to boot the OS from a second BIOS in response to a failure to boot the first boot loader, determining whether the boot loader has been attempted to boot the communication device more than a predetermined threshold number of times in response to a successful boot of the first boot loader, continuing the attempt to boot the OS from the first BIOS in response to determining that the boot loader has not been attempted to boot the communication device more than a predetermined threshold number of times, and automatically attempting to boot the OS from the second BIOS in response to determining that the boot loader has been attempted to boot the communication device more than a predetermined threshold number of times. Furthermore, this method further attempts to load the first kernel image of the first BIOS after continuing attempts to boot the OS from the first BIOS, triggers a reboot of the OS from the first BIOS in response to the first kernel image not loading successfully, and in response to the first kernel image loading successfully, the first kernel image of the first BIOS initrd Attempting to load the image, and the first initrd In response to the image not loading correctly, trigger an OS reboot from the first BIOS, and the first initrdThe method may further include, in response to the successful loading of the image, continuing the attempt to boot the OS from the first BIOS, and / or, the attempt to boot the OS from the second BIOS may include the attempt to boot the second boot loader, and the method may further include, in response to the failure to boot the second boot loader, automatically booting the OS from the third BIOS pre-stored in the third partition of the communication device's memory, in response to the successful booting of the second boot loader, determining whether the boot loader boot has been attempted more than a predetermined threshold number of times, in response to the determination that the boot loader boot has not been attempted more than a predetermined threshold number of times, continuing the attempt to boot the OS from the second BIOS, and in response to the determination that the boot loader boot has been attempted more than a predetermined threshold number of times, automatically attempting to boot the OS from the third BIOS. Furthermore, the third BIOS may be pre-stored in the third partition of the memory during the manufacture of the communication device. Furthermore, the first and second BIOSes can each be configured to be upgradeable, while the third BIOS cannot be upgraded.

[0015] In some implementations, the communication device can be a distributed unit (DU).

[0016] In some implementations, at least one of the attempts and / or automatic attempts can be performed by a base station in the wireless communication system. Furthermore, the base station may include at least one of eNodeB base stations, gNodeB base stations, wireless base stations, and any combination thereof.

[0017] In some implementations, the wireless communication system may be at least one of the following: a long-term evolution communication system, a new wireless communication system, or any combination thereof.

[0018] Also described are non-temporary computer program products (i.e., physically embodied computer program products) that, when executed by one or more data processors of one or more computing systems, store instructions causing at least one data processor to perform the operations described herein. Similarly, computer systems that may include one or more data processors and memory coupled to one or more data processors are also described. The memory can temporarily or permanently store instructions causing at least one processor to perform one or more of the operations described herein. Furthermore, the method may be implemented by one or more data processors in a single computing system or distributed across two or more computing systems. Such computing systems may be connected via one or more connections that can exchange data and / or commands or other instructions, etc., and these connections include, but are not limited to, connections via networks (e.g., the Internet, wireless wide area networks, local area networks, wide area networks, wired networks, etc.) via direct connections between one or more of the computing systems.

[0019] Details of one or more modifications of the subject matter described herein are shown in the accompanying drawings and the following description. Other features and advantages of the subject matter described herein will be evident from the description and drawings, and from the claims.

[0020] The accompanying drawings incorporated herein and constituting part of this specification illustrate specific aspects of the subject matter disclosed herein and, together with the description, help to illustrate some of the principles relating to the disclosed implementations. [Brief explanation of the drawing]

[0021] [Figure 1a] This figure illustrates an exemplary conventional Long-Term Evolution ("LTE") communication system.

[0022] [Figure 1b] FIG. 2 is a diagram showing further details of an exemplary LTE system shown in FIG. 1a.

[0023] [Figure 1c] FIG. 8 is a diagram showing further details of an evolved packet core of an exemplary LTE system shown in FIG. 1a.

[0024] [Figure 1d] FIG. 14 is a diagram showing an exemplary evolved Node B of an exemplary LTE system shown in FIG. 1a.

[0025] [Figure 2] FIG. 20 is a diagram showing further details of an evolved Node B shown in FIGS. 1a - 1d.

[0026] [Figure 3] FIG. 26 is a diagram showing an exemplary virtual radio access network according to some implementations of the present subject matter.

[0027] [Figure 4] FIG. 32 is a diagram showing an exemplary 3GPP split architecture for providing its user with the use of a higher frequency band.

[0028] [Figure 5a] FIG. 38 is a diagram showing an exemplary 5G wireless communication system.

[0029] [Figure 5b] FIG. 44 is a diagram showing an exemplary layer architecture of a split gNB and / or a split ng-eNB (e.g., a next generation eNB that can be connected to a 5GC). [[ID=四十七]]

[0030] [Figure 5c] FIG. 50 is a diagram showing an exemplary functional split in a gNB architecture shown in FIGS. 5a - 5b.

[0031] [Figure 6]This figure shows a dual BIOS FLASH configuration for a device containing multiple OS partitions, based on several implementations of this subject.

[0032] [Figure 7] This figure shows the configuration of a device containing multiple OS partitions having a first set of designations, based on several implementations of this subject.

[0033] [Figure 8] Figure 7 shows a configuration with multiple OS partitions having a second set of specifications, representing several implementations of this subject.

[0034] [Figure 9] This figure shows several implementations of this topic that demonstrate how to perform automatic fallback across multiple OS instances.

[0035] [Figure 10] This figure shows methods for performing automatic upgrades across multiple OS instances using several implementations of this subject.

[0036] [Figure 11] This figure shows an exemplary system with several implementation forms of this subject.

[0037] [Figure 12] This figure illustrates several implementations of this subject. [Modes for carrying out the invention]

[0038] This subject can provide systems and methods that can be implemented in wireless communication systems. Such systems may include various wireless communication systems, including 5G new radio (NR) communication systems and long-term evolution (LTE) communication systems.

[0039] Generally, this subject concerns automatic upgrades and fallbacks across multiple operating system ("OS") instances.

[0040] In some implementations of this subject, a computer system may have multiple instances of the OS installed on it. These OS instances, also referred to herein as OS partitions, are partitioned from one another within the computer system's memory. Therefore, an error in one OS instance may be isolated from any of the other OS instances and may not affect any of them. If a booted OS instance fails to boot successfully, the other OS instances can provide redundancy, allowing one of the other OS instances to automatically boot.

[0041] In some implementations of this subject, the OS may attempt to boot from a first Basic Input / Output System ("BIOS") pre-stored in a first partition of the computer system's memory in a communication device within a wireless communication system, such as a Long-Term Evolution Communication System, a New Wireless Communication System, or another Wireless Communication System. The OS can operate on the communication device in response to the OS successfully booting from the first BIOS. In response to the OS failing to successfully boot from the first BIOS, the OS may automatically attempt to reboot from a second BIOS pre-stored in a second partition of the communication device's memory.

[0042] In some implementations of this subject, the second BIOS can be upgraded while the OS is running on a communication device after the OS has successfully booted from the first BIOS. In response to the successful upgrade of the second BIOS, the OS may automatically reboot from the upgraded second BIOS.

[0043] One or more aspects of this subject matter may be incorporated into the transmitter and / or receiver components of base stations (e.g., gNodeB, eNodeB, etc.) within such communication systems. The following is a general discussion of long-term evolution communication systems and new 5G wireless communication systems.

[0044] I. Long-Term Evolution Communication Systems Figures 1a-1c and 2 illustrate an exemplary conventional Long-Term Evolution ("LTE") communication system 100 with its various components. The LTE system, or 4G LTE, is governed by a standard for high-speed data wireless communication for mobile phones and data terminals, as is commercially known. This standard is an evolution of GSM / EDGE ("Global System for Mobile Communications" / "GSM Advanced High-Speed ​​Data Rate") and UMTS / HSPA ("Universal Mobile Communications System" / "High-Speed ​​Packet Access") network technologies. This standard was developed by 3GPP ("Third Generation Partnership Project").

[0045] As shown in Figure 1a, System 100 may include an Advanced Universal Terrestrial Radio Access Network ("EUTRAN") 102, an Advanced Packet Core ("EPC") 108, and a Packet Data Network ("PDN") 101, where EUTRAN 102 and EPC 108 provide communication between user equipment 104 and PDN 101. EUTRAN 102 may include multiple Advanced Node B ("eNodeB" or "ENODEB" or "enodeb" or "eNB") or base stations 106 (a, b, c) (as shown in Figure 1b) that provide communication capabilities to multiple user equipment 104 (a, b, c). User equipment 104 may be a mobile phone, smartphone, tablet, personal computer, personal digital assistant ("PDA"), server, data terminal, and / or any other type of user equipment, and / or any combination thereof. The user device 104 can connect to the EPC 108 and ultimately to the PDN 101 via any eNodeB 106. Typically, the user device 104 can connect to the eNodeB 106 closest in terms of distance. In the LTE system 100, the EUTRAN 102 and EPC 108 work together to provide connectivity, mobility, and services for the user device 104.

[0046] Figure 1b shows further details of the network 100 shown in Figure 1a. As described above, EUTRAN 102 includes multiple eNodeB 106, also known as cell sites. The eNodeB 106 provides radio functionality and performs important control functions, including scheduling or radio resource management of airlink resources, active mode mobility or handover, and admission control for services. The eNodeB 106 is responsible for selecting which mobility management entity (MME, as shown in Figure 1c) will serve the user equipment 104, and for protocol features such as header compression and encryption. The multiple eNodeB 106 that make up EUTRAN 102 cooperate with each other for radio resource management and handover.

[0047] Communication between user equipment 104 and eNodeB 106 takes place via air interface 122 (also known as the “LTE-Uu” interface). As shown in Figure 1b, air interface 122 provides communication between user equipment 104b and eNodeB 106a. Air interface 122 uses orthogonal frequency division multiple access (“OFDMA”) and single-carrier frequency division multiple access (“SC-FDMA”), OFDMA variants, on the downlink and uplink, respectively. OFDMA enables the use of several known antenna techniques, including multiple input multiple output (“MIMO”).

[0048] The air interface 122 uses various protocols, including radio resource control ("RRC") for signaling between user equipment 104 and eNodeB 106, and non-accessible layer ("NAS") for signaling between user equipment 104 and MME (as shown in Figure 1c). In addition to signaling, user traffic is forwarded between user equipment 104 and eNodeB 106. Both signaling and traffic in system 100 are carried by physical layer ("PHY") channels.

[0049] Multiple eNodeB106s can be interconnected using X2 interfaces 130(a, b, c). As shown in Figure 1b, X2 interface 130a provides interconnection between eNodeB106a and eNodeB106b, X2 interface 130b provides interconnection between eNodeB106a and eNodeB106c, and X2 interface 130c provides interconnection between eNodeB106b and eNodeB106c. The X2 interface can be established between two eNodeBs to provide signal exchange, which may include information related to load or interference, as well as information related to handover. The eNodeB106s communicate with the advanced packet core 108 via S1 interfaces 124(a, b, c). The S1 interface 124 can be divided into two interfaces: one for the control plane (shown as the control plane interface (S1-MME interface) 128 in Figure 1c) and the other for the user plane (shown as the user plane interface (S1-U interface) 125 in Figure 1c).

[0050] EPC108 establishes and enforces Quality of Service ("QoS") for user services, enabling user equipment 104 to maintain a consistent Internet Protocol ("IP") address while in transit. Note that each node in network 100 has its own IP address. EPC108 is designed to interact with legacy wireless networks. EPC108 is also designed to separate the control plane (i.e., signaling) and the user plane (i.e., traffic) in the core network architecture, which allows for greater flexibility in implementation forms, as well as independent scalability of control and user data functions.

[0051] The EPC108 architecture is dedicated to packet data and is illustrated in detail in Figure 1c. The EPC108 includes a Serving Gateway (S-GW) 110, a PDN Gateway (P-GW) 112, a Mobility Management Entity ("MME") 114, a Home Subscriber Server ("HSS") 116 (subscriber database for EPC108), and a Policy Control and Billing Rule Function ("PCRF") 118. Some of these (such as the S-GW, P-GW, MME, and HSS) are often combined into a node according to the manufacturer's implementation.

[0052] S-GW110 functions as an IP packet data router and is the bearer route anchor for user equipment within EPC108. Therefore, when user equipment moves from one eNodeB106 to another during mobility operation, S-GW110 remains the same, and the bearer route toward EUTRAN102 is switched to communicate with the new eNodeB106 serving user equipment 104. If user equipment 104 moves to the domain of another S-GW110, MME114 will forward all of the user equipment's bearer routes to the new S-GW. S-GW110 establishes bearer routes for user equipment to one or more P-GW112s. When downstream data is received for idle user equipment, S-GW110 buffers the downstream packets and requests MME114 to identify and re-establish the bearer routes to and through EUTRAN102.

[0053] P-GW112 is the gateway between EPC108 (and user equipment 104 and EUTRAN102) and PDN101 (shown in Figure 1a). P-GW112 functions as a router for user traffic and performs functions on behalf of the user equipment. These include assigning IP addresses to user equipment, packet filtering of downstream user traffic to ensure that downstream user traffic is placed on the appropriate bearer route, and implementing downstream QoS, including data rates. Depending on the services used by the subscriber, there may be multiple user data bearer routes between user equipment 104 and P-GW112. A subscriber may use services on a PDN served by different P-GWs, in which case the user equipment has at least one bearer route established to each P-GW112. If the S-GW110 also changes during a handover of user equipment from one eNodeB to another, the bearer route from P-GW112 is switched to the new S-GW.

[0054] The MME114 manages user devices 104 within the EPC108, which includes managing subscriber authentication, maintaining context for authenticated user devices 104, establishing data bearer routes within the network for user traffic, and tracking the location of standby mobile devices that have not detached from the network. For standby user devices 104 that need to reconnect to the access network to receive downstream data, the MME114 initiates paging to locate the user device and re-establishes the bearer route to and through the EUTRAN102. The MME114 for a particular user device 104 is selected by the eNodeB106 from which the user device 104 initiates system access. MMEs are typically part of a collection of MMEs within the EPC108 for load sharing and redundancy purposes. In establishing user data bearer routes, the MME114 is responsible for selecting the P-GW112 and S-GW110, which constitute the endpoints of the data route through the EPC108.

[0055] PCRF118 is responsible for policy control decision-making and controlling the flow-based billing functionality within the policy control enforcement function ("PCEF") residing within P-GW110. PCRF118 provides QoS authentication (QoS class identifier ("QCI") and bitrate), which determines how a given data flow is handled within the PCEF and ensures that this conforms to the user's subscription profile.

[0056] As described above, IP service 119 is provided by PDN 101 (as shown in Figure 1a).

[0057] Figure 1d shows an exemplary structure of eNodeB106. eNodeB106 may include at least one remote radio head ("RRH") 132 (typically, there may be three RRHs 132) and a baseband unit ("BBU") 134. The RRH 132 may be connected to an antenna 136. The RRH 132 and BBU 134 may be connected using an optical interface compliant with the Common Public Radio Interface ("CPRI") / Extended CPRI ("eCPRI") 142 standard, either using a custom control and user plane framing method specific to the RRH or using an O-RAN Alliance compliant control and user plane framing method. The operation of eNodeB106 can be characterized using the following standard parameters (and specifications): namely, high frequency bandwidth (band 4, band 9, band 17, etc.), bandwidth (5, 10, 15, 20 MHz), access method (downlink: OFDMA, uplink: SC-OFDMA), antenna technology (single-user and multi-user MIMO, uplink: single-user and multi-user MIMO), number of sectors (maximum 6), maximum transmission speed (downlink: 150 Mb / s, uplink: 50 Mb / s), S1 / X2 interface (1000Base-SX, 1000Base-T), and mobile environment (maximum 350 km / h). BBU134 can handle digital baseband signal processing, S1 line termination, X2 line termination, call processing, and monitoring and control processing. IP packets received from EPC108 (not shown in Figure 1d) can be modulated into digital baseband signals and transmitted to RRH132. Conversely, the digital baseband signal received from the RRH132 can be demodulated into IP packets for transmission to the EPC108.

[0058] The RRH132 can transmit and receive wireless signals using the antenna 136. The RRH132 can convert digital baseband signals from the BBU134 into radio frequency ("RF") signals (using a converter ("CONV") 140) and power amplified them (using an amplifier ("AMP") 138) for transmission to user equipment 104 (not shown in Figure 1d). Conversely, RF signals received from user equipment 104 are amplified (using AMP 138) and converted into digital baseband signals (using CONV 140) for transmission to the BBU134.

[0059] Figure 2 shows additional details of an exemplary eNodeB106. The eNodeB106 includes multiple layers: namely LTE Layer 1 202, LTE Layer 2 204, and LTE Layer 3 206. LTE Layer 1 includes the physical layer ("PHY"). LTE Layer 2 includes Medium Access Control ("MAC"), Radio Link Control ("RLC"), and Packet Data Convergence Protocol ("PDCP"). LTE Layer 3 includes various functions and protocols, including Radio Resource Control ("RRC"), Dynamic Resource Allocation, eNodeB Measurement Configuration and Provisioning, Radio Admission Control, Connectivity Mobility Control, and Radio Resource Management ("RRM"). The RLC protocol is an Automatic Retransmission Request ("ARQ") fragmentation protocol used over the cellular air interface. The RRC protocol handles LTE Layer 3 control plane signaling between user equipment and EUTRAN. RRC includes functions for connection establishment and release, broadcasting system information, establishing / reconfiguring and releasing radio bearers, RRC connection mobility procedures, paging notifications and releases, and outer loop power control. PDCP performs IP header compression and decompression, user data transfer, and maintaining the radio bearer sequence number. BBU134, shown in Figure 1d, may include LTE layers L1-L3.

[0060] One of the main functions of eNodeB106 is radio resource management, which includes scheduling of both uplink and downlink air interface resources for user equipment 104, as well as bearer resource control and admission control. As an agent for EPC108, eNodeB106 is responsible for forwarding paging messages used to locate mobile devices when they are on standby. eNodeB106 also communicates common control channel information over the air, performs header compression, encrypts and decrypts user data transmitted over the air, and establishes handover reporting and trigger criteria. As described above, eNodeB106 can cooperate with other eNodeB106s via the X2 interface for handover and interference management purposes. eNodeB106 communicates with the EPC's MME via the S1-MME interface and with the S-GW using the S1-U interface. Furthermore, eNodeB106 exchanges user data with the S-GW via the S1-U interface. eNodeB106 and EPC108 have a many-to-many relationship to support load sharing and redundancy between MMEs and S-GWs. eNodeB106 selects an MME from a group of MMEs so that the load can be shared by multiple MMEs to avoid congestion.

[0061] II.5G NR Wireless Communication Network In some implementations, this subject concerns the new 5G radio ("NR") communication system. 5G NR is the next communication standard beyond the 4G / IMT-Advanced standard. 5G networks offer higher capacity than current 4G, enabling a greater number of mobile broadband users per unit area and allowing for more and / or unlimited data consumption in gigabytes per month and per user. This could allow users to stream high-definition media for hours per day using their mobile devices, even if this is not possible on Wi-Fi networks. 5G networks also offer improved support for device-to-device communication, lower costs, lower latency than 4G equipment, and lower battery consumption. Compared to existing systems, such networks offer data rates of tens of megabits per second for a large number of users, 100 Mb / s for metropolitan areas, 1 Gb / s simultaneous to users within a limited area (e.g., an office floor), numerous simultaneous connections for wireless sensor networks, enhanced spectral efficiency, improved coverage, increased signaling efficiency, latency of 1-10 ms, and reduced latency.

[0062] Figure 3 shows an exemplary virtual radio access network 300. The network 300 can provide communication between various components, including base stations (e.g., eNodeB, gNodeB) 301, radio equipment, a central unit 302, a digital unit 304, and a radio device 306. Components in the system 300 can be communicatively coupled to the core using a backhoe link 305. The central unit ("CU") 302 can be communicatively coupled to a distributed unit ("DU") 304 using a midhoe connection 308. The radio frequency ("RU") component 306 can be communicatively coupled to the DU 304 using a fronthoe connection 310.

[0063] In some implementations, CU302 can provide intelligent communication functions to one or more DU units 304. Units 302, 304 may include one or more base stations, macro base stations, micro base stations, remote radio heads, and / or any combination thereof.

[0064] In a lower-layer partitioned architecture environment, the CPRI bandwidth requirement for NR can be several hundred Gb / s. CPRI compression can be performed at the DU and RU (as shown in Figure 3). In 5G communication systems, the compressed CPRI on the Ethernet frame is called eCPRI and is the recommended fronthole network. This architecture can enable fronthole / midhole standardization, which may include upper-layer partitioning (e.g., Option 2 or Option 3-1 (upper / lower RLC partitioned architecture)) and fronthole using an L1 partitioned architecture (Option 7).

[0065] In some implementations, the lower layer partitioning architecture (e.g., Option 7) may include a receiver at the uplink, joint processing across multiple transmit points (TPs) for both DL / UL, and transport bandwidth and latency requirements to facilitate deployment. Furthermore, the lower layer partitioning architecture of this subject may include partitioning between cell-level processing and user-level processing, which may include cell-level processing at the remote unit ("RU") and user-level processing at the DU. Moreover, using the lower layer partitioning architecture of this subject, frequency domain samples may be transmitted over the Ethernet fronthoe, and the frequency domain samples may be compressed for reduced fronthoe bandwidth.

[0066] Figure 4 shows an exemplary communication system 400 that can implement 5G technology and give its users the use of higher frequency bands (for example, greater than 10 GHz). System 400 may include a macrocell 402 and small cells 404, 406.

[0067] The mobile device 408 may be configured to communicate with one or more of the small cells 404, 406. The system 400 can enable the division of the control plane (C-plane) and user plane (U-plane) between the macrocell 402 and the small cells 404, 406, with the C-plane and U-plane utilizing different frequency bands. Specifically, the small cells 404, 406 may be configured to utilize a higher frequency band when communicating with the mobile device 408. The macrocell 402 can utilize the existing cellular band for C-plane communication. The mobile device 408 may be communicatively coupled via the U-plane 412, where the small cell (e.g., small cell 406) can provide a higher data rate and more flexible / cost / energy-efficient operation. The macrocell 402 can maintain good connectivity and mobility via the C-plane 410. Furthermore, in some cases, LTE and NR may be transmitted on the same frequency.

[0068] Figure 5a shows an exemplary 5G wireless communication system 500 in several implementation forms of the subject. System 500 may be configured to have a lower-layer partitioning architecture according to option 7-2. System 500 may include a core network 502 (e.g., a 5G core) and one or more gNodeBs (or gNBs), where the gNB may have a centralized unit gNB-CU. The gNB-CU may be logically divided into a control plane portion gNB-CU-CP 504 and one or more user plane portions gNB-CU-UP 506. The control plane portion 504 and the user plane portion 506 may be configured to be communicatively coupled using an E1 communication interface 514 (as defined in the 3GPP standard). The control plane portion 504 may be configured to be responsible for executing the RRC and PDCP protocols of the radio stack.

[0069] The control plane portion 504 and user plane portion 506 of the gNB's centralized unit may be configured to communicately couple to one or more distributed units (DUs) 508, 510 according to the upper layer partitioning architecture. The distributed units 508, 510 may be configured to run the upper parts of the RLC, MAC, and PHY layer protocols of the radio stack. The control plane portion 504 may be configured to communicately couple to the distributed units 508, 510 using an F1-C communication interface 516, and the user plane portion 506 may be configured to communicately couple to the distributed units 508, 510 using an F1-U communication interface 518. The distributed units 508, 510 may be coupled to one or more remote radio units (RUs) 512 via a front-houl network 520 (which may include one or more switches, links, etc.), which then communicate with one or more user devices (not shown in Figure 5a). The remote radio unit 512 may be configured to execute the lower part of the PHY layer protocol and to provide antenna capabilities to the remote unit for communication with user equipment (similar to the above description relating to Figures 1a-2).

[0070] Figure 5b shows an exemplary layer architecture 530 of a segmented gNB. Architecture 530 can be implemented within the communication system 500 shown in Figure 5a, which can be configured as a virtualized, non-aggregated radio access network (RAN) architecture, thereby allowing layers L1, L2, L3 and radio processing to be virtualized and non-aggregated within centralized, distributed, and radio units. As shown in Figure 5b, the gNB-DU 508 can be communicatively coupled to the gNB-CU-CP control plane portion 504 (also shown in Figure 5a) and the gNB-CU-UP user plane portion 506. Each of components 504, 506, and 508 may be configured to include one or more layers.

[0071] The gNB-DU508 may include the RLC, MAC, and PHY layers, as well as various communication sublayers. These may include the F1 Application Protocol (F1-AP) sublayer, the GPRS Tunneling Protocol (GTPU) sublayer, the Stream Controlled Transmission Protocol (SCTP) sublayer, the User Datagram Protocol (UDP) sublayer, and the Internet Protocol (IP) sublayer. As described above, the distributed unit 508 can be communicatively coupled to the control plane portion 504 of the centralized unit, which may also include the F1-AP, SCTP, and IP sublayers, as well as the Radio Resource Control and PDCP Control (PDCP-C) sublayers. Furthermore, the distributed unit 508 may also be communicatively coupled to the user plane portion 506 of the centralized unit of the gNB. The user plane portion 506 may include the Service Data Adaptive Protocol (SDAP), PDCP User (PDCP-U), GTPU, UDP, and IP sublayers.

[0072] Figure 5c shows an exemplary functional partition in the gNB architecture shown in Figures 5a and 5b. As shown in Figure 5c, gNB-DU508 can be communicatively coupled to gNB-CU-CP504 and GNB-CU-UP506 using the F1-C communication interface. gNB-CU-CP504 and GNB-CU-UP506 can be communicatively coupled using the E1 communication interface. The upper part of the PHY layer (or layer 1) may be performed by gNB-DU508, and the lower part of the PHY layer may be performed by RU (not shown in Figure 5c). As shown in Figure 5c, the RRC and PDCP-C parts may be performed by the control plane part 504, and the SDAP and PDCP-U parts may be performed by the user plane part 506.

[0073] Some of the functions of the PHY layer in a 5G communication network may include error detection on the transport channel and instructions to higher layers, FEC coding / decoding of the transport channel, hybrid ARQ soft synthesis, rate matching of coded transport channels to physical channels, mapping of coded transport channels to physical channels, power weighting of physical channels, modulation and demodulation of physical channels, frequency and time synchronization, radio characteristics measurement and instructions to higher layers, MIMO antenna processing, digital and analog beamforming, RF processing, and other functions.

[0074] The Layer 2 MAC sublayer can perform beam management, random access procedures, mapping between logical channels and transport channels, concatenation of multiple MAC service data units (SDUs) belonging to a single logical channel into a transport block (TB), multiplexing / demultiplexing of SDUs belonging to a logical channel to / from a TB passed to and from the physical layer on the transport channel, scheduling information reporting, error correction by HARQ, priority processing between logical channels of a single UE, priority processing between UEs by dynamic scheduling, transport format selection, and other functions. The functions of the RLC sublayer may include forwarding upper layer packet data units (PDUs), error correction by ARQ, sorting, duplication and protocol error detection of data PDUs, and re-establishment. The PDCP sublayer can be responsible for forwarding user data, various functions during re-establishment procedures, retransmission of SDUs, discarding SDUs on the uplink, and forwarding control plane data.

[0075] The Layer 3 RRC sublayer can perform functions such as broadcasting system information to NAS and AS, establishing, maintaining, and releasing RRC connections, security, establishing, configuring, maintaining, and releasing point-to-point wireless bearers, mobility functions, reporting, and other functions.

[0076] III. Automatic Upgrades and Fallback Across Multiple Operating System Instances In some implementations of this subject, a computer system (for example, a computer system at a base station (e.g., gNodeB or gNB, eNodeB or eNB, ng-eNodeB or ng-eNB) as shown in Figures 1a to 5c and described above with respect to Figures 1a to 5c, a commercial off-the-shelf (COTS) server, etc.) can have multiple instances of the OS installed on it. One of the OS instances can boot and operate at a time. If the booted OS instance fails to boot successfully, the other OS instances can provide redundancy by automatically booting one of the other OS instances. Thus, even if the computer system experiences an OS boot failure, the computer system can still boot and have OS functionality. Human error can also be avoided. Furthermore, the OS can boot without requiring local or remote manual intervention to deal with the boot failure experienced by one of the OS instances. An operating system may fail to boot properly for a variety of reasons, including errors in installing the OS on the computer system that prevent the initial boot of the OS, failures in the OS boot loader during the boot process, failures in loading the OS kernel image during the boot process, failures in loading the OS initial RAM disk ("initrd") during the boot process, kernel panics, or kernel failures or other serious failures that prevent a normal boot.

[0077] OS instances, also referred to herein as OS partitions, are partitioned from one another within the memory of a computer system. Therefore, an error in one OS instance, such as an installation error, an error occurring during the boot process, an error occurring while the OS is running, or an error occurring during or as a result of an upgrade, may be isolated from and unaffected by any other OS instances. Only one of the OS instances is configured to boot and operate at a time, so that each OS instance provides the computer system with full OS functionality. Since the computer system can function regardless of which OS instance is booted, multiple OS instances can therefore provide redundancy to reduce or avoid computer system downtime. Reducing or avoiding downtime can mitigate revenue loss and a decline in key performance indicators ("KPIs") (accessibility) for the computer system operator. If the computer system is a device in a wireless communications network, avoiding downtime can allow the cell site where the computer system is located to remain fully functional and handle cell traffic appropriately as needed.

[0078] Each OS instance (except the golden OS instance) can be configured to be upgraded independently of all other OS instances. One of the OS instances may be the golden OS instance installed during manufacturing, which cannot be upgraded. This can help ensure that the computer system always has a bootable OS available. Upgrading an independent OS instance can help prevent errors occurring in the OS instance being upgraded, either during or as a result of the upgrade, from affecting other OS instances. Upgrading an independent OS instance can allow the computer system to upgrade an OS instance without experiencing downtime, as an OS booted from another OS instance may be running during the upgrade.

[0079] Once the upgrade is successfully installed on the OS partition, the computer system can be configured to automatically reboot from the upgraded OS partition. Automatic rebooting allows the upgrade to take effect as quickly as possible, thus enabling the benefits of the upgrade to be realized more rapidly without the need for manual reboots that could delay the use of the upgrade on the computer system. While the computer system will experience downtime during this reboot, it will be significantly less than what would be experienced if the computer system were down or in maintenance mode during the upgrade, or if the computer system were unable to successfully boot the upgraded OS (since the OS could be booted from one of the other partitions). If the newly upgraded OS instance being booted fails to boot successfully, the other OS instances can provide redundancy, allowing one of the OS instances to automatically boot instead, as described herein.

[0080] In response to an OS instance failing to boot or upgrade successfully, a notification can be automatically generated and sent to the operational facility and / or administrator responsible for maintaining the computer system to notify of the boot or upgrade failure. Therefore, an OS instance that failed to boot or upgrade successfully may be evaluated and / or repaired remotely and / or locally, as needed, by the administrator receiving the notification, or by another maintenance worker who receives the notification directly or is otherwise informed of the need for evaluation and / or repair as a result of the notification being sent to the operational facility and / or administrator. Such evaluation and repair may not require computer system downtime, as another OS instance may operate to maintain the functionality of the computer system despite the failure of one OS instance to boot or upgrade successfully.

[0081] Figure 6 shows one implementation of the computer system 600 in several implementation forms of this subject. The computer system 600 may be for a communication device configured for use in a wireless communication network, a COTS server, or other devices (for example, base stations such as those shown in Figures 1a to 5c and described above with respect to Figures 1a to 5c, such as gNodeB or gNB, eNodeB or eNB, ng-eNodeB or ng-eNB)).

[0082] The computer system 600 includes a first memory 602 containing multiple OS partitions 604 (a first partition 604a, a second partition 604b, and a third partition 604c) and a second memory 606 containing multiple OS partitions 608 (a first partition 608a, a second partition 608b, and a third partition 608c). Each of the first memory 602 and the second memory 606 contains three OS partitions 604, 608 in this illustrated implementation, but can contain a different number of partitions greater than three, such as four, five, etc. Having three partitions makes available, as shown in Figure 6, a first partition for the current OS to be booted or an active OS that is running, a second partition for a standby OS that is waiting to boot and operate (standby) in case the active OS cannot boot, and a third partition for a golden OS installed during manufacturing, which is a backup of the active and standby partitions in case each of the active and standby partitions cannot boot. Having more than three partitions may make it possible to provide at least one additional standby OS partition.

[0083] The first and second memories 602, 606 may each include one or more types of memory or storage devices. Each of the first and second memories 602, 606 is a solid-state drive ("SSD") in the illustrated implementation in Figure 6, but may be or include at least one other type, such as non-volatile memory express ("NVMe"), a disk device, or other types.

[0084] Each of the first and second memories 602 and 606 may be associated with a specific component of the computer system 600. In other implementations, the computer system 600 may contain only one memory. In yet another implementation, the computer system 600 may contain one or more additional memories, each associated with one or more corresponding additional components of the computer system 600. For example, in some implementations of this subject, the computer system 600 may be associated with a base station, and the first memory 602 may be associated with the base station's first DU (e.g., DU304 in Figure 3, DU508 or 510 in Figures 5a-5c, etc.), and the second memory 604 may be associated with the base station's second DU (e.g., DU304 in Figure 3, DU508 or 510 in Figures 5a-5c, etc.). Any additional DU of the base station may each be associated with additional memories configured and used similarly to the memories 602 and 606 described herein.

[0085] The computer system 600 may also include, as shown in the implementation configuration of Figure 6, a processor 610, a composite programmable logic device ("CPLD") 612, a first multiplexer ("MUX") 614 communicatively coupled to the processor 610 and the CPLD 612, a second MUX 616 communicatively coupled to the processor 610 and the CPLD 612, a first BIOS 618 communicatively coupled to the first MUX 614 (for example, via a first serial peripheral interface ("SPI") 620), a second BIOS 622 communicatively coupled to the second MUX 616 (for example, via a second SPI 624), a first memory 602, and a second memory 606. In this illustrated implementation configuration, the processor 610 is an Ice Lake Xeon D ("ICX-D") (Intel® Xeon® D processor), but may be of a different type.

[0086] As shown in the implementation configuration of Figure 6, the second BIOS 622 may contain content stored in FLASH memory. This content may include the primary BIOS image 626 and NVRAM 628. As also shown in the implementation configuration of Figure 6, the first BIOS 618 may contain content stored in FLASH memory. This content may include the golden BIOS image 630 and NVRAM 632. The NVRAM 632 of the first BIOS 618 may store a snapshot of the primary BIOS image 626 at the time of backup, which may help ensure version locking and ensure that the golden OS remains bootable at all times. The NVRAM 628 of the second BIOS 632 may store Extensible Firmware (EFI) variables that store the first boot order of the first multiple partitions 604a, 604b, 604c of the first memory 604 and the second boot order of the second multiple partitions 608a, 608b, 608c of the second memory 606.

[0087] The boot order indicates the preferred order in which the OS should be attempted to boot from each partition. The processor 610 is configured to cause the OS to boot according to the boot order, as described herein. The first of the multiple OS partitions in the boot order is considered the active OS and is also referred to herein as the “current partition” to reflect that it is the current partition preferred for booting, or the current partition in which the OS is operating as if it had successfully booted. The active OS is the first OS that will be attempted to boot and is therefore the OS that is actively running if it has successfully booted. The active OS is also referred to as the active OS. The second of the multiple OS partitions in the boot order is considered the standby OS. The standby OS is the OS that will be attempted to boot in the event of a boot failure of the active OS, as described further herein. The third of the multiple OS partitions in the boot order is the golden OS. The golden partition, being last in the boot order, generally reflects that one or more of the other partitions in the multiple partitions have been upgraded and may therefore be a more preferable OS to run than the OS in the golden partition.

[0088] Multiple partitions are ordered according to the boot order stored in non-volatile random access memory (NVRAM) 628. As will be further described herein, over time, as the active and standby partitions change their designations, the partitions in the boot order can be swapped, for example, a standby partition can become the active partition, and the active partition can become the standby partition. The golden partition always remains the golden partition and always remains last in the boot order.

[0089] Figure 6 reflects the boot order for the first set of partitions 604: the first partition 604a (labeled "Active OS" in Figure 6), the second partition 604b (labeled "Standby OS" in Figure 6), and the third partition 604c (labeled "Golden OS" in Figure 6). Figure 6 also reflects the boot order for the second set of partitions 608: the first partition 608a (labeled "Active OS" in Figure 6), the second partition 608b (labeled "Standby OS" in Figure 6), and the third partition 608c (labeled "Golden OS" in Figure 6).

[0090] It may be possible to override the boot order to force booting from an OS partition that is not next in the boot order. This override can be performed locally or remotely through manual intervention by a maintenance worker with authenticated access to computer system 600. For example, as shown in Figure 6, in “recovery” mode, a golden OS partition (e.g., golden partition 604c or golden partition 608c) can be forced to come first in the boot order. Since the golden OS is installed during manufacturing and cannot be upgraded, forcing booting from the golden OS partition can help ensure that the OS boots, which can be useful when repairing computer system 600, evaluating errors, etc. Booting from the golden partition (e.g., golden partition 604c or golden partition 608c) can be achieved by a restore operation via CPLD612, which is configured to copy the contents of the golden BIOS image 630 to the primary BIOS image 626 in order to attempt booting using the golden OS.

[0091] Figures 7 and 8 show the changes in the boot sequence over time in several implementations of this subject. Figures 7 and 8 show a BIOS 700 (e.g., the first BIOS 618 in Figure 6) that is communicatively coupled to memory 702 (e.g., the first memory 602 or the second memory 606 in Figure 6). The BIOS 700 contains content stored in FLASH memory, which may include a primary BIOS image 704 (e.g., the primary BIOS image 626 in Figure 6) and NVRAM 706 (e.g., NVRAM 628 in Figure 6). Memory 702 contains multiple OS partitions 708 (a first partition 708a, a second partition 708b, and a third partition 708c) (e.g., OS partition 604 or OS partition 608 in Figure 6). In this illustrated implementation, memory 702 includes disk devices, SSDs, and NVMe, but as described herein, memory 702 may include one or more types.

[0092] Figure 7 reflects the boot order for multiple partitions 708: namely, the first partition 708a (labeled "Active OS" in Figure 7), the second partition 708b (labeled "Standby OS" in Figure 7), and the third partition 708c (labeled "Golden OS" in Figure 7). Figure 8 reflects the change in assignment of the active and standby partitions, with the boot order here being the second partition 708b (labeled "Active OS" in Figure 8), the first partition 708a (labeled "Standby OS" in Figure 8), and the third partition 708c (labeled "Golden OS" in Figure 8). The boot order shown in Figure 8 reflects the fact that the first partition 708a failed to boot, and the second partition 708b will be attempted to boot instead. The partitions in the boot order may change to revert to the boot order shown in Figure 7 if the second partition 708b fails to boot. The partitions in the boot order may change any number of times while using the devices including the BIOS 700 and memory 702.

[0093] Figures 6-8 show implementations by this subject in which a single memory contains multiple OS instances with a boot order, for example, the first memory 602 in Figure 6 contains multiple OS partitions 604, the second memory 606 in Figure 6 contains multiple OS partitions 608, and the memory 702 in Figures 7 and 8 contains multiple OS partitions 708. In other implementations by this subject, multiple memory may each contain a single OS instance, where the multiple OS instances collectively (together) have a boot order. In yet another implementation by this subject, multiple memory may each contain multiple OS instances, where the multiple OS instances collectively have a boot order. In yet another implementation by this subject, multiple memory may be combined in various redundant arrays of independent (or inexpensive) disks ("RAID"). A bootable RAID volume contains multiple OS instances.

[0094] Figure 9 shows one implementation of Method 900 for performing automatic fallback across multiple OS instances in several implementation forms of this subject. Although Method 900 is described in relation to the implementation forms in Figures 7 and 8 for ease of explanation, it can be implemented in other configurations of memory and OS instances as described above, using other devices such as the device in Figure 6. Method 900 can be implemented by a base station (e.g., one or more base stations 106 in Figures 1b and 2, base station 301 in Figure 3, etc.) and / or one or more of its components, which may incorporate one or more components of computer systems such as computer system 600 in Figure 6, computer systems in Figures 7 and 8, and computer system 1100 in Figure 11.

[0095] As shown in Figure 9, method 900 may include turning on the device 902. Turning on the device 902 may trigger several setup actions 904 related to booting the OS.

[0096] Setup action 904 may include setting the boot order of partition 708 and storing the boot order in NVRAM 706 of BIOS 700, for example, by triggering the processor to set and store it. In this implementation, the boot order is set and stored in the first partition 708a (labeled "Active OS" in Figure 7), the second partition 708b (labeled "Standby OS" in Figure 7), and the third partition 708c (labeled "Golden OS" in Figure 7), as shown in Figure 7. The first partition 708a, which is first in the boot order, is labeled "Active OS" in Figure 7. The first partition 708a, which is first in the boot order, is the current partition. The second partition 708b, which is second in the boot order, is labeled "Standby OS" in Figure 7. The third and final partition in the boot sequence, partition 708c, is labeled "Golden OS" in Figure 7.

[0097] Setup action 904 may also include setting a boot attempt counter to 0, for example, by the processor setting a stored boot attempt counter to 0. The boot attempt counter may be stored in BIOS 700, for example in NVRAM 706, or in another location accessible to BIOS 700. The boot attempt counter may be set to 0 before or after the boot order is set.

[0098] After the boot order is set, method 900 continues by starting the boot of the OS from the current partition by booting from the boot loader of the current partition 906. Figures 7 and 8 show the first Grand Unified Bootloader (GRUB) bootloader 710a on the first partition 708a, the GRUB bootloader 710b on the second partition 708b, and the GRUB bootloader 710c on the third partition 708c. If booting the boot loader 906 is unsuccessful, the current partition cannot be booted. Therefore, in response to the failure of booting the boot loader 906, the next partition in the boot order is set as the current partition 908, which in this illustrated implementation is the second partition 708b. Method 900 then continues by booting the boot loader of the current partition 906, which is here the second GRUB bootloader 710b on the second partition 708b. If booting the boot loader fails (906), the standby OS cannot be booted. Therefore, in response to the failure of booting the boot loader (906), the next partition in the boot sequence is set as the current partition (908), which in this illustrated implementation is the third partition (708c). Method 900 then continues (906) to boot the boot loader of the current partition, which is here the third GRUB boot loader (710c) of the third partition (708c). This initiates the boot of the golden OS.

[0099] If the boot loader 906 of the first GRUB boot loader 710a is successful, it can continue to attempt to boot the current partition. Thus, method 900 may include incrementing the boot attempt counter by 1 910, for example, by the processor incrementing the stored boot attempt counter by 1.

[0100] Method 900 may include determining 912, for example, that the processor determines whether the boot attempt counter is greater than a threshold. This threshold may reflect the maximum number of times the current partition can be attempted to boot before it is deemed unbootable, thereby determining which partition in the boot order should be used to boot the OS. The threshold value may be pre-set and stored in the BIOS 700, for example in NVRAM 706, or in another location accessible to the BIOS 700. The threshold value may be selected based on any of several factors, such as the processor's processing power or the acceptable level of downtime in booting the OS.

[0101] In response to the determination 912 that the boot attempt counter is greater than a threshold, method 900 may include determining 914, for example, that the processor determines whether the current partition is the active partition. If it is determined that the current partition is the active partition 914, method 900 may include changing the partition designation for the boot order 916 so that the standby partition becomes the current partition. This change 916 reflects that the active OS has failed to boot enough times for an attempt to be made to boot the standby OS instead. The current partition is set to become the standby partition, the standby partition is designated as the active partition, and the former active partition is set as the standby partition. This change in designation is reflected in the difference between Figure 7 and Figure 8, where the first partition 708a changes from being the active OS to being the standby OS, and the second partition 708b changes from being the standby OS to being the active OS.

[0102] If the current partition is determined not to be the active partition, 914, method 900 may include modifying the partition specification for the boot order, 918, so that the golden partition becomes the current partition. This modification 918 reflects that the active and standby operating systems have each failed to boot enough times for an attempt to be made to boot the golden OS instead.

[0103] After changing the current partition to a standby partition 916 or changing the current partition to a golden partition 918, method 900 may include chainloading the bootloader of the current partition, for example, the GRUB bootloader 710b of the second partition 708b (when the current partition was changed to a standby partition 916), or the GRUB bootloader 710c of the third partition 708c (when the current partition was changed to a golden partition 918) 920. Method 900 then continues by booting the bootloader of the current partition 906.

[0104] In response to determining that the boot attempt counter is not greater than a threshold 912, method 900 may continue attempting to boot the OS by attempting to load the kernel image of the current partition. If the kernel image loading is unsuccessful, the current partition cannot be booted. Therefore, in response to the failure to load the kernel image, method 900 may include determining 914, as described above, for example, that the processor determines whether the current partition is the active partition.

[0105] If the kernel image load is successful, the system can continue attempting to boot the current partition by attempting to load the initrd image for the current partition. If the initrd image load is unsuccessful, the current partition cannot be booted. Therefore, in response to a kernel image loading failure, method 900 may include triggering an OS reboot from the current partition, starting with booting from the bootloader of the current partition 906 as described above 922.

[0106] If the initrd image loads successfully, the system can continue attempting to boot the current partition. If a kernel panic occurs while the current partition is still booting, method 900 may include triggering an OS reboot from the current partition, starting from booting from the current partition's bootloader, as described above, 906, 922. If no kernel panic occurs while the current partition is still booting, method 900 may include performing an OS boot using the current partition, 924. If a kernel failure or critical failure occurs, method 900 may include triggering an OS reboot from the current partition, starting from booting from the current partition's bootloader, as described above, 922. If no kernel failure or critical failure occurs, method 900 may include setting the boot attempt counter to 0, 926, and running the successfully booted OS, 928. Setting the boot counter to 0, 926, reflects that the OS has booted successfully.

[0107] Figure 10 shows one implementation of Method 1000 for performing automatic upgrades across multiple OS instances, in several implementation forms of this subject. Method 1000 is described in relation to the implementation forms in Figures 7 and 8 and the automatic fallback Method 900 in Figure 9 for ease of explanation, but it can be performed using other devices such as the device in Figure 6 and other methods of automatic fallback.

[0108] Method 1000 is performed while the OS is running on the device, such as after a successful boot according to Method 900 in Figure 9. As shown in Figure 10, Method 1000 can be initiated when an OS upgrade becomes available. In some implementations, OS upgrades may be available on a predetermined schedule, such as every six months or other time schedules, to provide atomic air-gap OS upgrades. In some implementations, OS upgrades may be available without any time schedule; for example, OS upgrades are made available as needed. In some implementations, some OS upgrades may be available on a predetermined schedule, while others may be available without any time schedule.

[0109] In method 1000, an available OS upgrade can trigger an upgrade 1002 of the standby partition in the background of the running OS (when booted from the current partition). The upgrade 1002 can be performed according to the requirements of a particular OS. For example, in the configuration of Figure 7, the upgrade 1002 may be for the second partition 708b. As another example, in the configuration of Figure 8, the upgrade 1002 may be for the first partition 708a. In device implementations with multiple memory, each containing multiple partitions, each of the standby partitions of the device can be upgraded 1002. For example, in the configuration of Figure 6, the upgrade 1002 may be for the second partition 604b of the first memory 602 and the second partition 608b of the second memory 606.

[0110] In response to the failure of upgrade 1002, upgrade 1002 may be attempted again. Upgrade 1002 can be attempted any number of times. An upgrade that was previously unsuccessful may succeed on a second attempt if the previous attempt failed due to a temporary problem such as a network failure or power outage, which has since been resolved. In some implementations, upgrade 1002 may be attempted only once. In some implementations, upgrade 1002 may be attempted any number of times within a predetermined period until the previously unsuccessful upgrade 1002 succeeds or until a predetermined period expires. In some implementations, upgrade 1002 may be attempted up to a predetermined number of times until upgrade 1002 succeeds or until upgrade 1002 fails and is attempted a predetermined number of times.

[0111] In response to the successful upgrade 1002, method 1000 may include changing the partition designation for the boot order 1004 so that the newly upgraded standby partition becomes the current partition. That is, the current partition is set to be this standby partition, this standby partition is designated as the active partition, and the previous active partition is set as the standby partition.

[0112] Following the modification of the partition designation 1004, method 1000 may include rebooting the OS using the current partition, for example, the newly upgraded partition 1006. Thus, the OS can automatically reboot in response to a successful OS upgrade, thereby enabling the device to run on the latest available OS.

[0113] In some implementations, this subject can be configured to be implemented in system 1100, as shown in Figure 11. System 1100 may include one or more of the following: processor 1110, memory 1120, storage device 1130, and input / output device 1140. Each of components 1110, 1120, 1130, and 1140 can be interconnected using system bus 1150. Processor 1110 can be configured to process instructions for execution within system 600. In some implementations, processor 1110 may be a single-threaded processor. In alternative implementations, processor 1110 may be a multi-threaded processor. Processor 1110 may be further configured to process instructions stored in memory 1120 or storage device 1130, which includes receiving or sending information through input / output device 1140. Memory 1120 can store information within system 1100. In some implementations, memory 1120 may be computer-readable media. In alternative implementations, memory 1120 may be a volatile memory unit. In some further implementations, memory 1120 may be a non-volatile memory unit. Storage device 1130 may be capable of providing large-capacity storage to system 1100. In some implementations, storage device 1130 may be a computer-readable medium. In alternative implementations, storage device 1130 may be a floppy disk device, a hard disk device, an optical disk device, a tape device, a non-volatile solid-state memory, or any other type of storage device. Input / output device 1140 may be configured to provide input / output operations to system 1100. In some implementations, input / output device 1140 may include a keyboard and / or a pointing device. In alternative implementations, input / output device 1140 may include a display unit for displaying a graphical user interface.

[0114] Figure 12 illustrates an exemplary method 1200 for automatic upgrades and fallbacks across multiple OS instances, based on several implementations of this subject. Method 1200 can be implemented, for example, using the implementations shown in Figures 6-8 and described with respect to Figures 6-8.

[0115] Method 1200 includes attempting to boot an OS from a first BIOS pre-stored in a first partition of the memory (e.g., a first memory 602 or second memory 606 in Figure 6, memory 702 in Figures 7 and 8, memory 1020 in Figure 12) of a communication device (e.g., a DU such as DU304 in Figure 3, or DU508 or 510 in Figures 5a to 5c) in a wireless communication system (e.g., a Long Term Evolution communication system, a new wireless communication system, etc.). The OS operates on the communication device in response to the OS successfully booting from the first BIOS. Method 1204 also includes automatically attempting to boot an OS from a second BIOS pre-stored in a second partition of the communication device's memory in response to the OS failing to successfully boot from the first BIOS.

[0116] In some implementations, this subject may include one or more of the following optional features.

[0117] In some implementations, the OS can operate on the communication device in response to the OS successfully booting from a second BIOS, and this method may further include automatically booting the OS from a third BIOS pre-stored in a third partition of the communication device's memory in response to the OS failing to successfully boot from the second BIOS. Furthermore, the third BIOS can be pre-stored in a third partition of memory during the manufacturing of the communication device. In addition, the first and second BIOSes can each be configured to be upgradeable, while the third BIOS cannot be upgraded.

[0118] In some implementations, the method may further include upgrading a second BIOS while the OS is running on the communication device, and automatically rebooting the OS from the upgraded second BIOS in response to the successful upgrade of the second BIOS. Furthermore, the method may further include upgrading the first BIOS after the reboot and while the OS is running on the communication device, and automatically rebooting the OS from the upgraded first BIOS in response to the successful upgrade of the first BIOS.

[0119] In some implementations, the first BIOS may be pre-stored in a first partition of memory during the manufacturing of the communication device, the second BIOS may be pre-stored in a second partition of memory during the manufacturing of the communication device, the second BIOS may be configured to be upgraded during the operation of an OS that has been successfully booted from the first BIOS, and the first BIOS may be configured to be upgraded during the operation of an OS that has been successfully booted from the second BIOS.

[0120] In some implementations, attempting to boot the OS from a first BIOS may include attempting to boot a first boot loader, and this method may further include automatically attempting to boot the OS from a second BIOS in response to a failure to boot the first boot loader, determining in response to a successful boot of the first boot loader whether the boot loader has been attempted to boot the communication device more than a predetermined threshold number of times, continuing the attempt to boot the OS from the first BIOS in response to determining that the boot loader has not been attempted to boot the communication device more than a predetermined threshold number of times, and automatically attempting to boot the OS from the second BIOS in response to determining that the boot loader has been attempted to boot the communication device more than a predetermined threshold number of times. Furthermore, this method continues to attempt to boot the OS from the first BIOS, then attempts to load the first kernel image of the first BIOS, triggers a reboot of the OS from the first BIOS in response to the first kernel image not loading successfully, and in response to the first kernel image loading successfully, the first kernel image of the first BIOS initrd Attempting to load an image, the first initrd In response to the image not loading correctly, trigger an OS reboot from the first BIOS, and the first initrdThe method may further include, in response to the successful loading of the image, continuing the attempt to boot the OS from the first BIOS, and / or, the attempt to boot the OS from the second BIOS may include the attempt to boot the second boot loader. The method may further include, in response to the failure to boot the second boot loader, automatically booting the OS from the third BIOS pre-stored in the third partition of the communication device's memory; in response to the successful booting of the second boot loader, determining whether the boot loader boot has been attempted more than a predetermined threshold number of times; in response to the determination that the boot loader boot has not been attempted more than a predetermined threshold number of times, continuing the attempt to boot the OS from the second BIOS; and in response to the determination that the boot loader boot has been attempted more than a predetermined threshold number of times, automatically attempting to boot the OS from the third BIOS. Furthermore, the third BIOS may be pre-stored in the third partition of memory during the manufacture of the communication device. Furthermore, the first BIOS and the second BIOS may each be configured to be upgradeable, while the third BIOS cannot be upgraded.

[0121] In some implementations, the communication device can be a distributed unit (DU).

[0122] In some implementations, at least one of the attempts and / or automatic attempts can be performed by a base station in the wireless communication system. Furthermore, the base station may include at least one of eNodeB base stations, gNodeB base stations, wireless base stations, and any combination thereof.

[0123] In some implementations, the wireless communication system may be at least one of the following: a long-term evolution communication system, a new wireless communication system, or any combination thereof.

[0124] The systems and methods disclosed herein can be embodied in various forms, including, for example, data processors such as computers, which may also include databases, digital electronic circuits, firmware, software, or combinations thereof. Furthermore, the above features, as well as other aspects and principles of the implementations of this disclosure, can be implemented in various environments. Such environments and associated applications may be specifically constructed to perform various processes and operations according to the disclosed implementations, or they may include general-purpose computers or computing platforms that are selectively activated or reconfigured by code to provide the necessary functionality. The processes disclosed herein are essentially independent of any particular computer, network, architecture, environment, or other device and can be carried out by a preferred combination of hardware, software, and / or firmware. For example, various general-purpose machines may be used with programs written according to the teachings of the disclosed implementations, or it may be more convenient to construct dedicated devices or systems to perform the required methods and techniques.

[0125] The systems and methods disclosed herein can be implemented as computer program products, i.e., computer programs tangibly embodied in information carriers, such as machine-readable storage devices or propagating signals, for execution by or control of the operation of data processing devices, such as programmable processors, computers, or multiple computers. Computer programs can be written in any form of programming language, including compiled or interpreted languages, and can be deployed as standalone programs or in any form, including modules, components, subroutines, or other units suitable for use in a computing environment. Computer programs can be deployed to run on a single computer, or on multiple computers distributed across multiple sites and interconnected by a communication network.

[0126] As used herein, the term "user" may refer to any entity, including a person or a computer.

[0127] Ordinal numbers such as "1st," "2nd," etc., may be related to order in some contexts, but as used in this document, ordinal numbers do not necessarily imply order. For example, ordinal numbers can be used simply to distinguish one item from another. For instance, distinguishing the first event from the second event does not imply any arbitrary chronological order or fixed reference system (such as the first event in one paragraph of the description being different from the first event in another paragraph of the description).

[0128] The foregoing description is intended to illustrate, and not to limit, the scope of the present invention as defined by the attached claims. Other implementations are within the scope of the following claims.

[0129] These computer programs, which may also be referred to as programs, software, software applications, applications, components, or code, include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages, and / or in assembly / machine language. As used herein, the term “machine-readable medium” means any computer program product, apparatus, and / or device, such as magnetic disks, optical disks, memory, and programmable logic devices (PLDs), used to provide machine instructions and / or data to a programmable processor, including machine-readable medium that receives machine instructions as machine-readable signals. The term “machine-readable signals” means any signals used to provide machine instructions and / or data to a programmable processor. The machine-readable medium may store such machine instructions non-temporarily, for example, non-temporarily stored solid-state memory or magnetic hard drives or any equivalent storage medium. The machine-readable medium may, alternatively or additionally, store such machine instructions temporarily, for example, a processor cache or other random-access memory associated with one or more physical processor cores.

[0130] To provide user interaction, the subjects described herein can be implemented on a computer having a display device, such as a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user, and a keyboard and pointing device, such as a mouse or trackball, to which the user can provide input to the computer. User interaction can also be provided using other types of devices. For example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including, but not limited to, acoustic, verbal, or tactile input.

[0131] The subject matter described herein may be implemented in a computing system including, for example, one or more backend components such as data servers, or middleware components such as one or more application servers, or frontend components such as one or more client computers having a graphical user interface or a web browser on which a user can interact with an implementation of the subject matter described herein, or in any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication, such as a communication network. Examples of communication networks include, but are not limited to, local area networks ("LANs"), wide area networks ("WANs"), and the Internet.

[0132] A computing system may include clients and servers. Clients and servers are generally, but not exclusively, separate from one another and typically interact via a communication network. The relationship between a client and a server arises from computer programs running on each computer that have a client-server relationship with one another.

[0133] The implementations described above do not represent all implementations that are consistent with the subject matter described herein. Rather, they are only some examples that are consistent with the aspects relating to the subject matter described herein. While several modifications have been described in detail above, other modifications or additions are possible. In particular, further features and / or variations can be provided in addition to those described herein. For example, the implementations described above may cover various combinations and partial combinations of the disclosed features, and / or combinations and partial combinations of some of the further features disclosed above. In addition, the logical flows shown in the accompanying figures and / or described herein do not necessarily require a specific order or sequence shown to achieve the desired result. Other implementations may be within the scope of the following claims.

Claims

1. An attempt to boot an operating system (OS) from a first basic input / output system (BIOS) pre-stored in a first partition of the memory of a communication device within a wireless communication system. A computer implementation method including, The OS operates on the communication device in response to the OS successfully booting from the first BIOS. The method further includes, in response to the OS failing to boot successfully from the first BIOS, automatically attempting to boot the OS from a second BIOS pre-stored in a second partition of the memory of the communication device, The second BIOS stores the boot order of multiple OS instances corresponding to multiple OS partitions, and dynamically changes the boot order stored in the second BIOS. Computer implementation method.

2. The OS operates on the communication device in response to the OS successfully booting from the second BIOS. The method further includes, in response to the OS failing to boot successfully from the second BIOS, automatically booting the OS from a third BIOS pre-stored in a third partition of the memory of the communication device. The method according to claim 1.

3. The third BIOS was pre-stored in the third partition of the memory during the manufacturing of the communication device. The method according to claim 2.

4. The first BIOS and the second BIOS are configured to be upgraded, The aforementioned third BIOS cannot be upgraded. The method according to claim 3.

5. The above method further, Upgrading the second BIOS while the OS is operating on the communication device, This includes automatically rebooting the OS from the upgraded second BIOS in response to the successful upgrade of the second BIOS, The method according to claim 1.

6. The above method further, Upgrading the first BIOS after the reboot and while the OS is operating on the communication device, This includes automatically rebooting the OS from the upgraded first BIOS in response to the successful upgrade of the first BIOS, The method according to claim 5.

7. The first BIOS is pre-stored in the first partition of the memory during the manufacturing of the communication device. The second BIOS is pre-stored in the second partition of the memory during the manufacturing of the communication device. The second BIOS is configured to be upgraded during the operation of the OS which was successfully booted from the first BIOS. The first BIOS is configured to be upgraded during the operation of the OS which was successfully booted from the second BIOS. The method according to claim 1.

8. Attempting to boot the OS from the first BIOS includes attempting to boot the first boot loader, The above method further, In response to the failure of the first boot loader to boot, the system automatically attempts to boot the OS from the second BIOS. In response to the successful booting of the first boot loader, the system determines whether the boot loader has been attempted to boot the communication device more than a predetermined threshold number of times. In response to determining that the boot loader has not been attempted to boot the communication device more than the predetermined threshold number of times, the attempt to boot the OS from the first BIOS is continued, and This includes, in response to determining that the boot loader has been attempted to boot the communication device more than the predetermined threshold number of times, automatically attempting to boot the OS from the second BIOS, The method according to claim 1.

9. The above method further, After continuing the attempt to boot the OS from the first BIOS, an attempt is made to load the first kernel image of the first BIOS. In response to the failure of the first kernel image to load successfully, trigger a reboot of the OS from the first BIOS. In response to the successful loading of the first kernel image, an attempt is made to load the first initializer image of the first BIOS. In response to the failure of the first initrd image to load successfully, trigger a reboot of the OS from the first BIOS, and This includes continuing the attempt to boot the OS from the first BIOS in response to the successful loading of the first initrd image, The method according to claim 8.

10. Attempting to boot the OS from the second BIOS includes attempting to boot the second boot loader, The above method further, In response to the failure of the second boot loader to boot, the OS is automatically booted from a third BIOS pre-stored in a third partition of the memory of the communication device. In response to the successful booting of the second boot loader, determine whether the boot loader has been attempted to boot more than the predetermined threshold number of times. In response to determining that the boot loader has not attempted to boot more than the predetermined threshold number of times, the second BIOS continues the attempt to boot the OS, and This includes, in response to determining that the booting of the second boot loader has been attempted more than the predetermined threshold number of times, automatically attempting to boot the OS from the third BIOS, The method according to claim 8.

11. The third BIOS was pre-stored in the third partition of the memory during the manufacturing of the communication device. The method according to claim 10.

12. The first BIOS and the second BIOS are configured to be upgraded, The aforementioned third BIOS cannot be upgraded. The method according to claim 11.

13. The aforementioned communication device is a distributed unit (DU). The method according to claim 1.

14. At least one of the aforementioned attempt and the aforementioned automatic attempt is performed by a base station in the wireless communication system. The method according to claim 1.

15. The base station includes at least one of the following: eNodeB base station, gNodeB base station, wireless base station, and any combination thereof. The method according to claim 14.

16. The wireless communication system is at least one of a long-term evolution communication system, a new wireless communication system, and any combination thereof. The method according to claim 1.

17. At least one processor, When executed by the at least one processor, the at least one processor, An attempt to boot an operating system (OS) from a first basic input / output system (BIOS) pre-stored in a first partition of the memory of a communication device within a wireless communication system. A non-temporary storage medium that stores instructions for performing an action including, A device equipped with, The OS operates on the communication device in response to the OS successfully booting from the first BIOS. The operation further includes, in response to the OS failing to boot successfully from the first BIOS, automatically attempting to boot the OS from a second BIOS pre-stored in a second partition of the communication device's memory, The second BIOS stores the boot order of multiple OS instances corresponding to multiple OS partitions, and dynamically changes the boot order stored in the second BIOS. Device.

18. The OS operates on the communication device in response to the OS successfully booting from the second BIOS. The operation further includes, in response to the OS failing to boot successfully from the second BIOS, automatically booting the OS from a third BIOS pre-stored in a third partition of the communication device's memory. The apparatus according to claim 17.

19. The third BIOS was pre-stored in the third partition of the memory during the manufacturing of the communication device. The apparatus according to claim 18.

20. The first BIOS and the second BIOS are configured to be upgraded, The aforementioned third BIOS cannot be upgraded. The apparatus according to claim 19.

21. The aforementioned operation further, Upgrading the second BIOS while the OS is operating on the communication device, This includes automatically rebooting the OS from the upgraded second BIOS in response to the successful upgrade of the second BIOS, The apparatus according to claim 17.

22. The aforementioned operation further, Upgrading the first BIOS after the reboot and while the OS is operating on the communication device, This includes automatically rebooting the OS from the upgraded first BIOS in response to the successful upgrade of the first BIOS, The apparatus according to claim 21.

23. The first BIOS is pre-stored in the first partition of the memory during the manufacturing of the communication device. The second BIOS is pre-stored in the second partition of the memory during the manufacturing of the communication device. The second BIOS is configured to be upgraded during the operation of the OS which was successfully booted from the first BIOS. The first BIOS is configured to be upgraded during the operation of the OS which was successfully booted from the second BIOS. The apparatus according to claim 17.

24. Attempting to boot the OS from the first BIOS includes attempting to boot the first boot loader, The aforementioned operation further, In response to the failure of the first boot loader to boot, the system automatically attempts to boot the OS from the second BIOS. In response to the successful booting of the first boot loader, the system determines whether the boot loader has been attempted to boot the communication device more than a predetermined threshold number of times. In response to determining that the boot loader has not been attempted to boot the communication device more than the predetermined threshold number of times, the attempt to boot the OS from the first BIOS is continued, and This includes, in response to determining that the boot loader has been attempted to boot the communication device more than the predetermined threshold number of times, automatically attempting to boot the OS from the second BIOS, The apparatus according to claim 17.

25. The aforementioned operation further, After continuing the attempt to boot the OS from the first BIOS, an attempt is made to load the first kernel image of the first BIOS. In response to the failure of the first kernel image to load successfully, the system triggers a reboot of the OS from the first BIOS. In response to the successful loading of the first kernel image, an attempt is made to load the first initializer image of the first BIOS. In response to the failure of the first initrd image to load successfully, trigger a reboot of the OS from the first BIOS, and This includes continuing the attempt to boot the OS from the first BIOS in response to the successful loading of the first initrd image, The apparatus according to claim 24.

26. Attempting to boot the OS from the second BIOS includes attempting to boot the second boot loader, The aforementioned operation further, In response to the failure of the second boot loader to boot, the OS is automatically booted from a third BIOS pre-stored in a third partition of the memory of the communication device. In response to the successful booting of the second boot loader, determine whether the boot loader has been attempted to boot more than the predetermined threshold number of times. In response to determining that the boot loader has not attempted to boot more than the predetermined threshold number of times, the second BIOS continues the attempt to boot the OS, and This includes, in response to determining that the booting of the second boot loader has been attempted more than the predetermined threshold number of times, automatically attempting to boot the OS from the third BIOS, The apparatus according to claim 24.

27. The third BIOS was pre-stored in the third partition of the memory during the manufacturing of the communication device. The apparatus according to claim 26.

28. The first BIOS and the second BIOS are configured to be upgraded, The aforementioned third BIOS cannot be upgraded. The apparatus according to claim 27.

29. The aforementioned communication device is a distributed unit (DU). The apparatus according to claim 17.

30. At least one of the aforementioned attempt and the aforementioned automatic attempt is performed by a base station in the wireless communication system. The apparatus according to claim 17.

31. The base station includes at least one of the following: eNodeB base station, gNodeB base station, wireless base station, and any combination thereof. The apparatus according to claim 30.

32. The wireless communication system is at least one of a long-term evolution communication system, a new wireless communication system, and any combination thereof. The apparatus according to claim 17.

33. When executed by at least one processor, the at least one processor, An attempt to boot an operating system (OS) from a first basic input / output system (BIOS) pre-stored in a first partition of the memory of a communication device within a wireless communication system. A non-temporary storage medium that stores instructions for performing an operation including, The OS operates on the communication device in response to the OS successfully booting from the first BIOS. The operation further includes, in response to the OS failing to boot successfully from the first BIOS, automatically attempting to boot the OS from a second BIOS pre-stored in a second partition of the communication device's memory, The second BIOS stores the boot order of multiple OS instances corresponding to multiple OS partitions, and dynamically changes the boot order stored in the second BIOS. Non-transitory storage medium.

34. The OS operates on the communication device in response to the OS successfully booting from the second BIOS. The operation further includes, in response to the OS failing to boot successfully from the second BIOS, automatically booting the OS from a third BIOS pre-stored in a third partition of the communication device's memory. The storage medium according to claim 33.

35. The third BIOS was pre-stored in the third partition of the memory during the manufacturing of the communication device. The storage medium according to claim 34.

36. The first BIOS and the second BIOS are configured to be upgraded, The aforementioned third BIOS cannot be upgraded. The storage medium according to claim 35.

37. The aforementioned operation further, Upgrading the second BIOS while the OS is operating on the communication device, This includes automatically rebooting the OS from the upgraded second BIOS in response to the successful upgrade of the second BIOS, The storage medium according to claim 33.

38. The aforementioned operation further, Upgrading the first BIOS after the reboost and during the operation of the OS on the communication device, This includes automatically rebooting the OS from the upgraded first BIOS in response to the successful upgrade of the first BIOS, The storage medium according to claim 37.

39. The first BIOS is pre-stored in the first partition of the memory during the manufacturing of the communication device. The second BIOS is pre-stored in the second partition of the memory during the manufacturing of the communication device. The second BIOS is configured to be upgraded during the operation of the OS which was successfully booted from the first BIOS. The first BIOS is configured to be upgraded during the operation of the OS which was successfully booted from the second BIOS. The storage medium according to claim 33.

40. Attempting to boot the OS from the first BIOS includes attempting to boot the first boot loader, The aforementioned operation further, In response to the failure of the first boot loader to boot, the system automatically attempts to boot the OS from the second BIOS. In response to the successful booting of the first boot loader, the system determines whether the boot loader has been attempted to boot the communication device more than a predetermined threshold number of times. In response to determining that the boot loader has not been attempted to boot the communication device more than the predetermined threshold number of times, the attempt to boot the OS from the first BIOS is continued, and This includes, in response to determining that the boot loader has been attempted to boot the communication device more than the predetermined threshold number of times, automatically attempting to boot the OS from the second BIOS, The storage medium according to claim 33.

41. The aforementioned operation further, After continuing the attempt to boot the OS from the first BIOS, an attempt is made to load the first kernel image of the first BIOS. In response to the failure of the first kernel image to load successfully, trigger a reboot of the OS from the first BIOS. In response to the successful loading of the first kernel image, an attempt is made to load the first initializer image of the first BIOS. In response to the failure of the first initrd image to load successfully, trigger a reboot of the OS from the first BIOS, and This includes continuing the attempt to boot the OS from the first BIOS in response to the successful loading of the first initrd image, The storage medium according to claim 40.

42. Attempting to boot the OS from the second BIOS includes attempting to boot the second boot loader, The aforementioned operation further, In response to the failure of the second boot loader to boot, the OS is automatically booted from a third BIOS pre-stored in a third partition of the memory of the communication device. In response to the successful booting of the second boot loader, determine whether the boot loader has been attempted to boot more than the predetermined threshold number of times. In response to determining that the boot loader has not attempted to boot more than the predetermined threshold number of times, the second BIOS continues the attempt to boot the OS, and This includes, in response to determining that the booting of the second boot loader has been attempted more than the predetermined threshold number of times, automatically attempting to boot the OS from the third BIOS, The storage medium according to claim 40.

43. The third BIOS was pre-stored in the third partition of the memory during the manufacturing of the communication device. The storage medium according to claim 42.

44. The first BIOS and the second BIOS are configured to be upgraded, The aforementioned third BIOS cannot be upgraded. The storage medium according to claim 43.

45. The aforementioned communication device is a distributed unit (DU). The storage medium according to claim 33.

46. At least one of the attempt and the automatic attempt is performed by a base station in the wireless communication system The storage medium according to claim 33.

47. The base station includes at least one of an eNodeB base station, a gNodeB base station, a wireless base station, and any combination thereof. The storage medium according to claim 46.

Images