State Messaging Protocol

Abstract

To provide a method and a device for achieving timing synchronization to ensure a functionality of an air interface.SOLUTION: A method executed in a first communication device of a radio access network (RAN) includes the steps related to at least one of a layer 1 and a layer 2, which includes a step of detecting an event, a step of generating a notification including an identifier related to the detected event on the basis of a predetermined protocol that specifies an identifier related to the detected event, and a step of transmitting the notification to a second communication device of the radio access network (RAN) so as to cause an action corresponding to the event on the basis of the identifier.SELECTED DRAWING: Figure 13

Description

[Technical Field]

[0001] In some embodiments, the subject matter of protection relates to telecommunications systems, and in particular to wireless synchronization state messaging protocols between various communication units (e.g., distributed units, wireless units, etc.) in wireless communication systems, such as 5G New Radio ("NR"). [Background technology]

[0002] In today's world, cellular networks provide on-demand communication capabilities to individuals and businesses. Typically, cellular networks are wireless networks that can be distributed over multiple terrestrial regions, called cells. Each such cell is served by at least one fixed-location transceiver, called a cell site or base station. Each cell may use a different set of frequencies from 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 geographic area, allowing numerous mobile phones and / or other wireless devices or portable transceivers to communicate with each other and with fixed transceivers or phones anywhere in the network. Such communication occurs through base stations, even when the mobile transceiver is traveling through two or more cells during transmission. Major wireless communication providers deploy such cell sites worldwide, enabling mobile phones and mobile computing devices to connect to the public switched telephone network and the public Internet.

[0003] A mobile phone is a portable telephone that can receive and / or make telephone and / or data calls through a cell site or transmission tower by using radio waves to transmit signals between these phones. Given the large number of mobile phone users, current mobile phone networks offer limited shared resources. In this regard, cell sites and handsets can change frequencies and use low-power transmitters to allow simultaneous use of the network by many callers with less interference. Cell site coverage may depend on the specific geographic 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 1 / 2 mile, while in rural areas, the distance may be as long as 5 miles. In some areas, users can receive signals from cell sites as far away as 25 miles.

[0004] Examples of some digital cellular technologies used by communication providers are: Global System for Mobile Communications ("GSM"), General Packet Radio Service ("GPRS"), cdmaOne, CDMA2000, Evolution-Data Optimized ("EV-DO"), Enhanced Data Rates for GSM Evolution ("EDGE"), Universal Mobile Telecommunications System ("UMTS"), Digital Enhanced Cordless Telecommunications ("DECT"), Digital AMPS ("IS-136 / TDMA"), and Integrated Digital Enhanced Network ("iDEN"). Long Term Evolution, or 4G LTE, developed by the 3rd Generation Partnership Project ("3GPP") standards organization, is a standard for high-speed data wireless communications for mobile phones and data terminals. 5G LTE standards are currently being developed and deployed. LTE is based on GSM / EDGE and UMTS / HSPA digital cellular technologies and allows for increased capacity and speeds by using a different air interface along with core network improvements.

[0005] Mobile devices are used to receive and send various types of data, such as voice data (e.g., calls), email, text messages, internet browsing, video data (e.g., videos, video calls, augmented / virtual reality, etc.), audio data (e.g., streaming songs), etc. Different types of data may require different transmission bandwidths. For example, playing high-definition video on a mobile device with good quality may require a higher bandwidth than sending email or text messages to the mobile device.

[0006] To ensure proper efficiency and proper functioning of the air interface, 5G NR networks implement various frequency and timing requirements, but currently implemented protocols are unable to provide effective timing synchronization to base stations. Summary of the Invention [Means for solving the problem]

[0007] In some embodiments, the subject matter covered relates to a computer-implemented method for wireless synchronized state messaging between communication units in a wireless communication system, the method may include detecting, by one or more first communication devices, a change in a state event, generating a message indicating the detected change in the state event, and transmitting the generated message to one or more second communication devices.

[0008] In some embodiments, the protected subject matter may include one or more of the following optional features: The communications device may include at least one of the following: a base station, a gNodeB base station, an eNodeB base station, and any combination thereof. In particular, the communications device may include at least one of the following: one or more distributed units, one or more radio units, and any combination thereof. Furthermore, in some embodiments, the remote unit may generate a message and transmit the generated message to one or more distributed units. Alternatively or additionally, the distributed unit may generate a message and transmit the generated message to one or more remote units.

[0009] In some embodiments, the message may be a Layer 2 message frame configured to be transmitted from one or more Layer 2 components of one or more first communication devices to one or more Layer 2 components of one or more second communication devices. The Layer 2 message may include at least one of the following: an identifier of an origin of the Layer 2 message, an identifier of a type of origin of the Layer 2 message, an identifier of a destination of the Layer 2 message, an identifier of a type of destination of the Layer 2 message, an identifier of a type of Layer 2 message, data corresponding to a change in state event, and any combination thereof. Furthermore, the data corresponding to a change in state event may include at least one of the following: a precision timing protocol clock state, a synchronous Ethernet clock state, a time error state, a precision timing protocol setting, a synchronous Ethernet setting, one or more commands, one or more settings, and any combination thereof. The data corresponding to a change in state event may include at least one of the following: a time elapsed since detection of a preceding change in state event, a phase offset setting, a frequency offset setting, and any combination thereof.

[0010] In some embodiments, the method may include performing, by the second communication device, one or more actions based on the received message.

[0011] In some embodiments, the message may be a multicast message configured to be received by one or more second communication devices in substantially real time.

[0012] Non-transitory computer program products (i.e., physically embodied computer program products) are also described that have stored thereon instructions that, when executed by one or more data processors of one or more computing systems, cause at least one data processor to perform the operations described herein. Similarly, it is also described that a computer system may include one or more data processors and memory coupled to the one or more data processors. The memory may store, either temporarily or permanently, instructions that cause at least one processor to perform one or more of the operations described herein. Additionally, the methods 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 connectable and may exchange data and / or commands or other instructions, etc., via one or more connections, including, but not limited to, connections over a network (e.g., the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, etc.).

[0013] The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will become apparent from the description and drawings, and from the claims.

[0014] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate certain aspects of the subject matter disclosed herein and, together with the description, help explain certain principles related to the disclosed embodiments. [Brief explanation of the drawings]

[0015] [Figure 1a] FIG. 1 illustrates an exemplary conventional Long Term Evolution (“LTE”) communication system. [Figure 1b] FIG. 1b illustrates further details of the exemplary LTE system shown in FIG. 1a. [Figure 1c] FIG. 1b illustrates additional details of the evolved packet core of the exemplary LTE system shown in FIG. 1a. [Figure 1d] FIG. 1b illustrates an exemplary evolved Node B for the exemplary LTE system shown in FIG. 1a. [Figure 2] FIG. 2 shows further details of the evolved Node B shown in FIGS. 1a-1d. [Figure 3] 1 illustrates an exemplary virtual radio access network in accordance with some embodiments of the present protected subject matter. [Figure 4] FIG. 1 illustrates an exemplary 3GPP split architecture for providing users with access to higher frequency bands. [Figure 5] FIG. 1 illustrates an exemplary 5G wireless communication system. [Figure 6] FIG. 1 illustrates a 5G wireless communication system in accordance with some embodiments of the present subject matter. [Figure 7a] FIG. 1 illustrates a user plane protocol stack. [Figure 7b] FIG. 1 illustrates a control plane protocol stack. [Figure 8] FIG. 1 illustrates an exemplary wireless synchronization status messaging protocol system in accordance with some embodiments of the present protected subject matter. [Figure 9] FIG. 1 illustrates an example communication system that can be configured to implement the NETCONF / YANG notification protocol. [Figure 10] FIG. 1 illustrates an exemplary communication system that can be configured to implement a wireless synchronous messaging protocol in accordance with some embodiments of the present subject matter. [Figure 11] 11 illustrates an example process 1100 for wireless synchronous messaging in accordance with some embodiments of the present subject matter. [Figure 12]FIG. 1 illustrates an exemplary system according to some embodiments of the present subject matter. [Figure 13] FIG. 1 illustrates an exemplary method according to some embodiments of the present subject matter. DETAILED DESCRIPTION OF THE INVENTION

[0016] The subject matter may provide systems and methods that can be implemented in a lower layer split architecture for wireless communication systems, including various wireless communication systems, including 5G New Radio communications systems, Long Term Evolution communications systems, and the like.

[0017] One or more aspects of the subject matter may be incorporated within transmitter and / or receiver components of a base station (e.g., gNodeB, eNodeB, etc.) in such a communication system. The following is a general discussion of Long Term Evolution and 5G emerging communication systems.

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

[0019] As shown in FIG. 1a, system 100 may include an Evolved Universal Terrestrial Radio Access Network (“EUTRAN”) 102, an Evolved Packet Core (“EPC”) 108, and a Packet Data Network (“PDN”) 101, where EUTRAN 102 and EPC 108 provide communications between user equipment 104 and PDN 101. EUTRAN 102 may include multiple evolved Node Bs (“eNodeB” or “ENODEB” or “enodeb” or “eNB”) or base stations 106(a, b, c) (shown in FIG. 1b) that provide communications capabilities to multiple user equipment 104(a, b, c). User equipment 104 may be a mobile phone, a smartphone, a tablet, a personal computer, a personal digital assistant (“PDA”), a server, a data terminal, and / or any other type of user equipment, and / or any combination thereof. User equipment 104 can connect to the EPC 108 and ultimately to the PDN 101 through any eNodeB 106. Typically, the user equipment 104 can connect to the eNodeB 106 that is closest in distance. In the LTE system 100, the EUTRAN 102 and the EPC 108 cooperate to provide connectivity, mobility, and services to the user equipment 104.

[0020] Figure 1b shows further details of the network 100 shown in Figure 1a. As mentioned above, the EUTRAN 102 includes multiple eNodeBs 106, also known as cell sites. The eNodeBs 106 provide radio functionality and perform key control functions, including scheduling of air link or radio resource management, active mode mobility or handover, and admission control for services. The eNodeBs 106 are responsible for selecting which mobility management entity (MME, as shown in Figure 1c) will serve the user equipment 104, as well as protocol functions such as header compression and encryption. The eNodeBs 106 that make up the EUTRAN 102 cooperate with each other for radio resource management and handover.

[0021] Communication between the user equipment 104 and the eNodeB 106 occurs over an air interface 122 (also known as the "LTE-Uu" interface). As shown in FIG. 1b, the air interface 122 provides communication between the user equipment 104b and the eNodeB 106a. The air interface 122 uses orthogonal frequency division multiple access ("OFDMA") and single-carrier frequency division multiple access ("SC-FDMA"), a variant of OFDMA, on the downlink and uplink, respectively. OFDMA can use multiple known antenna technologies, such as multiple-input multiple-output ("MIMO").

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

[0023] Multiple eNodeBs 106 can interconnect with each other using X2 interfaces 130(a, b, c). As shown in FIG. 1b, the X2 interface 130a provides interconnection between the eNodeBs 106a and 106b, the X2 interface 130b provides interconnection between the eNodeBs 106a and 106c, and the X2 interface 130c provides interconnection between the eNodeBs 106b and 106c. The X2 interfaces can be established between two eNodeBs to provide for the exchange of signals that can include information about loading or interference as well as handovers. The eNodeBs 106 communicate with the evolved packet core 108 via the S1 interfaces 124(a, b, c). The S1 interface 124 can be divided into two interfaces: one for the control plane (shown in FIG. 1c as control plane interface (S1-MME interface) 128) and the other for the user plane (shown in FIG. 1c as user plane interface (S1-U interface) 125).

[0024] The EPC 108 establishes and enforces quality of service ("QoS") for user services and enables user equipment 104 to maintain a consistent Internet Protocol ("IP") address while moving. It should be noted that each node in the network 100 has its own IP address. The EPC 108 is designed to interwork with legacy wireless networks. The EPC 108 is also designed to separate the control plane (i.e., signaling) and user plane (i.e., traffic) in the core network architecture, which allows for greater flexibility in implementation and independent scalability of control and user data functions.

[0025] The EPC 108 architecture is dedicated to packet data and is shown in more detail in Figure 1c. The EPC 108 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 (the subscriber database for the EPC 108), and a Policy Control and Charging Rules Function ("PCRF") 118. Some of these (such as the S-GW, P-GW, MME, and HSS) are often combined into multiple nodes according to manufacturer implementations.

[0026] The S-GW 110 functions as an IP packet data router and is the bearer path anchor for the user equipment within the EPC 108. Thus, when the user equipment moves from one eNodeB 106 to another during mobility operation, the S-GW 110 remains the same and the bearer path towards the EUTRAN 102 is switched to the new eNodeB 106 serving the user equipment 104. If the user equipment 104 moves to the domain of a different S-GW 110, the MME 114 forwards all of the user equipment's bearer paths to the new S-GW. This S-GW 110 establishes a bearer path for the user equipment to one or more P-GWs 112. When downstream data is received for an idle user equipment, the S-GW 110 buffers the downstream packets and requests the MME 114 to locate and re-establish the bearer path to and through the EUTRAN 102.

[0027] The P-GW 112 is the gateway between the EPC 108 (and user equipment 104 and EUTRAN 102) and the PDN 101 (shown in FIG. 1a). The P-GW 112 acts as a router for user traffic and performs functions on behalf of the user equipment. These include IP address allocation for the user equipment, packet filtering of downstream user traffic to ensure it is placed on the appropriate bearer path, and enforcement of downstream QoS, including data rate. Depending on the services a subscriber is using, there may be multiple user data bearer paths between the user equipment 104 and the P-GW 112. A subscriber may use services on the PDN served by different P-GWs, in which case the user equipment has at least one bearer path established to each P-GW 112. During a handover of user equipment from one eNodeB to another, if the S-GW 110 also changes, the bearer path from the P-GW 112 switches to the new S-GW.

[0028] The MME 114 manages the user equipment 104 in the EPC 108, including managing subscriber authentication, maintaining context for authenticated user equipment 104, establishing a data bearer path within the network for user traffic, and keeping track of the location of idle mobiles that are not detached from the network. For idle user equipment 104 that needs to reconnect to the access network to receive downstream data, the MME 114 initiates paging to locate the user equipment and reestablishes a bearer path to and through the EUTRAN 102. The MME 114 for a particular user equipment 104 is selected by the eNodeB 106 through which the user equipment 104 initiates system access. This MME is typically part of a collection of MMEs in the EPC 108 for load sharing and redundancy purposes. During the establishment of a user's data bearer path, the MME 114 is responsible for selecting the P-GW 112 and S-GW 110 that constitute the termination of the data path through the EPC 108.

[0029] The PCRF 118 is responsible for policy control decision making and control of flow-based charging functions in the Policy Control Enforcement Function ("PCEF") residing in the P-GW 110. The PCRF 118 determines how to treat a particular data flow in the PCEF, providing QoS authorization (QoS Class Identifier ("QCI") and bit rate) to ensure that it adheres to the user's subscription profile.

[0030] As mentioned above, IP services 119 are provided by PDN 101 (as shown in FIG. 1a).

[0031] 1d shows an example structure of an eNodeB 106. The eNodeB 106 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 connectable using an optical interface that conforms to the Common Public Radio Interface (“CPRI”) 142 standard specification. The eNodeB 106 operates according to the following standard parameters (and specifications): radio frequency band (Band 4, Band 9, Band 17), bandwidth (5, 10, 15, 20 MHz), access scheme (downlink: OFDMA; uplink: SC-OFDMA), antenna technology (downlink: 2x2 MIMO; uplink: 1x2 Single Input Multiple Output (“SIMO”)), number of sectors (up to 6), maximum transmit power (60 W), maximum transmission rate (downlink: 150 Mb / s; uplink: 50 Mb / s), S1 / X2 interface (100 The BBU 134 can be characterized using various standards (1000Base-SX, 1000Base-T) and mobile environments (up to 350 km / h). The BBU 134 can handle digital baseband signal processing, S1 line termination, X2 line termination, call processing, and supervisory control processing. (Not shown in FIG. 1d) IP packets received from the EPC 108 can be modulated into digital baseband signals and transmitted to the RRH 132. Conversely, digital baseband signals received from the RRH 132 can be demodulated into IP packets for transmission to the EPC 108.

[0032] The RRH 132 can transmit and receive wireless signals using an antenna 136. The RRH 132 can convert (using a converter (“CONV”) 140) digital baseband signals from the BBU 134 to radio frequency (“RF”) signals and power amplify them (using an amplifier (“AMP”) 138) for transmission to the user equipment 104 (not shown in FIG. 1d). Conversely, RF signals received from the user equipment 104 are amplified (using AMP 138) and converted (using CONV 140) to digital baseband signals for transmission to the BBU 134.

[0033] FIG. 2 illustrates additional details of an exemplary eNodeB 106. The eNodeB 106 includes multiple layers: 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 media 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, connection mobility control, and radio resource management ("RRM"). The RLC protocol is an automatic repeat request ("ARQ") fragmentation protocol used over the cellular air interface. The RRC protocol handles LTE Layer 3 control plane signaling between user equipment and the EUTRAN. The RRC includes functions for connection establishment and release, system information broadcast, radio bearer establishment / reconfiguration and release, RRC connection mobility procedures, paging notification and release, and outer loop power control. The PDCP performs IP header compression and decompression for radio bearers, user data transfer, and sequence number maintenance. The BBU 134 shown in Figure 1d may include LTE layers L1-L3.

[0034] One of the primary functions of the eNodeB 106 is radio resource management, which includes scheduling both uplink and downlink air interface resources for user equipment 104, control of bearer resources, and admission control. As agents for the EPC 108, the eNodeB 106 is responsible for forwarding paging messages used for locating idle mobiles. The eNodeB 106 also communicates common control channel information over the air, performs header compression, encryption and decryption of user data transmitted over the air, and establishes handover reporting and trigger criteria. As mentioned above, the eNodeB 106 can cooperate with other eNodeBs 106 over the X2 interface for handover and interference management purposes. The eNodeB 106 communicates with the MME of the EPC over the S1-MME interface and with the S-GW with the S1-U interface. Furthermore, the eNodeB 106 exchanges user data with the S-GW over the S1-U interface. The eNodeBs 106 and the EPC 108 have a many-to-many relationship to support load sharing and redundancy among multiple MMEs and S-GWs. The eNodeB 106 selects one MME from a group of MMEs so that the load can be shared among multiple MMEs to avoid congestion.

[0035] II. 5G NR Wireless Communication Network In some embodiments, the protected subject matter relates to 5G New Radio ("NR") communication systems. 5G NR is a next-generation communication standard that exceeds the 4G / IMT-Advanced standard. 5G networks offer higher capacity than current 4G, allowing for a greater number of mobile broadband users per area, and enabling consumption of larger and / or unlimited amounts of data per gigabyte per month and per user. This allows users to stream high-definition media for hours per day using their mobile devices, even in the absence of a Wi-Fi network. 5G networks offer improved support for device-to-device communication, lower costs, lower latency than 4G equipment, and lower battery consumption. Such networks have data rates of tens of megabits per second for many users, data rates of 100 Mb / s for large metropolitan areas, 1 Gb / s simultaneous connections for users within a limited area (e.g., an office floor), many simultaneous connections for wireless sensor networks, improved spectral efficiency, improved coverage, improved signaling efficiency, and latencies of 1-10 ms, a reduced latency compared to existing systems.

[0036] 3 illustrates an exemplary virtual radio access network 300. This network 300 can provide communication between various components, including a base station (e.g., eNodeB, gNodeB) 301, radio equipment 307, a centralized unit 302, a digital unit 304, and a wireless device 306. The components in the system 300 can be communicatively coupled to a core using a backhaul link 305. The centralized unit ("CU") 302 can be communicatively coupled to a distributed unit ("DU") 304 using a midhaul connection 308. The radio frequency ("RU") component 306 can be communicatively coupled to the DU 304 using a fronthaul connection 310.

[0037] In some embodiments, the CU 302 may provide intelligent communication capabilities to one or more DU units 304. The units 302, 304 may include one or more base stations, macro base stations, micro base stations, remote radio heads, etc., and / or any combination thereof.

[0038] In a lower layer split architecture environment, the CPRI bandwidth requirement for NR can be several hundred Gb / s. CPRI compression can be achieved within the DU and RU (as shown in Figure 3). In 5G communication systems, compressed CPRI over Ethernet frames is referred to as eCPRI and is the recommended fronthaul interface. This architecture can enable fronthaul / midhaul standardization, which can include higher layer splitting (e.g., Option 2 or Option 3-1 (upper / lower RLC split architecture)) and fronthaul with L1 split architecture (Option 7).

[0039] In some embodiments, the lower layer split architecture (e.g., Option 7) can include receivers in the uplink, joint processing across multiple transmission points (TPs) for both DL / UL, and transport bandwidth and latency requirements to facilitate deployment. Additionally, the protected lower layer split architecture can include a split between cell-level processing and user-level processing, which can include cell-level processing at a remote unit ("RU") and user-level processing at a DU. Additionally, by using the protected lower layer split architecture, frequency-domain samples can be transported over the Ethernet fronthaul, where they can be compressed for reduced fronthaul bandwidth.

[0040] 4 illustrates an exemplary communication system 400 that may implement 5G technology and provide users with access to higher frequency bands (e.g., above 10 GHz). The system 400 may include a macro cell 402 and small cells 404 and 406.

[0041] The mobile device 408 can be configured to communicate with one or more of the small cells 404, 406. The system 400 can enable control plane (C-plane) and user plane (U-plane) splitting between the macro cell 402 and the small cells 404, 406, where the C-plane and U-plane utilize different frequency bands. In particular, the small cells 402, 406 can be configured to utilize higher frequency bands when communicating with the mobile device 408. The macro cell 402 can utilize existing cellular bands for C-plane communications. The mobile device 408 can be communicatively coupled via the U-plane 412, where the small cells (e.g., the small cell 406) can provide higher data rates and more flexible, cost-effective, and energy-efficient operation. The macro cell 402 can maintain good connectivity and mobility via the C-plane 410. Furthermore, in some cases, the LTE PUCCH and the NR PUCCH can be transmitted on the same frequency.

[0042] FIG. 5 illustrates an exemplary 5G wireless communication system 500 according to some embodiments of the present protected subject matter. The system 500 may be configured to have a lower layer split architecture according to Option 7-2. The system 500 may include a core network 502 (e.g., 5G Core) and one or more gNodeBs (or gNBs), which 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 specified 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.

[0043] The control plane portion 504 and user plane portion 506 of the centralized unit of the gNB can be configured to be communicatively coupled to one or more distributed units (DUs) 508, 510 according to a lower layer split architecture. The distributed units 508, 510 can be configured to execute upper portions of the RLC, MAC, and PHY layer protocols of the radio stack. The control plane portion 504 can be configured to be communicatively coupled to the distributed units 508, 510 using an F1-C communication interface 516, and the user plane portion 506 can be configured to be communicatively coupled to the distributed units 508, 510 using an F1-U communication interface 518. The distributed units 508, 510 can be coupled to one or more remote radio units (RUs) 512 via a fronthaul interface 520, which in turn communicate with one or more user equipment (UE) devices (not shown in FIG. 5). The remote radio unit 512 may be configured to execute lower portions of the PHY layer protocol as well as provide the remote unit with antenna functionality for communicating with user equipment (similar to the discussion above in connection with Figures 1a-2).

[0044] Figure 6 illustrates a 5G wireless communication system 600 in accordance with some embodiments of the presently protected subject matter. This system 600 may be part of the system 500 illustrated in Figure 5. The system 600 may be configured to include one or more centralized units (CUs) 602, one or more distributed units (DUs) 604(a, b), one or more radio units (RUs) 606(a, b, c), and one or more remote radio heads (RRHs) 608(a, b, c, d, e, f). These units 602-608 may be communicatively coupled using one or more interfaces as described above.

[0045] In some embodiments, the CU 602 can be communicatively coupled to the DU 604a and the DU 604b. The distributed unit 604a can then be communicatively coupled to the remote units 606a and 606b, such that the unit 606a can be coupled to two remote radio heads 608a and 608b, and the unit 606b can be coupled to one remote radio head 608c. The distributed unit 604b can then be coupled to the remote unit 606c, which is then coupled to three remote radio heads 608d, 608e, and 608f. The system 600 shown in FIG. 6 may be configured as a virtualized and personalized radio access network (RAN) architecture, whereby layers L1, L2, L3, and radio processing can be virtualized and personalized in the centralized unit, the distributed unit, and the radio units.

[0046] 7a-7b show further details of example protocol stacks in a 5G wireless communication system. In particular, FIG. 7a shows a user plane protocol stack 700, and FIG. 7b shows a control plane protocol stack 710. Portions of the protocol stacks are shown for both an example user equipment 702 and a base station (or portion thereof), e.g., a gNodeB or gNB, 704. The user plane protocol stack 700 may include PHY, MAC, RLC, and PDCP layers. The control plane protocol stack 710 may include PHY, MAC, RLC, PDCP, RRC, and NAS (non-access stratum, a portion of which may be incorporated within the 5G core control network 706 as shown in FIG. 7b).

[0047] The protocol stack may include Layer 1, Layer 2, and Layer 3. Layer 1 is the physical layer (PHY). Layer 2 may include MAC, RLC, and PDCP. Layer 3 is the RRC layer as shown in Figures 7a-7b.

[0048] Some of the functions of the PHY layer in a 5G communication network include error detection in transport channels and indicating to higher layers, FEC encoding / decoding of transport channels, hybrid ARQ soft combining, 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, measuring radio characteristics and indicating to higher layers, MIMO antenna processing, digital and analog beamforming, RF processing, and other functions.

[0049] The Layer 2 MAC sublayer may perform beam management, random access procedures, mapping between logical channels and transport channels, concatenation of multiple MAC service data units (SDUs) belonging to one logical channel into transport blocks (TBs), multiplexing / demultiplexing of SDUs belonging to logical channels to / from TBs delivered to / from the physical layer on transport channels, reporting scheduling information, error correction using HARQ, prioritizing between logical channels for one UE, prioritizing between UEs using dynamic scheduling, transport format selection, and other functions. The RLC sublayer's functions may include forwarding upper layer packet data units (PDUs), error correction using ARQ, reordering of data PDUs, duplication and protocol error detection, reestablishment, etc. The PDCP sublayer may be responsible for forwarding user data, various functions during reestablishment procedures, retransmission of SDUs, discarding SDUs in the uplink, forwarding control plane data, etc.

[0050] The RRC sublayer of Layer 3 may perform the following functions: broadcasting system information to NASs and ASs, establishing, maintaining and releasing RRC connections, security, establishment, configuration, maintenance and release of point-to-point radio bearers, mobility functions, reporting and other functions.

[0051] III. Messaging Protocols In some embodiments, the protected object can be configured to provide a real-time messaging communication protocol system between DUs and RUs, e.g., regarding events such as frequency and timing synchronization, to ensure that the communication system 600 shown in FIG. 6 operates efficiently and effectively. Such a timing and synchronization protocol system can be configured to operate in various deployment models, where multiple DUs communicate with a single RU, where multiple RUs communicate with a single DU, and where the DU controls and / or monitors connected RUs to enable / disable various radio frequency (RF) functions within the RU. To ensure proper control of functions and capabilities is performed by the DU, the DU can be configured to obtain real-time timing, synchronization, and other status information from the RU. The real-time frequency and timing information can enable base stations to maximize data rates (e.g., by minimizing guard frequencies / times to maximize spectral efficiency and utilizing bandwidth-boosting techniques such as carrier aggregation (CA) and MIMO / CoMP) and optimize user experience (e.g., by performing smooth handovers, reducing latency, providing location-based services (LBS), etc.). Furthermore, the RU may be configured to provide / update real-time status to the DU in response to state changes such as real-time timing, synchronization, etc. This may enable the DU to make various decisions regarding RU functionality, including but not limited to enabling / disabling certain RF functions, based on state events / changes such as time type, synchronization, etc. reported by the RU, as described above.

[0052] In some embodiments, the protected entity may be further configured to communicate timing / synchronization / etc. state change events / RU changes (e.g., Precision Time Protocol (PTP) lock state, clock quality changes, phase / frequency accuracy updates, etc.) to the DU via the Ethernet layer. Additionally, the DU may be configured to communicate various configuration / monitoring / etc. information to the RU to determine which RU features should be enabled / disabled. In some exemplary embodiments, this information / messages between the DU and the RU may use the Radio Synchronization State Messaging (RSSM) protocol, as described herein.

[0053] FIG. 8 illustrates an exemplary wireless synchronization state messaging protocol system 800 in accordance with some embodiments of the present protected subject matter. This system 800 may be part of a 5G wireless communication system. The system 800 may include one or more distributed units (DUs) 804(a, b) communicatively coupled to one or more remote units (RUs) 806(a, b, c). As shown in FIG. 8, the DU 804a may be communicatively coupled to RUs 806a and 806b. The DU 804b may be communicatively coupled to RUs 806b and 806c. The system 800 may also include one or more synchronization masters selectable for each network segment within the system, where the root timing reference is referred to as a grandmaster (e.g., GMs 802a, 802b). The grandmaster may transmit synchronization information to clocks residing on its network segment, such that once a grandmaster is selected, all other clocks may synchronize directly to this grandmaster. The Precision Time Protocol (PTP) (as originally defined in the IEEE 1588-2002 standard) can be used to synchronize clocks throughout the system 800. PTP can be used to achieve clock accuracy in the sub-microsecond range. As shown in FIG. 8, both the DU 804 and the RU 806 can be configured to use the PTP protocol for clock synchronization purposes (via timing / synchronization planes 810(a,b)). However, to synchronize clocks related to state changes / events, a wireless synchronization state messaging protocol such as that described herein can be used between the DU 804 and the RU 806.

[0054] The use of this protected communications protocol solves various problems associated with legacy systems that implement the NETCONF / YANG protocol (or application-layer communications mode). NETCONF / YANG is a network management protocol developed and standardized by the Internet Engineering Task Force (IETF) under the RFC4741 and RFC6241 standards. This protocol provides mechanisms for installing, manipulating, and deleting configurations of network devices. However, communications based on this protocol do not define events / alerts for all timing and synchronization events / changes / conditions. In particular, protocol-based communications do not define extensions for PTP / SyncE (Synchronous Ethernet) information exchange, such as PTP clock class changes, SyncE clock quality changes, phase / frequency offsets, grandmaster information to which the RU may be locked, or the mode in which the RU is operating from the RU's perspective (e.g., GPS, PTP, etc.). From the DU's perspective, this protocol does not define extensions for various timing and synchronization settings, including, but not limited to, phase / frequency offset thresholds to be programmed in the RU, PTP clock class / SyncE clock quality thresholds to be programmed, etc.

[0055] 9 illustrates an exemplary communication system 900 that can be configured to implement the NETCONF / YANG notification protocol. The system 900 can include a remote unit (RU) 902 and a distributed unit (DU) 904. Communication between the RU 902 and the DU 904 can be achieved using various layers, each responsible for different aspects of the communication. In particular, these layers include Layer 1 (PHY) 906, Layer 2 (Data Link) 908, Layer 3 (Network) 910, Layer 4 (Transport) 912, and an application layer (e.g., Layers 5-7).

[0056] The application layer 914 can be configured to incorporate timing / synchronization components 916, where the RU 902 can include its own timing / synchronization component 916a and the DU 904 can also include a corresponding component 916b. Additionally, the application layer 914 can include various other aspects of Operations, Administration, and Maintenance (OAM), Simple Network Management Protocol (SNMP), and NETCONF / YANG protocols, where each of the RU 902 and DU 904 can be configured to include portions of each (e.g., the RU 902 can include portion 918a, and the DU 904 can include portion 918b). The application layer components 918a and 918b can be configured to exchange various notifications regarding status information in accordance with the NETCONF / YANG protocol. Components 916a and 916b can be configured to be communicatively coupled to precision time protocol-aware components 920a and 920b, respectively, which can be incorporated within Layer 1 / Layer 2 hardware, as shown in FIG. 9 .

[0057] System 900 can be configured to operate as follows: A timing state change event 930 may be detected within hardware component 920 (e.g., component 920a). Information about the event 930 may be sent to software component 916a. For example, the information may indicate a transition to a holdover state due to a clock class change event. Software component 916a may then be configured to communicate this information with component 918a at 932. Component 918a may be configured to generate and send an OAM layer notification 934 indicating the state change to its peer node, i.e., component 918b within DU 904. This notification may be sent using a NETCONF / SNMP message. Component 918b can then notify component 916b at 936 so that component 916b can perform the appropriate timing corrections.

[0058] Conventional systems (such as the system 900 shown in FIG. 9 ) cannot provide real-time reporting of time / synchronization events / changes / status to the DU. However, timing accuracy is important for providing real-time feedback from the RU to the DU regarding any timing / synchronization events / changes / etc. (e.g., the RU moving out of lock (holdover) due to significant packet delay variation (PDV) in the network, corruption of the PTP Grandmaster (GM) clock quality, corruption of the SyncE clock quality, and / or inaccessibility of the upstream master, etc.). It is also important for accurate timestamps of data packets, generation / processing of various PTP events and / or messages, timing of event changes, etc. Furthermore, such timing accuracy is also important for immediate reporting purposes from the RU to the DU, which must be processed in a real-time manner. However, this is not possible in conventional systems using the NETCONF / YANG protocol because such systems use application-based reporting. Here, any time / synchronization / status events detected in the hardware (e.g., PTP 920) are communicated to the software layer (e.g., components 916, 918) using the NETCONF / YANG protocol for reporting from the RU to the DU, as discussed above in connection with FIG. 9. Due to the dependency on the application layer, the reporting process is complex, time-consuming, and not performed in real time (which can be particularly problematic in scenarios where there are a series of PTP state changes), which typically forces the DU to process stale or "stale" data from the RU. The inability to report the RU's status to the DU in real time can also lead to unexpected / undefined results. For example, the DU may not want the RU to emit when the RU transitions to holdover (due to a large offset). Furthermore, delays in providing this information to the DU can ultimately lead to call handover issues, delays, and other problems.

[0059] The protected object solves the above problem using a radio synchronous messaging protocol described below. In particular, the protected object can be configured to provide a communication protocol between a DU and a RU that can occur in real time at Layer 2. The protected object can be configured to implement a Layer 2 fast path mechanism using a predetermined destination multicast address, a predetermined protocol type, various time-synchronized data types, payload options (where, for example, the payload is variable based on the type of data exchange), and any combination thereof.

[0060] Figure 10 illustrates an exemplary communication system 1000 that can be configured to implement a wireless synchronous messaging protocol according to some embodiments of the present subject matter. The system 1000 can include a remote unit (RU) 1002 and a distributed unit (DU) 1004. Similar to Figure 9, communication between the RU 1002 and the DU 1004 can be performed using various layers. These layers can include Layer 1 (PHY) 1006, Layer 2 (Data Link) 1008, Layer 3 (Network) 1010, Layer 4 (Transport) 1012, and an application layer (e.g., Layers 5-7).

[0061] In the system 1000, the application layer 1014 can be configured to incorporate timing / synchronization components 1016, where the RU 1002 can include component 1016a and the DU 1004 can include component 1016b. These components 1016a and 1016b can be configured to be communicatively coupled to precision time protocol-aware components 1020a, 1020b, respectively, which can be incorporated in Layer 1 / Layer 2 hardware as shown in FIG. 10. Furthermore, each PTP component 1020 can include a radio synchronization status messaging module (RSSM module) 1022(a, b), respectively. The modules 1022 of the RU 1002 and the DU 1004 can be communicatively coupled as shown in FIG. 10.

[0062] The system 1000 can be configured to operate as follows: A timing state change event 1030 (e.g., a transition to a holdover state due to a clock class change event) may be detected in a hardware component 1020 (e.g., component 1020a). These event 1030 information may be sent to a software component 1016a or provided to an RSSM module 1022a. The RSSM module 1022a can then communicate a notification of the state change information to an RSSM module 1022b of the DU 1004 at 1032 via a Layer 2 message. The component 1020b can then transmit the information received by the RSSM module 1022b and send a notification 1034 to component 1016b, thereby enabling component 1016b to perform appropriate timing corrections and / or any other functions in the application layer 1012 portion of the DU 1004.

[0063] Furthermore, in communications from any RU 1002 to a DU 1004, a Layer 2 frame having a predetermined protocol type (e.g., an RSSM protocol as discussed below) can be generated for any time synchronization / status / event change and can be configured to include the type of data for reporting (e.g., a PTP clock class change, etc.). The frame can also include different time synchronization / status / event data types (e.g., an RSSM message type as discussed below), source and / or destination information, optional payload information, and / or any other information. The source information (e.g., Source_Info) can be used to identify the source of the data packet origin and can include a source type (e.g., Source_Type) and a source identifier (e.g., Source_id). The Source_Type can be further configured to identify whether the message is being sent from an RU or a DU. The Source_Id can indicate a remote unit identifier (e.g., RU_ID) that can be used to identify a specific RU among multiple RUs that may be connected to a DU. The destination information (e.g., Destination_Info) can be used to identify the destination and can have a destination type (e.g., Destination_Type) that can identify a particular DU and / or RU, and a destination identifier (e.g., Dest_Id) that can identify a particular DU and / or RU (if it is a DU, its destination identifier can be DU_ID). Table 1 below shows an example Ethernet frame format that can be transmitted between modules 1022a and 1022b (as shown in FIG. 10) in accordance with the above discussion.

[0064] Table 1. Ethernet frame format [Table 1]

[0065] In the exemplary Ethernet frame format shown in Table 1, the DST_MC_MAC_ADDR field may refer to a predetermined multicast MAC address. The SRC_MAC_ADDR field may refer to the MAC address of the Layer 2 source (e.g., the RU is the source). The ETHER_TYPE field may refer to a Layer 2 protocol Ether type, which may indicate the type of frame being transmitted. The PAYLOAD field of the frame may contain information about detected time synchronization / status / events. In particular, the PAYLOAD field may contain the RSSM protocol message shown in Table 2 below. The PREAMBLE and FCS (Frame Check Sequence) fields of the above Ethernet frame may refer to standard components of an Ethernet frame. Each of the above portions of this Ethernet frame may have various sizes (some of which may be typical of a standard Ethernet frame). As mentioned above, Table 2 shows an exemplary RSSM protocol message format.

[0066] Table 2. RSSM protocol messages [Table 2]

[0067] As shown in Table 2 above, VersionRSSM may be a field (e.g., 3 bits) that indicates the RSSM protocol version. The DST_IDENTIFIER field may contain information about the destination type and destination identifier. In particular, as shown by Table 3 below, this may include the following two fields: Destination Type (DU / RU) and Destination_Id.

[0068] Table 3. Destination Information Fields [Table 3]

[0069] Similarly, the SRC_IDENTIFIER field may contain information about the source type and source identifier, in particular, as shown by Table 4 below, this may include the following two fields: Source Type (DU / RU) and Source_Id.

[0070] Table 4. Origin Information Fields [Table 4]

[0071]

[0046] Referring back to Table 2, the RSSM_MSG_TYPE field may indicate the type of RSSM message being sent. Some example RSSM message types may include at least one of the following: 0 - undefined, 1 - PTP_CLOCK_STATUS (e.g., may be used to indicate PTP lock status), 2 - SYNCE_CLOCK_STATUS (e.g., may be used to indicate SyncE lock status), 3 - TIME_ERR_STATUS (e.g., may be used to indicate phase / frequency error / offset), 4 - PTP_CFG (e.g., may refer to PTP settings such as offset thresholds set in the RU), 5 - SYNCE_CFG (e.g., may refer to frequency settings such as offset thresholds set in the RU), 6 - optional cmd / config, and 7 through 255 - reserved for various uses.

[0072] The RSSM message length field may indicate the length (e.g., bytes) of the RSSM message, including the header and payload portion. The payload field may contain relevant data regarding any changes in synchronization / time / state changes based on each of the above RSSM_MSG_TYPEs. For example, when the RU 1002 transitions to the HOLDOVER state due to a PTP clock class change, the RU 1004 may generate a Layer 2 frame according to the format shown in Tables 1-4 above to notify the DU 1002 of the state change regarding the RU 1004. In particular, the Ethernet frame shown in Table 1 may contain the following information within its fields: DST_MC_MAC_ADDR may refer to the MAC address of the DU 1004; SRC_MAC_ADDR may refer to the MAC address of the RU 1002; and ETHER_TYPE may contain an RSSM protocol type, which may indicate that an RSSM protocol frame is being transmitted. The payload portion may be defined according to Tables 2-4 above. It may include a DST_IDENTIFIER (e.g., an identifier of the DU 1004), a SRC_IDENTIFIER (e.g., an identifier of the RU 1002), an RSSM_MSG_TYPE message type (e.g., a PTP clock state message), and an optional RSSM payload. Furthermore, the DST_IDENTIFIER may include the Destination_Type and Destination_Identifier of the DU 1004 as the DU_ID (e.g., DU 1004) identifier, which may indicate the destination of the message. Furthermore, the SRC_IDENTIFIER may include the Source_Type (e.g., RU) and Source_Identifier of the RU 1002 as the RU_ID corresponding to the origin of the message (i.e., the RU 1002). The RSSM_MSG_TYPE field of the message may indicate that the message is a PTP clock state message. The payload fields of the RSSM message may be: PTP lock state: LOCKED / HOLDOVER / FREE-RUN (e.g., can indicate PTP status) State since (in seconds): xx (for example, you can show the time since the last change of state) PTP Receive Clock Quality: 7 (e.g., this value can include any value from 1 to 255) GM Info (GM Clk id): 64-byte value (e.g., can indicate grandmaster clock information and its clock identifier)

[0073] Using the above information, the RSSM module 1022a in the RU 1002 can be configured to generate an RSSM message 1032 and send this message to the RSSM module 1022b in the DU 1004. Based on the received message, the DU 1004 can be configured to selectively control / monitor / configure the RU 1002 for any further action.

[0074] Similarly, communication from the DU 1004 to the RU 1002 can also implement the Layer 2 Ethernet frames described above with respect to Tables 1-4. In particular, for any time synchronization configuration, the DU 1004 can generate a Layer 2 frame (e.g., as shown in Table 1) having a predetermined protocol type (e.g., RSSM protocol) and data for reporting, configuration, etc. (e.g., phase / frequency thresholds configured in the RU 1002). For transmission of an RSSM message from the DU 1004 to the RU 1002, a different time synchronization event data type (e.g., RSSM message type), source and destination information, and optional payload information can be used (e.g., different from those used in the Ethernet frame being transmitted from the RU 1002 to the DU 1004). For example, the DU 1004 may want the RU 1002 to be configured with specific phase / frequency thresholds so that the RU 1002 can continue to radiate in a locked state as long as the phase / frequency error is within the configured phase / frequency thresholds. To do so, the DU 1004 can be configured to generate a Layer 2 Ethernet frame (as defined in Tables 1-4 above) using the following information and send it to the RU 1002 for setting the intended values:

[0075] In particular, the Ethernet frame shown in Table 1 may include the following information in its fields: DST_MC_MAC_ADDR may refer to the MAC address of the RU 1002. SRC_MAC_ADDR may refer to the MAC address of the DU 1004. ETHER_TYPE may include an RSSM protocol type, which may indicate that an RSSM protocol frame is being transmitted. The payload portion may be defined according to Tables 2-4 above. It may include a DST_IDENTIFIER (e.g., an identifier of the RU 1002), an SRC_IDENTIFIER (e.g., an identifier of the DU 1004), an RSSM_MSG_TYPE message type (e.g., a phase / frequency threshold setting message), and an optional RSSM payload. Furthermore, the DST_IDENTIFIER may include a Destination_Type and a Destination_Identifier of the RU 1002 as an RU_ID (e.g., RU 1002) identifier, which may indicate the destination of the message. Furthermore, the SRC_IDENTIFIER may include the Source_Type (i.e., DU) and Source_Identifier of the DU 1004 as the DU_ID corresponding to the origin of the message (i.e., the DU 1004). The RSSM_MSG_TYPE field of the message may indicate that the message is a PTP_CFG configuration message. The payload field of the RSSM message may be: Clock Class: Configurable clock class threshold Phase_Offset_cfg: Configurable phase offset threshold (e.g. 100ns) Freq_Offset_cfg: Set frequency offset threshold (ppm) (e.g., 11 ppm) Optionally, a payload can be added.

[0076] As described above, using the above data, the DU 1004 can generate a Layer 2 Ethernet message destined for the RU 1002, so that the intended configuration can be applied at the RU 1002 using the content sent in the generated RSSM message.

[0077] In some embodiments, in a personalized RAN architecture, one or more DUs 1004 can be communicatively coupled to a single RU 1002, and / or one or more RUs 1002 can be communicatively coupled to a single DU 1004. During operation, the RUs 1002 can be configured to synchronize (e.g., in time / frequency, etc.), and the DUs 1004 can be configured to monitor the time synchronization status of the RUs 1002 by programming the RUs 1002 to report the synchronization status to the connected DUs 1004 using an RSSM protocol mechanism. This reporting may be automatic upon receiving an appropriate request, periodic, manual, and / or may be performed at any other desired time and / or may be performed periodically. For example, the rate / frequency at which such reporting to the DUs 1004 occurs can be programmable.

[0078] Each RU 1002 can be configured to report time synchronization status to the DU 1004 generating the Layer 2 Ethernet frame (according to Tables 1-4 above). The frame can include data for the PTP module 1020a, where the PTP module functions can be implemented in hardware, software, and / or both. As shown in FIG. 10 and discussed above, the PTP module 1020a can incorporate the functions and / or procedures of the RSSM protocol module 1022a.

[0079] In the event of a state change in the RU 1002 (e.g., if the RU 1002 loses lock / synchronization state and transitions from LOCKED / SYNCED state to HOLDOVER / FREE-RUN state due to, for example, loss of S-plane communication at the RU / PTP, clock class not within acceptable range, SyncE SSM quality exceeding acceptable range, etc.), its PTP module 1020a can be configured to detect such change and provide an appropriate notification to the RSSM module 1022a, where this notification can include data indicating the change in lock state along with the lock state data. The RSSM module 1022a can use the received information to indicate / determine the type of event and can generate a Layer 2 Ethernet frame message according to Tables 1-4 above. The RSSM module 1022a can then transmit the generated message to all upstream DUs 1004 that may be communicatively coupled to the RU 1002.

[0080] The embedded PTP module 1020 of the DU 1004, which integrates the RSSM module 1022, can be configured to detect received Layer 2 Ethernet messages and determine changes in the state of time synchronization. The DU 1004 can then decide whether to respond to such changes based on the received information. This response can be in a real-time manner. The RSSM module 1022b of the DU 1004 can generate an appropriate RSSM message for inclusion in a Layer 2 Ethernet frame (generated according to Tables 1-4 above) and send it to all associated DUs 1004 that can be communicatively coupled to the RU 1002.

[0081] The above detection, reaction, and notification (by the DU / RU) of time state changes can occur within the hardware portion of the DU / RU (e.g., near the "wire"). These processes can thus avoid interactions with software modules that may occur at higher layers, and therefore avoid delays in reporting time-sensitive events to the DU that may be related to the software layer. Therefore, communication between the DU and the RU can be substantially real-time.

[0082] Furthermore, in some embodiments, an RU reporting its lock status to a DU can be configured to select a predetermined multicast address as the destination MAC address. This avoids keeping track of all unicast DUs with which a particular RU can be communicatively associated and generating multiple lock status reports using unicast destination MAC addresses. Instead, a single multicast destination MAC address RSSM frame can be replicated and simultaneously transmitted to all upstream DUs. This ensures that the RU status is broadcast to all multicast DUs in real time, allowing the DUs to take appropriate action in a timely manner to enable / disable radio frequency (RF) capabilities before RUs experience delays (e.g., that could result in dropped / delayed calls).

[0083] FIG. 11 illustrates an exemplary process 1100 for wireless synchronous messaging in accordance with some embodiments of the present protected subject matter. This process 1100 may be performed by the system 1000 illustrated in FIG. 10. At 1102, timing state changes (e.g., changes in synchronization state, timing change events, PTP clock class changes, phase / frequency threshold changes, etc.) may be monitored and detected. The timing state changes may be monitored / detected by the distributed unit (DU) 1004 and / or the radio unit (RU) 1002, as illustrated in FIG. 10. In particular, the PTP module 1020 may be configured to detect such changes.

[0084] At 1104, a Layer 2 frame may be generated (e.g., by an RU for communication from RU to DU; by a DU for communication from DU to RU). The Layer 2 frame may include source and destination data / information along with payload information, which may include an RSSM message. At 1104a, the source data / information may include a source type, a source identifier, etc. (e.g., identifying the DU and / or RU), and at 1104b, the destination data / information may include a destination type, a destination identifier, etc. (e.g., identifying the RU and / or DU). At 1104c, the frame may also include an Ether type that specifically identifies this type of frame as a communication change in synchronization state, a timing change event, etc. At 1104d, the Layer 2 frame may also include an RSSM message, which may indicate a detected change as discussed above.

[0085] At 1106, the generated Layer 2 frame may be transmitted to all applicable or "associated" communication units (e.g., RUs, DUs, etc.). Transmission to all applicable or "associated" communication units may be achieved through the use of multicast MAC addressing, whereby the generated frame may be replicated and transmitted using multiple copies. The Layer 2 frame may be received by the PTP hardware (particularly the RSSM module 1022) of the frame's intended recipient (e.g., the DU 1004 when the frame is transmitted by the RU 1002 as shown in FIG. 10).

[0086] Some advantages of the protected protocol over existing systems include the ability to use multicast-based communication between the DU and RU (as opposed to traditional protocols that implement unicast communication), thereby eliminating the need for separate message communication between the DU and RU. Furthermore, as noted above, the protected protocol enables substantially real-time change detection and RSSM message generation and reporting to the DU (compared to traditional systems, which typically took up to approximately one second from the time an event was detected until a message was generated and reported from the RU to the DU). Additionally, while traditional systems typically provide a generic mechanism for information exchange between the DU and RU for all types of events / notifications (e.g., S-plane, U-plane, C-plane), the protected RSSM protocol can define explicit communication methods that may be desired by a telecommunications operator for exchanging time synchronization status (e.g., S-plane) and setting time synchronization thresholds / parameters between the DU and DU.

[0087] Referring back to Table 2, below is a discussion of some example formats for the various RSSM_MSG_TYPE fields that can indicate the type of RSSM message being sent (e.g., 0 - undefined, 1 - PTP_CLOCK_STATUS, 2 - SYNCE_CLOCK_STATUS, 3 - TIME_ERR_STATUS, 4 - PTP_CFG, 5 - SYNCE_CFG, 6 - optional cmd / config, and 7 through 255 - reserved for various uses). The type of RSSM message (shown in Table 2 above) can determine the specific data that can be included in the payload.

[0088] In some exemplary embodiments, the PTP_CLOCK_STATUS message may have the following format as shown in Table 5 below:

[0089] Table 5. PTP_CLOCK_STATUS messages [Table 5]

[0090] The above message may indicate that the RSSM message type is PTO clock status (e.g., RSSM_MSG_TYPE=PTP_CLOCK_STATUS(1)). It may also include an indication of the length of the RSSM message header and payload in bytes (e.g., N). Furthermore, the PTP lock status may indicate the timing state of the RU and / or DU (e.g., PTP_Lock_Status=RU / DU Timing Status). As a non-limiting example, some PTP_Lock_Status values ​​may include LOCKED, HOLDOVER, FREE-RUN, etc. Another field in the above message may include an indication of how long a particular DU / RU has been in the current lock state (e.g., State_Since; in seconds). The Clock_Class field may indicate the clock class (e.g., grandmaster clock class) that can be received from the upstream master. The GM Id field may indicate a grandmaster identifier that can be received and selected from other available grandmasters according to a best master clock algorithm (BMCA). The extendable payload field may contain any additional data.

[0091] The SYNCE_CLOCK_STATUS message (eg, RSSM message type 2) may have the following format as shown in Table 6:

[0092] Table 6. SYNC_CLOCK_STATUS Messages [Table 6]

[0093] The first two fields of this message may be similar to the message shown in Table 5. The SyncE_Lock_Status field may indicate the SyncE lock state of the RU / DU. Some example non-limiting values ​​may include LOCKED, HOLDOVER, FREE-RUN, etc. The State_Since field is similar to the respective field shown in Table 5 above. The Received_SSM_Level field may indicate the received SSM quality, which indicates the physical clock quality level. The extensible payload may contain any additional data similar to Table 5.

[0094] The TIME_ERR_STATUS message may have the following format as shown in Table 7:

[0095] Table 7. TIME_ERR_STATUS messages [Table 7]

[0096] The first two fields of the above message (containing the respective information) are similar to the fields in Tables 5 and 6 discussed above. In particular, the RSSM_MSG_TYPE field may contain the time error (e.g., offset) status of the device (e.g., TIME_ERR_STATUS). The N fields may correspond to the length of the RSSM message header and payload, as described above. The TIME_ERR field (as measured in nanoseconds) may correspond to the time error (e.g., phase offset) accumulated on the device (e.g., RU, DU, etc.). The FREQ_ERR field may correspond to the frequency error (e.g., offset) accumulated on the device (e.g., as measured in ppm). The payload may contain any further information.

[0097] The PTP configuration message (i.e., PTP_CFG) may have the following format, shown in Table 8:

[0098] Table 8. PTP configuration messages [Table 8]

[0099] The first two fields contain the types of information described above with respect to Tables 5-7. The PTP_Clock_Class field can correspond to a configurable clock class value (e.g., 1-255). The PHASE_OFFSET_CFG field can contain a configurable phase offset value (e.g., as measured in ns). The FREQ_OFFSET_CFG field can contain a configurable frequency offset value (e.g., as measured in ppm). Again, the payload field can contain any other information.

[0100] The SyncE configuration message (eg, SYNCE_CFG) may have the following format as shown in Table 9 below:

[0101] Table 9. SyncE configuration messages [Table 9]

[0102] In addition to the fields already discussed with respect to Tables 5-9, the SSM_CLK_LEVEL field may contain information about the configurable SSM quality level. The FREQ_OFFSET_CFG field may contain data about the configurable frequency offset (as measured in ppb). Finally, the payload may contain any additional data.

[0103] As shown in FIG. 12 , in some embodiments, the subject matter may be configured to be implemented within a system 1200. The system 1200 may include one or more processors 1210, memory 1220, storage devices 1230, and input / output devices 1240. Each of these components 1210, 1220, 1230, and 1240 may be interconnected using a system bus 1250. The processor 1210 may be configured to process instructions for execution within the system 600. In some embodiments, the processor 1210 may be a single-threaded processor. In alternative embodiments, the processor 1210 may be a multi-threaded processor. The processor 1210 may be further configured to process instructions stored in the memory 1220 or on the storage devices 1230, including receiving or transmitting information via the input / output devices 1240. The memory 1220 may store information within the system 1200. In some embodiments, the memory 1220 may be a computer-readable medium. In alternative embodiments, memory 1220 may be a volatile memory unit. Further, in some embodiments, memory 1220 may be a non-volatile memory unit. Storage device 1230 may provide mass storage for system 1200. In some embodiments, storage device 1230 may be a computer-readable medium. In alternative embodiments, storage device 1230 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 1240 may be configured to provide input / output operations for system 1200. In some embodiments, input / output device 1240 may include a keyboard and / or a pointing device. In alternative embodiments, input / output device 1240 may include a display unit for displaying a graphical user interface.

[0104] 13 illustrates an exemplary method 1300 according to some embodiments of the present protected subject matter. At 1302, a change in a state event may be detected by one or more first communication devices (e.g., RU, DU, etc.). At step 1304, a message may be generated indicating the detected change in state event. At 1306, the generated message may be transmitted to one or more second communication devices (e.g., DU, RU, etc.).

[0105] In some embodiments, the protected subject matter may include one or more of the following optional features: The communications device may include at least one of the following: a base station, a gNodeB base station, an eNodeB base station, and any combination thereof. In particular, the communications device may include at least one of the following: one or more distributed units, one or more radio units, and any combination thereof. Furthermore, in some embodiments, the remote unit may generate a message and transmit the generated message to one or more distributed units. Alternatively or additionally, the distributed unit may generate a message and transmit the generated message to one or more remote units.

[0106] In some embodiments, the message may be a Layer 2 message frame configured to be transmitted from one or more Layer 2 components of one or more first communication devices to one or more Layer 2 components of one or more second communication devices. The Layer 2 message may include at least one of the following: an identifier of an origin of the Layer 2 message, an identifier of a type of origin of the Layer 2 message, an identifier of a destination of the Layer 2 message, an identifier of a type of destination of the Layer 2 message, an identifier of a type of Layer 2 message, data corresponding to a change in state event, and any combination thereof. Furthermore, the data corresponding to a change in state event may include at least one of the following: a precision timing protocol clock state, a synchronous Ethernet clock state, a time error state, a precision timing protocol setting, a synchronous Ethernet setting, one or more commands, one or more settings, and any combination thereof. The data corresponding to a change in state event may include at least one of the following: a time elapsed since detection of a preceding change in state event, a phase offset setting, a frequency offset setting, and any combination thereof.

[0107] In some embodiments, the method may include performing, by the second communication device, one or more actions based on the received message.

[0108] In some embodiments, the message may be a multicast message configured to be received by one or more second communication devices in substantially real time.

[0109] The systems and methods disclosed herein may be embodied in various forms, including, for example, a data processor, such as a computer, including a database, digital electronic circuitry, firmware, software, or any combination thereof. Furthermore, the above-described features and other aspects and principles of the disclosed embodiments may be implemented in a variety of environments. Such environments and associated applications may include general-purpose computers or computing platforms that can be specially constructed to perform the various processes and operations according to the disclosed embodiments, or that are selectively activated or reconfigured by code to provide the required functionality. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, but may be implemented by any suitable combination of hardware, software, and / or firmware. For example, various general-purpose machines may be used with programs written in accordance with the teachings of the disclosed embodiments, or it may be more suitable to construct specialized apparatus or systems to perform the required methods and techniques.

[0110] The systems and methods disclosed herein can be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., a machine-readable storage device or a propagated signal, for execution by or control of the operation of a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. The computer program can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. The computer program can be deployed to run on one computer, on multiple computers at one site, or distributed across multiple sites and interconnected by a communications network.

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

[0112] Although ordinal numbers such as first, second, etc. may relate to order in some contexts, ordinal numbers as used herein do not necessarily imply ordering. For example, ordinal numbers may be used simply to distinguish one item from another, e.g., to distinguish a first event from a second event, without necessarily implying any chronological order or fixed frame of reference (so that a first event in one paragraph of description may be different from a first event in another paragraph of description).

[0113] The foregoing description is intended to illustrate, but not to limit, the scope of the invention, which is defined by the appended claims. Other embodiments are within the scope of the appended claims.

[0114] These computer programs, which may also be referred to as programs, software, software applications, applications, components, or code, contain machine instructions for a programmable processor and may be implemented in a high-level procedural and / or object-oriented programming language and / or assembly / machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus, and / or device used to provide machine instructions and / or data to a programmable processor, such as, for example, a magnetic disk, an optical disk, a memory, and a programmable logic device (PLD), including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor. A machine-readable medium may store such machine instructions non-transitoryly, such as, for example, a non-transitory solid-state memory or a magnetic hard drive or any equivalent storage medium. Alternatively or additionally, the machine-readable medium may store such machine instructions in a transitory manner, such as, for example, a processor cache or other random access memory associated with one or more physical processor cores.

[0115] To provide for user interaction, the subject matter described herein can be implemented in a computer having a display device, such as a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to a user, and a keyboard and pointing device, such as a mouse or trackball, by which the user can provide input to the computer. Other types of devices can be used to provide for user interaction as well. For example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback. Input from the user can also be received in any form, including, but not limited to, acoustic, voice, or tactile input.

[0116] The protected subject matter described herein may be implemented in a computing system that includes back-end components, such as, for example, one or more data servers, or middleware components, such as, for example, one or more application servers, or front-end components, such as, for example, one or more client computers having a graphical user interface or web browser through which a user can interact with an embodiment of the protected subject matter described herein, or any combination of such back-end, middleware, or front-end components. These components of the system may be interconnected by any form or medium of digital data communication, such as, for example, a communications network. Examples of communications networks include, but are not limited to, a local area network ("LAN"), a wide area network ("WAN"), and the Internet.

[0117] A computing system may include clients and servers. Clients and servers are generally (but not exclusively) remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0118] The embodiments set forth in the foregoing description do not represent all embodiments consistent with the subject matter described herein. Instead, they are merely some examples consistent with aspects related to the subject matter described. While some variations have been described in detail above, other modifications or additions are possible. In particular, further features and / or variations may be provided in addition to what is described herein. For example, the above-described embodiments may be directed to various combinations or subcombinations of the disclosed features and / or to combinations or subcombinations of multiple additional features described above. Additionally, the logic flow illustrated in the accompanying drawings and / or described herein does not necessarily require the particular order or sequential order shown to achieve desired results. Other embodiments may be within the scope of the dependent claims. In addition to the above, the present application provides the following: (Item 1) 1. A computer-implemented method, the method comprising: detecting a change in a state event by one or more first communication devices; generating a message indicating the detected change in the state event; transmitting the generated message to one or more second communication devices; A method comprising: (Item 2) The one or more first and second communication devices include at least one of the following: a base station, a gNodeB base station, an eNodeB base station, and any combination thereof; The method described in item 1. (Item 3) The one or more first and second communication devices include at least one of the following: one or more distributed units, one or more radio units, and any combination thereof; The method described in item 2. (Item 4) one or more remote units generating the message and transmitting the generated message to the one or more distributed units; The method described in item 3. (Item 5) the one or more distributed units generate the message and transmit the generated message to the one or more remote units; The method described in item 3. (Item 6) the message is a Layer 2 message frame configured to be transmitted from one or more Layer 2 components of the one or more first communication devices to one or more Layer 2 components of the one or more second communication devices; The method described in item 1. (Item 7) the Layer 2 message includes at least one of the following: an identifier of an originator of the Layer 2 message, an identifier of the type of the originator of the Layer 2 message, an identifier of a destination of the Layer 2 message, an identifier of the type of the destination of the Layer 2 message, an identifier of the type of the Layer 2 message, data corresponding to a change in the state event, and any combination thereof; The method described in item 6. (Item 8) the data corresponding to the change in state event includes at least one of the following: a precision timing protocol clock state, a synchronous ethernet clock state, a time error state, a precision timing protocol setting, a synchronous ethernet configuration, one or more commands, one or more configurations, and any combination thereof; The method described in item 7. (Item 9) the data corresponding to the change in the state event includes at least one of the following: an elapsed time since detection of a previous change in state event, a phase offset configuration, a frequency offset configuration, and any combination thereof; The method described in item 8. (Item 10) the method further comprising performing, by the one or more second communication devices, one or more actions based on the received message. The method described in item 1. (Item 11) the message is a multicast message configured to be received in real time by the one or more second communication devices. The method described in item 1. (Item 12) at least one programmable processor; a non-transitory machine-readable medium; An apparatus comprising: The non-transitory machine-readable medium, when executed by the at least one programmable processor, causes the at least one programmable processor to: detecting a change in a state event by one or more first communication devices; generating a message indicating the detected change in the state event; transmitting the generated message to one or more second communication devices; and storing instructions for performing operations including Device. (Item 13) The one or more first and second communication devices include at least one of the following: a base station, a gNodeB base station, an eNodeB base station, and any combination thereof; Item 13. The apparatus according to item 12. (Item 14) The one or more first and second communication devices include at least one of the following: one or more distributed units, one or more radio units, and any combination thereof; Item 14. The apparatus according to item 13. (Item 15) one or more remote units generating the message and transmitting the generated message to the one or more distributed units; Item 15. The apparatus according to item 14. (Item 16) the one or more distributed units generate the message and transmit the generated message to the one or more remote units; Item 15. The apparatus according to item 14. (Item 17) the message is a Layer 2 message frame configured to be transmitted from one or more Layer 2 components of the one or more first communication devices to one or more Layer 2 components of the one or more second communication devices; Item 13. The apparatus according to item 12. (Item 18) the Layer 2 message includes at least one of the following: an identifier of an originator of the Layer 2 message, an identifier of the type of the originator of the Layer 2 message, an identifier of a destination of the Layer 2 message, an identifier of the type of the destination of the Layer 2 message, an identifier of the type of the Layer 2 message, data corresponding to a change in the state event, and any combination thereof; Item 17. The apparatus according to item 17. (Item 19) the data corresponding to the change in the state event includes at least one of the following: a precision timing protocol clock state, a synchronous ethernet clock state, a time error state, a precision timing protocol setting, a synchronous ethernet configuration, one or more commands, one or more configurations, and any combination thereof; Item 19. The apparatus according to item 18. (Item 20) the data corresponding to the change in the state event includes at least one of the following: an elapsed time since detection of a previous change in state event, a phase offset configuration, a frequency offset configuration, and any combination thereof; Item 19. The apparatus according to item 19. (Item 21) the operations further include performing, by the one or more second communication devices, one or more actions based on the received message. Item 13. The apparatus according to item 12. (Item 22) the message is a multicast message configured to be received in real time by the one or more second communication devices. Item 13. The apparatus according to item 12. (Item 23) 1. A computer program product comprising: When executed by at least one programmable processor, the method causes said at least one programmable processor to: detecting a change in a state event by one or more first communication devices; generating a message indicating the detected change in the state event; transmitting the generated message to one or more second communication devices; a non-transitory machine-readable medium having stored thereon instructions for performing operations including Computer program products. (Item 24) The one or more first and second communication devices include at least one of the following: a base station, a gNodeB base station, an eNodeB base station, and any combination thereof; Item 24. The computer program product of item 23. (Item 25) The one or more first and second communication devices include at least one of the following: one or more distributed units, one or more radio units, and any combination thereof; 25. The computer program product of item 24. (Item 26) one or more remote units generating the message and transmitting the generated message to the one or more distributed units; 26. The computer program product of item 25. (Item 27) the one or more distributed units generate the message and transmit the generated message to the one or more remote units; Item 26. The computer program product of item 25. (Item 28) the message is a Layer 2 message frame configured to be transmitted from one or more Layer 2 components of the one or more first communication devices to one or more Layer 2 components of the one or more second communication devices; Item 24. The computer program product of item 23. (Item 29) the Layer 2 message includes at least one of the following: an identifier of an originator of the Layer 2 message, an identifier of the type of the originator of the Layer 2 message, an identifier of a destination of the Layer 2 message, an identifier of the type of the destination of the Layer 2 message, an identifier of the type of the Layer 2 message, data corresponding to a change in the state event, and any combination thereof; Item 29. The computer program product of item 28. (Item 30) the data corresponding to the change in the state event includes at least one of the following: a precision timing protocol clock state, a synchronous ethernet clock state, a time error state, a precision timing protocol setting, a synchronous ethernet configuration, one or more commands, one or more configurations, and any combination thereof; Item 30. The computer program product of item 29. (Item 31) the data corresponding to the change in the state event includes at least one of the following: an elapsed time since detection of a previous change in state event, a phase offset configuration, a frequency offset configuration, and any combination thereof; Item 31. The computer program product of item 30. (Item 32) the operations further include performing, by the one or more second communication devices, one or more actions based on the received message. Item 24. The computer program product of item 23. (Item 33) the message is a multicast message configured to be received in real time by the one or more second communication devices. Item 24. The computer program product of item 23.

Claims

1. 1. A method in a radio access network (RAN), comprising: The following steps, performed in a first communication device of the Radio Access Network (RAN), relate to at least one of Layer 1 and Layer 2: Detecting at least one event of the plurality of events; generating a notification for the at least one event of the plurality of events by including an identifier corresponding to each of the detected at least one event based on a designated protocol defining a unique identifier for each of the plurality of events; sending the notification to a second communication device in the Radio Access Network (RAN) to cause the second communication device to perform an action corresponding to the at least one event identified by the identifier; Including, the plurality of events includes a first event related to a Precision Time Protocol or a Synchronous Ethernet; method.

2. the first communication device includes one of a radio unit (RU) and a distributed unit (DU); the second communication device includes the other of the radio unit (RU) and the distributed unit (DU); The method of claim 1.

3. The generating step is performed without including information generated at an application layer of the first communication device in response to the detecting step. The method of claim 1.

4. sending information about the detected event to an application layer of the first communication device; further comprising the information causes an action in the application layer related to the action performed by the notification to be performed. The method of claim 1.

5. The plurality of events includes events related to at least one of a Precision Time Protocol clock state, a Synchronous Ethernet clock state, a time error state, a Precision Time Protocol configuration, a Synchronous Ethernet configuration, one or more commands, one or more settings, and any combination thereof. The method of claim 1.

6. The notification comprises a multicast message; the second communication device includes a plurality of communication devices that simultaneously receive the notification from the first communication device, the transmitting step includes simultaneously transmitting the notification to the plurality of communication devices. The method of claim 1.

7. A first communication device in a radio access network (RAN), comprising: at least one programmable processor; a non-transitory machine-readable medium on which instructions are stored; the instructions, when executed by the at least one programmable processor, cause the at least one programmable processor to perform the following steps relating to at least one of Layer 1 and Layer 2: Detecting at least one event of the plurality of events; generating a notification for the at least one event of the plurality of events by including an identifier corresponding to each of the detected at least one event based on a designated protocol defining a unique identifier for each of the plurality of events; sending the notification to a second communication device in the radio access network (RAN) to cause the second communication device to perform an action corresponding to the at least one event identified by the identifier; Execute the plurality of events includes a first event related to a Precision Time Protocol or a Synchronous Ethernet; A first communication device.

8. the first communication device includes one of a radio unit (RU) and a distributed unit (DU); the second communication device includes the other of the radio unit (RU) and the distributed unit (DU); The first communication device of claim 7 .

9. The generating step is performed without including information generated at an application layer of the first communication device in response to the detecting step. The first communication device of claim 7 .

10. The at least one programmable processor: sending information about the detected event to an application layer of the first communication device; Further execute the information causes an action in the application layer related to the action performed by the notification to be performed. The first communication device of claim 7 .

11. The plurality of events includes events related to at least one of a Precision Time Protocol clock state, a Synchronous Ethernet clock state, a time error state, a Precision Time Protocol configuration, a Synchronous Ethernet configuration, one or more commands, one or more settings, and any combination thereof. The first communication device of claim 7 .

12. The notification comprises a multicast message; the second communication device includes a plurality of communication devices that simultaneously receive the notification from the first communication device, the transmitting step includes simultaneously transmitting the notification to the plurality of communication devices. The first communication device of claim 7 .

Images