Edge-based Location-Specific Alert System for LTE Networks

Abstract

To provide a mobile edge computing (MEC) system and a method which provide a local emergency response and a warning exclusively for UEs in a site or in an area and also provide a place specificity warning in a site or in an area.SOLUTION: An LTE network edge system 100 includes a component which aggregates an SI-mme interface 112 between a mobile management entity (MME) and a plurality of base band devices 115 and accesses the S1-mme interface for reading or writing. The LTE network edge system issues a public warning system (PWS) message of cell specificity customized exclusively for each individual cell in the site.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to wireless communication, and more specifically, to an LTE mobile edge computing system that provides local emergency response and alerts limited to UEs in a site or area, and also provides location-specific alerts in the site or area.

Background Art

[0002] According to an LTE-based cellular phone network, a cellular carrier can perform many features from within an evolved packet core (EPC) network. The EPC interface interfaces with a radio access network (RAN) that determines how mobile devices ultimately connect to the cellular carrier's network.

[0003] An LTE base station (base station) or eNodeB (eNB) is a major element of a RAN that generates radio signals and regulates access and connectivity of mobile devices. Generally, an eNB is subordinate to its elements within the EPC. Thus, features, functions, and capabilities implemented "above the RAN" are transparent to the eNB. However, due to the relatively close proximity of the eNB to mobile devices and thus to the users of those mobile devices, the eNB is ideally suited to implement a function, roughly referred to as "mobile edge computing (MEC)", that is a somewhat improved function and can be beneficial to mobile devices and users.

[0004] Mobile Edge Computing (MEC) : ​​​​​​​​​​​​​MEC is a network architecture concept that enables cloud computing capabilities and IT service environments at the edge of the cellular network. The basic idea behind MEC is to run applications closer to cellular customers and perform associated processing tasks, thereby reducing network congestion and enabling applications to perform better. MEC technology is designed to be implemented in cellular base stations and also enables flexible and rapid deployment of new applications and services for customers. By combining elements of information technology and telecommunication networks, MEC further enables mobile network operators to open the radio access network (RAN) to authorized third parties such as application developers and content providers (see: https: / / en.wikipedia.org / wiki / Mobile_edge_computing).

[0005] Beyond being a rapidly growing technology concept, there are only a few practical implementations or unified methods for demonstrating MEC applications. Largely, this is due to the complexity of implementing and deploying such capabilities within the LTE RAN environment where subscriber and device security is a top priority. Additionally, even macro cellular networks with a physical proximity of eNBs (cell base station tower equipment, or even CRAN clusters associated with the transient nature in mobile devices) have no conductivity for many MEC applications. Therefore, the above MEC applications Using the mechanisms provided, it is intended to offload IP traffic locally to a local area network in the case of "offloading", where traffic destined for a private network, e.g., a company's private network, can be offloaded locally to a location where an eNB ( or small cell base station) is physically located near the destination LAN. However, these methods defined by 3GPP have not been commercialized, which means that they require a special service definition and cooperation with mobile network operators, including the definition of capabilities for the subscriber identity module (SIM) cards inserted into each mobile device. This level of management and coordination is infeasible for mobile network operators. Furthermore, there have been concerns expressed regarding potential conflicts with legal requirements for lawful interception court orders.

[0006] Public warning services and other mass notification solutions : According to the public alert service controlled by FEMA (Federal Emergency Management Agency), it is possible to simultaneously issue emergency alerts and mass notifications of instructions over multiple media such as cable TV, broadcast TV, AM / FM radio, and cellular networks. Authorized parties can "interface with" the PWS via a gateway hosted by FEMA. Such authorized parties include FEMA, FBI, state and some local law enforcement agencies, and NOAA in the case of severe weather events.

[0007] The public alert system is intended to alert people in situations that have a wide - reaching impact geographically and potentially. ​​​​​​​​and it is ideal to issue commands. Typically, these messages cover many counties, localities jurisdictions of municipalities / governments and law enforcement agencies. Covered by the public warning system The most well-known example in the type of "event" covered by the public warning system is probably in 1996 "Amber Alert" established to quickly resolve child abduction suspicions. There are detailed statistics and annual reports on the effectiveness of this Amber Alert law . There is no doubt that this Amber Alert has led to an improvement in the rescue of abducted children , but it still goes through a cumbersome and almost certainly necessary government work process . The following are the standardized Amber Alert criteria, namely, (1) Law enforcement agencies must obtain evidence of the occurrence of abduction, (2) The child must be at no risk of serious injury or death, (3) There must be sufficient descriptive information about the child, the abductor, or the abductor's vehicle in issuing the alert, and (4) The child must be under 18 years old .

[0008] All uses of the domestic public warning system require monitoring and scrutiny to ensure that the system is used as intended and does not cause public panic or overreaction as a result of misuse, whether intentional or accidental .

[0009] Other examples of using the public warning system include the following, namely, notification of the escape of dangerous suspects, biohazards such as chemical spills, and notification of imminent bad weather events such as tornadoes .

[0010] ​​​​​​Interface connections to the public alert system that issues alert messages are based on access rights to the FEMA system. Submission of a message requires the following inputs, namely, (1) a Federal Information Processing Standard (FIPS) code (county code) representing the county affected, and (2) an alert message (in accordance with the prescribed convention), and various descriptors (urgency type, duration, severity, etc.). After submission to FEMA, the message is "forwarded" to distribution entities including mobile phone carriers based on the "Wireless Emergency Alert" (WEA) system. Ultimately, the mobile phone carriers forward the message to all eNBs operating in the affected county, generally dozens of eNBs covering dozens of square miles. Ultimately, all mobile phones present in the designated county receive the message, many of these devices being miles away from the incident site. As drawbacks of the public alert system, there are a relatively long lead time until message issuance, a wide coverage area (county / county group), the inability to provide any local-related information or instructions (lacking in granularity), and limited control access, resulting in restricted use. There are several systems available for making "mass notifications" to recipient groups using different media such as SMS text, voice calls, email, and combinations thereof. These systems are for predefined pre-stored messages and ad-hoc messages as the case may be.

[0011]

[0012]

[0013] Mass notification system : ​​​​​​​​​​​​​​Both can be combined. They are used for both on-demand situations and planned events. For example, an on-demand scenario is a school district that issues a school closure message as a result of heavy snowfall, and a planned event is a school district that issues a reminder regarding a planned parent / teacher conference. These systems are based on a predetermined recipient list that includes mobile phone numbers and email addresses.

[0014] Disadvantages of group notification systems include the following, namely, (1) the fact that these systems use static contact lists that include "opt-in" recipients, and (2) the lack of the ability to send location-related messages, and thus the lack of providing any message transmission with a location context.

[0015] Therefore, what is needed is a mobile edge computing system that can issue cell-specific public warning system (PWS) messages customized to transmit only to each individual mobile phone (cell) within a specific location such as a site. SUMMARY OF THE INVENTION MEANS FOR SOLVING THE PROBLEM

[0016] In an aspect of the present invention, a mobile edge computing system includes a plurality of baseband devices, each of which is connected to a corresponding S1-mme interface, the baseband devices, and an aggregated S1-mme interface configured to be connected to a mobility management entity, the aggregated S1-mme interface being connected to the plurality of S1-mme interfaces, An S1-mme aggregator and an access component connected to the base, are provided. The S1-mme aggregator and the access component each aggregate a plurality of uplink S1-mme signals, which are signals from respective baseband devices, into an aggregated S1-mme signal and are configured to transmit the aggregated S1-mme signal on the aggregated S1-mme interface. The S1-mme aggregator and the access component further terminate a downlink S1-mme signal from the aggregated S1-mme interface, split the downlink S1-mme signal into a plurality of individual downlink S1-mme signals, route each of the individual downlink S1-mme signals to a corresponding S1- mme interface, and are configured to access the S1-mme uplink signal and the S 1-mme downlink signal. The mobile edge computing system further includes a management and network operation component connected to the S1-mme aggregator and the access component. The management and network operation component receives an alarm command from a field IT infrastructure having location information when an alarm request occurs, generates a write-rewrite alarm request message, and is configured to transmit the write-rewrite alarm request message to one or more baseband devices. In another aspect of the present invention, a method for supplying a local alarm message in an LTE network receives a cell restart indication signal from one of a plurality of S1-mme interfaces and is configured to... When an alarm request occurs, it receives an alarm command from a field IT infrastructure having location information, generates a write-rewrite alarm request message, and transmits the write-rewrite alarm request message to one or more baseband devices.

[0017] In another aspect of the present invention, a method for supplying a local alarm message in an LTE network receives a cell restart indication signal from one of a plurality of S1-mme interfaces and ​a step in which each of the plurality of S1-mme interfaces is connected to a baseband device a corresponding receiving step, a step of retrieving cell information from the cell restart indication signal a step of storing the cell information, and aggregating the plurality of S1-mme S1-mme interfaces into an aggregated S10-mme interface including the cell restart indication signal and a step of aggregating.

[0018] In still another aspect of the present invention, a method for supplying a local warning message in an LTE network includes identifying a write-rewrite warning request signal in an S1-mme data stream from a mobility management entity retrieving message information from the write-rewrite warning request signal storing the message information, and routing the write-rewrite warning request signal to a baseband device corresponding to the message information and a step of routing.

[0019] In still another aspect of the present invention, in a method for supplying a local warning message in an LTE network a step of receiving a warning message command from a field IT infrastructure retrieving location information from the warning message command generating a write-rewrite warning request corresponding to the warning message command and an insertion step of inserting the write-rewrite warning request into a destination S1-mme data stream corresponding to a destination cell, where the destination S1-mme data stream is one of a plurality of S1-mme data streams, and each S1-mme data stream corresponds to at least one cell and a step of inserting. and a step of inserting.

Brief Description of the Drawings

[0020]

Figure 1

Figure 2

Figure 3a

Figure 3b

Figure 4a

Figure 4b

Figure 5a

Figure 5b

Best Mode for Carrying Out the Invention

[0021] Deployed within a venue such as a stadium, airport, hospital, or university campus or like A patron or edge warning system that can respond to the scene (hereinafter referred to as "Edge Warning System"). This edge warning system acquires the ability to be based within the core network of a mobile phone operator and also operates within the mobile edge computing domain, enabling operational capabilities that are not currently available. The available functionality can be incorporated within an edge warning system that can be integrated between one or more mobility management entities (MMEs) and baseband units (BBUs) of the RAN within the LTE radio access network (RAN). The edge warning system, as well as its subsystems and components, are within the scope of the mobile edge computing (MEC) domain, enabling mobile edge computing functions while maintaining compliance with existing LTE standards. By doing so, the edge warning system remains transparent to established evolved packet core (EPC) and RAN elements and ensures interoperability with these elements. According to the edge warning system, authorized people within the scene, generally representatives of the security room, can optionally act as wireless subscribers connected to the on-site LTE mobile phone infrastructure and send alarm messages to the mobile phone (cell). The edge warning system can selectively message all cells, individual cells, or combinations of cells, as determined by the situation.

[0022]

[0023] ​​​​​​​​​​​​​​​Enables the site to broadcast (broadcast) the message. This decision can be made as part of a predetermined emergency response plan or be ad hoc, such as in the case of an emergency. Examples include warning messages and instructions for events such as bad weather affecting the site, missing children, kidnapping suspicions, fires, threat of explosives, active shooter incidents, etc. According to the Edge Alert System, it enables simultaneous location-specific rapid broadcasts to a variety of mobile devices belonging to different mobile network operators. According to the Edge Alert System, it enables simultaneous location-specific rapid broadcasts to a variety of mobile devices belonging to different mobile network operators. The Edge Alert System is subordinate to the normal public alert system described above and is not an alternative. According to the Edge Alert System, it can deliver alert messages limited to cells (mobile phones) within the site and thus to mobile devices, and can deliver location-specific unique messages to each individual cell within the site, and can issue alert messages at the individual site level.

[0024] This system is transparent and coexistable with the existing national PWS mechanism, and thus all messages issued via the national PWS are also issued to the cells within the site. The ability to communicate location-specific alert information to all mobile devices within a given site can be particularly effective for sites with many cells spread over a relatively large area, such as a college campus, and for visitors to these sites who are unfamiliar with the site's facilities, exits, emergency procedures, etc. The ability to communicate location-specific alert information to all mobile devices within a given site can be particularly effective for sites with many cells spread over a relatively large area, such as a college campus, and for visitors to these sites who are unfamiliar with the site's facilities, exits, emergency procedures, etc. issued via the national PWS are also issued to the cells within the site. The ability to communicate location-specific alert information to all mobile devices within a given site can be particularly effective for sites with many cells spread over a relatively large area, such as a college campus, and for visitors to these sites who are unfamiliar with the site's facilities, exits, emergency procedures, etc. and for visitors to these sites who are unfamiliar with the site's facilities, exits, emergency procedures, etc. and for visitors to these sites who are unfamiliar with the site's facilities, exits, emergency procedures, etc. This ability can be particularly effective for sites with many cells spread over a relatively large area, such as a college campus,

[0025] Figure 1 shows an exemplary LTE network edge system 100 according to the present disclosure. System 100 includes an evolved packet core (EPC) 105 and one or more mobile ducts It includes Mobility Management Entities (MMEs) 110, and each MME is connected to the Edge Alarm System 120 via an aggregated S1-mme interface 112. Both the MMEs 110 and the (aggregated) S1-mme interfaces can be part of a standard LTE subsystem defined under the appropriate 3GPP specifications. Both the MMEs 110 and the (aggregated) S1-mme interfaces can be part of a standard LTE subsystem defined under the appropriate 3GPP specifications. can be.

[0026] The Edge Alarm System 120 is connected to a plurality of Baseband Units 115 via a plurality of corresponding S1-mme interfaces 114. Each S1-mme interface 114 can be implemented to be the same as each other and the aggregated S1-mme interface 112, and can also comply with the relevant 3GPP specifications. The Edge Alarm System 120 is further connected to the local on-site IT infrastructure 130 via one or more Ethernet connections. Each S1-mme interface 114 can be implemented to be the same as each other and the aggregated S1-mme interface 112, and can also comply with the relevant 3GPP specifications. The Edge Alarm System 120 is further connected to the local on-site IT infrastructure 130 via one or more Ethernet connections. The local on-site IT infrastructure 130, which will be further described below, can include one or more IT systems related to on-site security and business operations. The local on-site IT infrastructure 130, which will be further described below, can include one or more IT systems related to on-site security and business operations. The local on-site IT infrastructure 130, which will be further described below, can include one or more IT systems related to on-site security and business operations. The local on-site IT infrastructure 130, which will be further described below, can include one or more IT systems related to on-site security and business operations. can include.

[0027] Each Baseband Unit 115 can be respectively connected to a Distributed Antenna System (DAS) 121 via an interface 116 and a fronthaul connection 117. The fronthaul connection 117 can be a standard digital wireless communication link as defined by the Common Public Radio Interface (CPRI) or the Open Base Station Architecture Initiative (OBSAI). The DAS 121 can include one or more Remote Units (RUs) 122, each of which is connected to one or more antennas 123. The fronthaul connection 117 can be a standard digital wireless communication link as defined by the Common Public Radio Interface (CPRI) or the Open Base Station Architecture Initiative (OBSAI). The DAS 121 can include one or more Remote Units (RUs) 122, each of which is connected to one or more antennas 123. The fronthaul connection 117 can be a standard digital wireless communication link as defined by the Common Public Radio Interface (CPRI) or the Open Base Station Architecture Initiative (OBSAI). The DAS 121 can include one or more Remote Units (RUs) 122, each of which is connected to one or more antennas 123. The fronthaul connection 117 can be a standard digital wireless communication link as defined by the Common Public Radio Interface (CPRI) or the Open Base Station Architecture Initiative (OBSAI). The DAS 121 can include one or more Remote Units (RUs) 122, each of which is connected to one or more antennas 123. The fronthaul connection 117 can be a standard digital wireless communication link as defined by the Common Public Radio Interface (CPRI) or the Open Base Station Architecture Initiative (OBSAI). The DAS 121 can include one or more Remote Units (RUs) 122, each of which is connected to one or more antennas 123. can include.

[0028] It will be apparent that changes to system 100 are possible and within the scope of the present disclosure. For example, one or more additional DAS systems 121 can be present and connected to the baseband device 115, or the DAS 121 can be replaced or supplemented by one or more small cell systems or large cellular systems. It will be readily appreciated that such changes are possible and within the scope of the present disclosure.

[0029] FIG. 2 shows an exemplary LTE network edge 100 including an edge alert system 120, a local on-site IT infrastructure 130, and a plurality of baseband processors 115, each baseband processor connected to one or more cells 235, each cell 235 capable of having a wireless remote unit and associated antennas and / or one or more DAS systems 121 (not shown).

[0030] With reference to FIG. 2, the local on-site IT infrastructure can be various IT systems dedicated to a particular site such as a stadium, airport, shopping mall, university campus, etc. The local on-site IT infrastructure can include IT systems and protocols for guard houses, business offices, data centers, etc. Each of these can be a stand-alone IT system or different functions within one or more integrated IT systems.

[0031] The edge alert system 120 includes a Mobility Services Engine (MSE) subsystem 210, and this subsystem 210 includes an S1-Conn component ​​​​​​​​​​​​​ a network 215, as well as management and network operation (MANO) components 220. The edge alarm system 120 further includes an application server sub system 225, and this subsystem 225 has an application program interface (API) 230. Each of these subsystems and components is implemented in software operating on one or more processors (not shown) connected to one or more non-volatile memory components that encode instructions for realizing the functions of each of these subsystems and components . Alternatively, each of these components can be implemented on a dedicated processor or dedicated special-purpose hardware . The edge alarm system 120 can be placed inside the eNodeB within or near the site, or can be co-located with the local site IT infrastructure . Further, the processors within the edge alarm system 120 can be distributed across various sites including one or more e NodeBs and / or the local site IT infrastructure .

[0032] The mobile service engine (MSE) 210 has an S1-Conn component (or host ) 215, as well as management and network operation (MANO) components 220. S1-Conn 215 and MANO 220 can be implemented in software using different languages to conform to their different requirements and modes of operation . For example, S2-Conn 215 performs real-time operations with S1-mme signals entering and exiting interfaces 112 and 114, due to which C ​ or can be implemented in C++, and MANO does not have such strict real-time requirements and must provide greater flexibility, and thus can be implemented on a platform such as JA VA. Both of these components can be stored as machine-readable instructions in non-volatile memory connected to one or more processors within the domain of MSE210.

[0033] S1-Conn215 implements the functions of a real-time S1-mme aggregator and access component First, the uplink S1-mme data from each of the plurality of S1-mme interfaces 114 is aggregated as a single uplink aggregated S1-mme interface 1 12. Second, the downlink aggregated S1-mme interface 112 is terminated, and the downlink S1-mme data is split into a plurality of S1-mme interfaces 11 4 and the appropriate S1-mme data is routed to the appropriate BBU115. The details of these functions are described in more detail below. Third, the S1-mme traffic on the aggregated S1-mme interface 112 is monitored, and public warning system (PWS) related traffic from the MMEs110 is identified and logged (recorded). Fourth, the PWS related traffic from the BBUs115 is monitored on the S1-mme interface 114 and blocked sometimes. Fifth, local specificity warning messages (received from MANO220) are formatted and generated, and each corresponding S1-mme interface 114 is used to send this message to the appropriate one or more BBUs115. These functions are described in more detail below. Third, the S1-mme traffic on the aggregated S1-mme interface 112 is monitored, and public warning system (PWS) related traffic from the MMEs110 is identified and logged (recorded). Fourth, the PWS related traffic from the BBUs115 is monitored on the S1-mme interface 114 and blocked sometimes. Fifth, local specificity warning messages (received from MANO220) are formatted and generated, and each corresponding S1-mme interface 114 is used to send this message to the appropriate one or more BBUs115. ring and sometimes blocking. Fifth, local specificity warning messages (received from MANO220) are formatted and generated, and each corresponding S1-mme interface 114 is used to send this message to the appropriate one or more BBUs115. ring and sometimes blocking. Fifth, local specificity warning messages (received from MANO220) are formatted and generated, and each corresponding S1-mme interface 114 is used to send this message to the appropriate one or more BBUs115. ​​

[0034] MANO220 performs the maintenance of the edge warning system 120 and the operation of the network ration. First, it receives the PWS message copied or blocked from S1-mme interfaces 112 and 114 by S1-Conn215, and logs the relevant data included in these messages. Second, it receives the alarm message transmission request from the local on-site IT infrastructure via API230, and converts this message information into data that can be used by S1-Conn215 to direct towards one or more appropriate cells 215. Both of these functions are described below.

[0035] The application server 225 provides an application programming interface (API) 230 that hosts any application running with local on-site IT infrastructure access, and provides a signal transmission and data conduit from MSE210 to the application running on the on-site IT infrastructure 130.

[0036] The edge warning system 120 performs three basic functions, namely, receiving and logging the PWS restart indication signal from each BBU via interface 114; receiving the PWS message from MME110, logging it, and routing it to each cell 235 via the corresponding BBU115 without being inhibited; and generating local-specific PWS messages and transmitting these messages to the appropriate cells 235 via the corresponding BBU115. Each of these functions is further described below.

[0037] Figures 3a and 3b show the signal flow and timing chart for receiving and logging data from each BBU during process 300 and at restart.

[0038] In step 310, one or more BBUs 115 restart and send a signal indicating that the cell has restarted. An example of a cell restart indication signal is the PWS restart indication message that the BBU 115 sends to the MME 110 via the S1-mme interface 114. S1-Conn215 executes instructions to detect each PWS restart indication at each S1-mme interface 114. In step 330, S1-Conn215 copies the data from each received PWS restart indication and sends this data to the MANO 220. In doing so, S1-Conn215 can receive the following information, namely the cell ID, the emergency area ID, and the tracking area ID, along with the timestamp. In step 340, the MANO 220 receives the data from S1-Conn215 and stores it in a memory that can be a non-volatile memory. In doing so, the MANO 220 maintains a list of all active cells 235 that are ready to receive alarm messages, along with their corresponding cell IDs, etc.

[0039] In step 320, S1-Conn215 executes instructions to aggregate each of the S1-mme streams received from each BBU 115 via the corresponding interface 114, including the copied PWS restart indication, and sends the aggregated S1-mme stream on the aggregated S1-mme interface 112 to the MME 110. In doing so, In step 310, the S1-Conn 215 contains the PWS restart indication received, and and thus the presence of S1-Conn215 is not detected, and each Aggregates S1-mme data to provide transparency into communication between the BBU 115 and the MME 110 And will broadcast it again.

[0040] FIG. 3b shows a signal flow and timing diagram of the process 300. 1 is an example of multiple PWS restart indications from multiple BBUs 115 via multiple interfaces 114. However, any given iteration of process 300 may include a PWS restart assertion from a single cell 235. Note that for a single receive, it is possible to perform the process 300 with a single receive. Boost mode from receiving multiple simultaneous PWS restart indications, as long as it is possible or received In the S1-mme interface 114, data copying and aggregation are performed in real time. The communication between the BBU 115 and the MME 110 is not impeded, and the S1-Conn It will be appreciated that 215 remains in a transparent state.

[0041] 4a and 4b respectively show a process 400 and a process for sending a PWS message to the MME 110. to the appropriate BBU 115 and collects and records PWS message information originating from the MME. The PWS message information from each BBU115 is stored in the S1-mme Signal flow and timing chart for transmission to MME 110 over interface 112 Indicates the route.

[0042] In step 405, the S21-Conn 215 receives a write-rewrite command from the MME 110. Execute an instruction to monitor the aggregation S1-mme interface 112 to detect that an alarm request (W-RWReq) is being received. After S1-Conn215 detects the W-RWReq, proceed to steps 410 and 420. In step 410, S1-Conn215 copies relevant data from the message and sends this to MANO220. The W-RWReq data copied by S1-Conn215 includes a message identifier and a serial number, and can also optionally include a tracking area ID, a cell ID (if any), and a timestamp. In step 415, MANO220 can store some or all of these data in non-volatile memory. The purpose of doing this is to enable MME210 (especially MANO220) to generate an alarm message that does not conflict with an alarm message from MME110 via conflicting or duplicate data by logging the message identifier and serial number of the identified write-rewrite alarm request. In step 420, S1-Conn215 executes an instruction to route the received W-RWReq to the appropriate BBU114. If the W-RWReq includes a cell ID or a tracking area ID, S1-Conn215 queries MANO220 to identify the corresponding BBU115 for either the tracking area ID or the cell ID (this information is logged by MANO in step 340), and then routes that W-RWReq to the appropriate BBU115 via the corresponding S1-mme interface 114.

[0043]

[0044] ​​​​​​​​​​​​​​​It does. Optionally, S1-Conn215 can simply broadcast W-RWReq to all BBU115 and report it. S1-Conn215 can, at the same time, or as close to the same time as possible, perform steps 410 and 420 to ensure the transparency of S1-Conn215 in the communication link between MME110 and each BBU115 be noted.

[0045] After each BBU115 receives the corresponding write-rewrite alarm request, it generates a write-rewrite alarm response (W-RWResp) and also returns it to the MME via the corresponding S1-mme interface 114

[0046] In step 425, S1-Conn215 detects each W-RWResp transmitted via the corresponding S1-mme interface 114 by each BBU115 Next, in step 430, S1-Conn215 aggregates the S1-mme data stream including the W-RWResp from the S1-mme interface 114 and also transmits it to MME110 on the aggregated S1-mme interface 112. Optionally, S1-Conn215 can copy its response data and also transmit it to MANO220 for logging

[0047] When the authorized entity involved in transmitting the PWS message via MME110 chooses to do so, a stop alarm request (SWReq) can be sent to BBus115 When that happens, S1-Conn215, which monitors the S1-mme traffic from the aggregated S1-mme interface 112 ​​​​​​​ detects the presence of SWReq. At step 440, S1-Conn215 routes the SWR eq to the appropriate BBUs115. In doing so, if SWReq contains a tra cking area ID, S1-Conn copies the tracking area ID from the message and also queries the MANO220 for the cell ID corresponding to the tracking area ID Along with these cell IDs, S1-Conn215 can selectively route the SWReq to the appropriate BB Us115. Alternatively, S1-Conn215 can simply broadcast the SWReq to all BBUs115. Regardless of the approach adopted , S1-Conn215 relays the SWReq in real time to maintain transparency .

[0048] After each BBU115 receives a stop alarm request, it takes appropriate action and can send the stop alarm request (SWReq) to the MM E110 via the corresponding S1-mme interface 114. At step 445, S1-Conn215, which monitors the traffic from each S1-mme interface 114, detects the SWReq. S1-Conn215 copies the data from each detected SWReq and also sends that information to the MANO220, which can then log information indicating that the alarm message has ended. This is optional .

[0049] At step 450, S1-Conn215 aggregates each S1-mme data stream containing SWResp from the S1-mme interface 114 and also aggregates it into an aggregated S It is transmitted to the MME 110 over the 1-mme interface 112 .

[0050] FIG. 4 b shows a signal flow and timing diagram illustrating the process 400 .

[0051] 5a and 5b are diagrams illustrating a process 500 and a specific cell, respectively, in accordance with the present disclosure. Signal flow and timing control for locally generating and providing location-specific alarm messages Referring to FIG. 5a, steps 510 to 535 are performed when the MSE 210 detects an alarm. generating a message and transmitting it to one or more cells 235. Steps 540 to 550 are for receiving responses from the BBUs 115 corresponding to the appropriate cells 235. Steps 555 to 570 include a step of receiving a response from the MSE 210. sending a stop message request to the cell 235; and step 57 5 to 585 are the appropriate stop message messages from the BBUs 115 corresponding to the appropriate cells 115. The method includes receiving a response.

[0052] In steps 505 and 510, MANO 220 receives application authorization from an authorization officer. The alarm message is sent via the on-site IT infrastructure 130 and API 230 in the application server 225. The location request may be sent to the location information or location identifier (e.g., a specific university) corresponding to the alert message. all cell devices in a building, all cell devices in a particular area of ​​a stadium, etc.) Each of these locations is identified by one or more Cell IDs. or identify as one or more "emergency zones" as described in more detail below. Authorized officers may send more than one alarm message, each corresponding to a distinct location identifier. can provide a page.

[0053] In step 515, if the cell ID is not provided by the guard room, MANO22 0 can execute an instruction to correlate location information with a specific cell ID. In this case, MA NO220 derives a desired cell identifier from a lookup table or a specified location Similar techniques can be implemented. There are numerous ways to implement this, and it can be understood that each of these is within the scope of the present invention disclosure. Further, MANO 220 can query information regarding the immediate response capability of cell 235 that receives an alarm message for its appropriate memory (i.e., MANO220 logs the PWN restart indication from BBU115 corresponding to cell 235).

[0054] Therefore, when the on-site cellular network is deployed, MANO220 can act as an important storage location for mapping cells to the emergency zone, whereby the guard room only needs to specify which message to direct to which emergency zone, and MANO 220 maps the emergency zone to the actual cell. Further, the guard room can issue a single alarm message to a cluster of emergency zones (a subset of the total number of emergency zones), and / or perform individual distribution of messages to a cluster of emergency zones. For example, several adjacent emergency zones within the core area can be designated to receive a set of message sets, and the remaining emergency zones can be designated to receive individual messages, where some of the individual messages are shared with the core area and some are For example, several adjacent emergency zones within the core area can be designated to receive a set of message sets, and the remaining emergency zones can be designated to receive individual messages, where some of the individual messages are shared with the core area and some are specified to receive individual messages, and some of the individual messages are shared with the core area and some are For example, the emergency zone may be obvious or obvious. An order to proceed to a specific exit that may not be white, to continue or stay in place The command may be to:

[0055] In steps 520 and 525, MANO 220 receives instructions to: That is, by pairing messages with their corresponding cell IDs and The alarm message and the corresponding cell are sent to each BBU 115 via the interface 114. Executing a command to send the identifier to the S1-Conn 215 for transmission to the associated BBU 115 With respect to step 520, MANO 220 may further Message identifiers and serial numbers that are not clear among those identified and stored in the By using the message number, the MS The E210 must prevent collision or confusion with existing messages sent by the MME110. This is because MANO 220 is identified in step 405 and recorded in step 415. The message identifier and serial number of the previously identified W-RWReq are stored in a non-volatile manner. and if there is a match, determining whether the message identifier and / or the message identifier is different. or deriving a serial number.

[0056] In step 530, the S1-Conn 215 receives the appropriate 114 to transmit to the appropriate cell 235. Executes instructions to format data for a write-over alarm request to be inserted into do.

[0057] Steps 505 to 530 can be executed once for the message cluster received by the on-site IT infrastructure 130, or these steps can be repeated once for each received message and executed. If the latter is true, at step 535, MANO2 20 can query the application server 225 to determine whether there are other alarm messages and whether the corresponding location information is waiting to be sent . If so, the process 500 returns to step 505 and repeats from step 5 30 with the next message. If not, the process 500 proceeds to step 540. Therefore, at the end of step 535 (or step 530 if all alarm messages to be sent are processed in one pass ), the MSE 210 sends all the requested alarm messages provided by the security room via the on-site IT infrastructure 1

[0058] 30 to the appropriate cell 235 via the corresponding BBUs 115 and the S1-mme interface 114. At this point in the process 500, the MSE 210 is waiting for a response from each of the BBUs 115 . At step 540, the S1-Conn 215 executes an instruction to monitor each S1-mme interface 114 for a write-rewrite alarm response (W-RWResp) via the BBU 115 from each cell 235 . After detecting the W-RWResp, the S1-Conn 215 blocks and terminates this W-RWResp so that it is not transferred to the MME 110. This is to ensure that no W-RWReq sent from the MME 110

[0059] is affected. is related. After detecting the W-RWResp, the S1-Conn 215 blocks and terminates this W-RWResp and transfers it to the MME 110 so that it is not transferred. This is to ensure that no W-RWReq sent from the MME 110 is affected. Receiving W-RWResp without association causes confusion within EPC105 This is to prevent such a situation.

[0060] In step 545, S1-Conn215 transfers all or a part of the W-RWResp indicating that the response has been received from the cell ID indicated by the response to MANO220. Further, in step 550, MANO220 logs the relevant information indicating that cell 235 corresponding to the cell ID in the W -RWReq is executing (or has executed) its command. Steps 540 to 550 are repeated for each blocked W-RWResp received by S1-Conn215 until each W-RWReq sent by MSE210 is received. At this point in process 500, MSE210 waits for instructions from the security room via the on-site IT infrastructure 130 to terminate the alarm message

[0061] In step 555, MANO220 receives instructions from the security room via the on-site IT infrastructure 130 and API230 to terminate the alarm message. In response to this, in step 560, MANO220 generates a stop alarm request (SWReq) with a cell ID corresponding to the location indicated by the cell ID or the request from the security room In doing so, if the request from the security room identifies an emergency zone, MANO 220 must correlate the location information or the emergency zone with the specific cell ID, and this correlation will be included in the SWReq.

[0062] In step 565, MANO220 generates it for transmission to the appropriate cell 215​​​​​​​ Relay the SWReq data to S1-Conn215. Also, in step 570, S2-Conn215 inserts the message data into the appropriate S1-mme interface 114 for transmission to the designated cell 235 via the corresponding BBU115. Steps 555 to 570 are repeated each time a W-RWReq is sent.

[0063] In step 575, S1-Conn210 executes an instruction to monitor each S1-mme interface 114 to identify and block each stop alarm request (SWResp) issued by each cell 250 via the BBU115. After S1-Conn210 identifies the SWResp, it terminates the signal and searches for data for relaying to MANO220 in step 580. Further, regarding step 580, MANO220 updates the logged PWS message information indicating that the cell ID indicated by the retrieved SWResp has ended the alarm.

[0064] In step 585, MANO220 sends a response to the guard room via the application server 25 and the on-site IT infrastructure 130 indicating that the alarm message has ended and that the message has been completed in a certain cell 235.

[0065] Each iteration of steps 555 to 570 is necessary to cover all the messages sent before the process can proceed to steps 575 to 585. Therefore, at any time, MSE210 implements either sequence of steps 555 to 570 and 575 to 585 based on the timing of receiving the SWResp signal. ​​​​​​​​​​​​It can execute instructions for doing so.

Claims

1. In a method for a warning system to supply a warning message in an LTE (Long Term Evolution) network, monitoring an aggregated data stream associated with a plurality of Mobility Management Entities (MMEs), wherein the aggregated data stream includes a plurality of S1-mme data streams, and each of the plurality of S1-mme data streams is routed from a corresponding one of the plurality of MMEs; dividing the plurality of S1-mme data streams; identifying a write-rewrite warning request signal including warning message information in a given one of the plurality of S1-mme data streams; acquiring the warning message information from the write-rewrite warning request signal; storing the warning message information; routing the write-rewrite warning request signal including the warning message information to a baseband device corresponding to the warning message information; A method comprising:

2. The method according to claim 1, wherein the warning message information includes a cell ID.

3. The method according to claim 1, wherein the warning message information includes a message identifier.

4. The method according to claim 1, wherein the warning message information includes a serial number.

5. The method according to claim 1, further comprising terminating a given one of the S1-mme data streams from the Mobility Management Entity.

6. receiving a warning message transmission request from an Information Technology (IT) infrastructure related to a local site; selectively transmitting the warning message transmission request to a cell via a baseband device based on information in the warning message transmission request, wherein the cell is associated with a corresponding location within the local site; The method according to claim 1, further comprising:

7. receiving a warning message transmission request from an Information Technology (IT) infrastructure related to a local site; selectively broadcasting the warning message transmission request to a plurality of cells via one or more baseband devices based on information in the warning message transmission request; Each of the plurality of cells receives the alarm message transmission request from a corresponding one of the one or more baseband devices, Each of the plurality of cells is associated with a corresponding different position within the local site, the method according to claim 1. **Claim 8** Two or more of the plurality of cells receive the alarm message transmission request via one baseband device of the one or more baseband devices, the method according to claim 7. **Claim 9** Receiving an alarm message transmission request from an information technology (IT) infrastructure related to a local site; Selectively broadcasting the alarm message transmission request to a plurality of mobile devices located within the local site, each of the plurality of mobile devices being associated with the same mobile phone operator; The method according to claim 1, further comprising. **Claim 10** An aggregation component that communicates with at least one mobility management entity (MME) via a corresponding at least one first S1-mme interface and communicates with at least one baseband device via a corresponding at least one second S1-mme interface; A management and network operation (MANO) component that communicates with the aggregation component and communicates with an information technology (IT) infrastructure of a local site, comprising: The aggregation component identifies a write-rewrite alarm request signal in an S1-mme data stream from one of the at least one MME, obtains message information from the write-rewrite alarm request signal, and routes the write-rewrite alarm request signal to a specific baseband device among the at least one baseband device corresponding to the message information; The MANO stores the message information, a mobile phone network alarm system for a local site. **Claim 11** The mobile phone network alarm system for a local site according to claim 10, wherein the message information includes a cell ID corresponding to a cell associated with a specific baseband device among the at least one baseband device. **Claim 12** The mobile phone network alarm system for a local site according to claim 10, wherein the message information includes a message identifier. **Claim 13** The message information includes a serial number, and is a local on-site mobile phone network warning system according to claim 10.

14. The aggregation component further terminates an S1-mme data stream from the mobility management entity, and is a local on-site mobile phone network warning system according to claim 10.

15. The MANO further receives an alarm message transmission request from an IT infrastructure related to a local site, The aggregation component further selectively transmits the alarm message transmission request to a cell via the one baseband device based on information in the alarm message transmission request, The cell is associated with a corresponding location within the local site, and is a local on-site mobile phone network warning system according to claim 10.

16. The MANO further receives an alarm message transmission request from an IT infrastructure related to a local site, The aggregation component further selectively broadcasts the alarm message transmission request to a plurality of cells via the at least one baseband device based on information in the alarm message transmission request, Each of the plurality of cells receives the alarm message transmission request from a corresponding one of the at least one baseband device, Each of the plurality of cells is associated with a corresponding different location within the local site, and is a local on-site mobile phone network warning system according to claim 10.

17. Two or more of the plurality of cells receive the alarm message transmission request via one baseband device of the at least one baseband device, and is a local on-site mobile phone network warning system according to claim 16.

18. The MANO further receives an alarm message transmission request from an IT infrastructure related to a local site, The aggregation component further selectively broadcasts the alarm message transmission request to a plurality of mobile devices located at the local site, Each of the plurality of mobile devices is associated with the same mobile phone operator, and is a local on-site mobile phone network warning system according to claim 10. A computer functioning as a mobile edge warning system operating in an LTE (Long Term Evolution) network, monitoring an aggregated data stream associated with a plurality of mobility management entities (MMEs), the aggregated data stream including a plurality of S1-mme data streams, each of the plurality of S1-mme data streams being routed from a corresponding one of the plurality of MMEs; dividing the plurality of S1-mme data streams; identifying a write-rewrite warning request signal including warning message information in a given one of the plurality of S1-mme data streams; obtaining the warning message information from the write-rewrite warning request signal; storing the warning message information; routing the write-rewrite warning request signal including the warning message information to a baseband device corresponding to the warning message information; A program for causing the above to be executed.

Images