JP7408540B2 - Edge-based location-specific alert system for LTE networks - Google Patents

Description

The present invention relates to wireless communications, and more particularly to LTE mobile edge computing that localizes local emergency response and alerts to UEs within a scene or area, and provides location-specific alerts within a scene or area. related to the management system.

LTE-based mobile phone networks allow mobile phone operators to implement many features from within an Evolved Packet Core (EPC) network. The EPC interface interfaces with the Radio Access Network (RAN), which is how mobile devices ultimately connect to a mobile operator's network.

LTE base stations or eNodeBs (eNBs) are the main elements of the RAN that generate radio signals and regulate access and connectivity for mobile devices. Generally, an eNB is subordinate to its elements within the EPC. Therefore, features, functions and capabilities implemented "above the RAN" are transparent to the eNB. However, due to the relatively close proximity of eNBs to mobile devices and, by extension, to users of those mobile devices, eNBs would ideally have slightly improved functionality that would be beneficial to mobile devices and users. It is suitable for implementing functions loosely referred to as "mobile edge computing" (MEC).

Mobile Edge Computing (MEC) :
MEC is a network architecture concept that enables cloud computing capabilities and IT service environments at the edge of cellular networks. The basic idea behind MEC is that by running applications and performing related processing tasks closer to cellular customers, network congestion is reduced and applications are better executed. MEC technology is designed to be implemented in cellular base stations and enables flexible and rapid deployment of new applications and services to customers. Combining information technology and telecommunications network elements, the MEC also enables mobile phone operators to open up their radio access networks (RANs) to authorized third parties such as application developers and content providers. (see: https://en.wikipedia.org/wiki/Mobile edge computing).

Beyond being a rapidly growing technology concept, there are only a few practical implementations or uniform ways to demonstrate MEC applications. In large part, this is due to the complexity of implementing and deploying such capabilities within an LTE RAN environment where subscriber and device security is paramount. Furthermore, the macro cellular network with the physical proximity of the eNB (cell base station tower equipment, or even CRAN clusters tied to the ephemeral nature of mobile devices) is not suitable for many MEC applications. No conductivity. Therefore, the MEC application mentioned above uses 3GPP defined mechanisms like LIPA (Local IP Access), Selective IP Traffic Offload (SIPTO) to locally transfer IP traffic to the local area network. "offloading" traffic destined for a private network, for example a company's private network, to a location where an eNB (or small cell base station) is physically located near the destination LAN. can be offloaded locally. However, these methods defined by 3GPP have not been put into practical use, meaning that they require special service definitions and coordination with mobile phone operators, including subscriptions inserted into each mobile device. Contains capability definitions for SIM card. This level of control and coordination makes it unfeasible for mobile phone operators. Additionally, there have been concerns expressed about the potential conflict with legal requirements for lawful inspection (wiretapping) court orders.

Public alert services and other mass notification solutions :
Public alert services controlled by FEMA (Federal Emergency Management Agency) provide mass notification of emergency alerts and orders simultaneously on multiple media such as cable television, broadcast television, AM/FM radio, and cellular networks. make it possible to do. Authorized parties can "interface with" a PWS via a FEMA-hosted gateway. Such authorized parties include FEMA, the FBI, some state and local law enforcement agencies, and NOAA in the event of an emergency severe weather event.

Ideally, public warning systems issue warnings and orders in situations where the impact on people is widespread, both geographically and potentially. Typically, these messages cover many county, municipal/government and law enforcement jurisdictions. Perhaps the best-known example of the type of "event" covered by a public alert system is the "Amber Alert" established in 1996 to quickly resolve child abduction allegations. ”. There are detailed statistics and annual reports on the effectiveness of this Amber Alert law. While this Amber Alert has undoubtedly improved the rescue of abducted children, it still involves a lengthy and arguably necessary red tape process. Standardized Amber Alert criteria include: (1) law enforcement must have evidence that an abduction has occurred; and (2) there must be a risk of serious injury or death to the child. , (3) there must be sufficient descriptive information about the child, the abductor, or the abductor's vehicle to trigger an alert, and (4) the child must be under 18 years of age.

All uses of national public warning systems 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. requires a degree of monitoring and scrutiny.

Other examples of public alert system uses include: notification of dangerous suspect escape incidents, biohazard notifications such as chemical spills, notifications of impending severe weather events such as tornadoes.

The interface connection to the public alert system that issues alarm messages is based on authorized access to the FEMA system. Submission of a message requires the following input: (1) the Federal Information Processing Standards (FIPS) code representing the affected county (County Code); and (2) the alert message (according to the regulatory treaty) and various descriptions. child (urgency type, duration, severity, etc.).

After submission to FEMA, the message is "forwarded" to distribution entities, including cell phone carriers under the "Wireless Emergency Alert" (WEA) regime. Ultimately, the cell phone operator will forward the message to all eNBs serving the affected county, typically as many as several dozen eNBs covering hundreds of square miles. Ultimately, all cell phones in a given county will receive the message, even if many of these devices are miles away from the crime scene.

Disadvantages of public warning systems include relatively long lead times for message issuance, wide dissemination areas (counties/counties), inability to provide any locally relevant information or instructions (lack of granularity), and limitations. controlled access, resulting in limited use.

Collective notification system :
There are several systems available for "mass notification" to a group of recipients using different media such as SMS text, voice call, email, and combinations thereof. These systems can combine both predetermined pre-stored messages and ad hoc messages. They are used for both on-demand situations and scheduled events. For example, an on-demand scenario is a school district issuing a school closure message as a result of heavy snowfall, and a planned event is a school district issuing a reminder regarding scheduled parent/teacher conferences. These systems are based on predetermined recipient lists that include mobile phone numbers and email addresses.

Disadvantages of mass notification systems include: (1) their use of static contact lists that include “opt-in” recipients; and (2) their ability to send location-related messages. , and therefore does not provide any messaging with location context.

What is needed, therefore, is a mobile device that can issue cell-specific public warning system (PWS) messages that are customized to localize and transmit to each individual cell phone (cell) within a specific location, such as a field site.・It is an edge computing system (mobile edge computing system).

In an aspect of the invention, a mobile edge computing system connects to a plurality of baseband devices, each connected to a corresponding S1-mme interface, and to a mobility management entity. and an S1-mme aggregator and access component connected between the plurality of S1-mme interfaces and the aggregated S1-mme interface. The S1-mme aggregator and access component aggregate a plurality of uplink S1-mme signals, each of which is a signal from each baseband device, as an aggregate S1-mme signal, and the aggregate S1-mme signal is integrated into the aggregate S1-mme signal. Configured to transmit on the mme interface. The S1-mme aggregator and access component further terminates the downlink S1-mme signal from the aggregated S1-mme interface and converts the downlink S1-mme signal into a plurality of individual downlink S1-mme signals. and is configured to route each individual downlink S1-mme signal to a respective corresponding S1-mme interface and to access the S1-mme uplink signal and the S1-mme downlink signal. The mobile edge computing system further comprises a management and network operations component connected to the S1-mme aggregator and access component. The management and network operations component receives an alarm command from the field IT infrastructure, where the alarm request includes location information, and generates a write-rewrite alarm request message, and sends the write-rewrite alarm request message to one or more of the write-rewrite alarm request messages. baseband equipment.

In another aspect of the invention, a method for providing local alert messages in an LTE network includes the steps of: receiving a cell restart assertion signal from one of a plurality of S1-mme interfaces, the method comprising: -mme interfaces each correspond to a baseband device, the receiving step, the step of retrieving cell information from the cell restart assertion signal, the step of storing the cell information, and the plurality of S1-mmeS1-mme and aggregating the interfaces into an aggregate S10-mme interface that includes the cell restart assertion signal.

In yet another aspect of the invention, a method for providing localized alert messages in an LTE network includes the steps of: identifying a write-rewrite alert request signal in an S1-mme data stream from a mobility management entity; The method includes retrieving message information from an alarm request signal, storing the message information, and routing the write-rewrite alarm request signal to a baseband device corresponding to the message information.

In yet another aspect of the invention, a method for providing localized alert messages in an LTE network, comprising:
receiving an alert message instruction from a field IT infrastructure; retrieving location information from the alert message instruction; generating a write-rewrite alert request corresponding to the alert message instruction; and the write-rewrite step. inserting an alert request into a destination S1-mme data stream corresponding to a destination cell, the destination S1-mme data stream being one of a plurality of S1-mme data streams, each S1-mme and the data stream corresponds to at least one cell.

1 illustrates an example mobile edge computing system in accordance with this disclosure. 1 illustrates an Edge Warning System that may be incorporated within an example mobile edge computing system. 2 illustrates an example process chart for collecting and storing PWS restart assertion information from each baseband device in accordance with this disclosure. 3 illustrates an example signal flow and timing diagram for collecting and storing PWS restart assertion information from each baseband device in accordance with this disclosure. FIG. Exemplary process chart for routing PWS messages from an MME to appropriate baseband devices, collecting and storing MME-derived PWS message information, and aggregating PWS message responses from each baseband device in accordance with the present disclosure shows. Exemplary signal flows for routing PWS messages from an MME to appropriate baseband devices, collecting and storing MME-derived PWS message information, and aggregating PWS message responses from each baseband device in accordance with the present disclosure. and a timing chart. 2 illustrates an example process chart for locally generating and providing location-specific alert messages to specific cells in accordance with the present disclosure. 3 illustrates an example signal flow and timing chart for locally generating and providing location-specific alert messages to specific cells in accordance with the present disclosure; FIG.

A Patron or Edge Warning System (hereinafter referred to as an "Edge Warning System") that can be deployed within or respond to a site such as a stadium, airport, hospital, or university campus. This edge alert system gains capabilities that can be based within a mobile operator's core network and deployed within the mobile edge computing domain, enabling operational capabilities not currently available. The available functionality is integrated within an LTE radio access network (RAN) between one or more Mobility Management Entities (MMEs) and the RAN's Baseband Units (BBUs). can be included within the resulting edge alarm system.

Edge alert systems, and their subsystems and components, fall within the Mobile Edge Computing (MEC) domain and enable mobile edge computing capabilities while maintaining compliance with existing LTE standards. . By doing so, the edge alert system remains transparent to, and ensures interoperability with, established Evolved Packet Core (EPC) and RAN elements.

According to the Edge Alert System, authorized persons in the field, typically representatives of the security office, can select a cell phone (cell) that acts as a wireless subscriber connected to the field LTE cell phone infrastructure. Enables the sending of information messages. Edge alert systems allow the field to selectively broadcast messages to all cells, individual cells, or combinations of cells as the situation dictates. This decision can be made as part of a predetermined contingency plan or ad hoc, such as when an emergency event occurs. Examples include warning messages and commands for events such as severe weather affecting the scene, missing children, suspected abductions, fires, explosives threats, active shooter incidents, etc. The Edge Alert System enables simultaneous, location-specific, rapid broadcasts to a variety of mobile devices belonging to different mobile phone carriers.

The Edge Alert System is subordinate to, and is not a replacement for, the regular public alert system described above. Edge alarm systems allow small localized capabilities to localize alarm messages to cells (mobile phones) and thus mobile devices within a field, and to deliver location-specific unique messages to each individual cell within a field. warning messages can be issued at the individual site level. This system is also transparent and co-existent with existing National PWS mechanisms, so that all messages originating via National PWS are also directed to cells within the field. The ability to communicate location-specific alarm information to all mobile devices within a given site is useful for sites with many cells distributed over a fairly large area, such as a college campus, as well as for site facilities, egress, emergency This can be especially effective for visitors to these sites who are unfamiliar with the time system, etc.

FIG. 1 shows an exemplary LTE network edge system 100 in accordance with the present disclosure. System 100 includes an Evolved Packet Core (EPC) 105 and one or more Mobility Management Entities (MMEs) 110, each MME connected to an Edge Alert System 120 via an aggregated S1-mme interface 112. Both the MMEs 110 and the (aggregated) S1-mme interface may be standard LTE subsystems defined under appropriate 3GPP specifications.

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 may be implemented identically to each other and to the aggregate S1-mme interface 112 and may comply with relevant 3GPP specifications. Edge alert system 120 is further connected to local on-site IT infrastructure 130 via one or more Ethernet connections. Local on-site IT infrastructure 130, described further below, may include one or more IT systems related to on-site security and business operations.

Each baseband device 115 may be connected to a distributed antenna system (DAS) 121 via an interface 116 and a fronthaul connection 117, respectively. Fronthaul connection 117 may be a standard digital wireless communications link as defined by the Common Public Radio Interface (CPRI) or the Open Base Station Architecture Initiative (OBSAI). DAS 121 may include one or more remote units (RU) 122, each connected to one or more antennas 123.

It will be appreciated that modifications 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 baseband equipment 115, or DAS 121 can replace or supplement one or more small cellular systems or large cellular systems. can do. It will be readily appreciated that such modifications are possible and within the scope of the present disclosure.

FIG. 2 shows an example LTE network edge 100 that includes an edge alert system 120, a local field IT infrastructure 130, and multiple baseband processors 115, each baseband processor connected to one or more cells 235. , each cell 235 may have a wireless remote device and associated antennas and/or one or more DAS systems 121 (not shown).

Referring to FIG. 2, the local on-site IT infrastructure may be a variety of IT systems dedicated to a particular site, such as a stadium, airport, shopping mall, university campus, etc. Local on-site IT infrastructure may include IT systems and protocols for security offices, business offices, data centers, and so on. Each of these may be a standalone IT system, or may be a different function within one or more aggregated IT systems.

Edge alert system 120 includes a Mobility Services Engine (MSE) subsystem 210 that has an S1-Conn component 215 and a management and network operations (MANO) component 220. Edge alert system 120 further includes an application server subsystem 225 having an application program interface (API) 230. Each of these subsystems and components includes one or more processors (not shown) connected to one or more non-volatile memory components that encode instructions that implement the functionality of each of these subsystems and components. ) can be implemented in software that runs on Alternatively, each of these components may be implemented on a dedicated processor or dedicated special purpose hardware. Edge alert system 120 may be located within an eNodeB at or near the site, or may be co-located with local site IT infrastructure. Additionally, the processors within edge alert system 120 may be distributed across a variety of sites including one or more eNodeBs and/or local field IT infrastructure.

Mobile Services Engine (MSE) 210 has an S1-Conn component (or host) 215 and a Management and Network Operations (MANO) component 220. S1-Conn 215 and MANO 220 can be implemented in software using different languages to suit their different requirements and manner of operation. For example, S2-Conn 215 can be implemented in C or C++ due to the need to perform real-time operations on the S1-mme signals to and from interfaces 112 and 114, and MANO It does not have strict real-time requirements and should provide greater flexibility and therefore can be implemented on a platform like JAVA. Both of these components may be stored as machine-readable instructions in non-volatile memory coupled to one or more processors within the domain of MSE 210.

S1-Conn 215 performs the functions of a real-time S1-mme aggregator and access component. First, uplink S1-mme data from each of multiple S1-mme interfaces 114 is aggregated as a single uplink aggregated S1-mme interface 112. Second, it terminates the downlink aggregate S1-mme interface 112 and also splits the downlink S1-mme data into multiple S1-mme interfaces 114 and routes the appropriate S1-mme data to the appropriate BBU 115. . The details of these functions are explained in more detail below. Third, S1-mme traffic on aggregated S1-mme interface 112 is monitored to identify and log public warning system (PWS) related traffic from MMEs 110. Fourth, monitor and occasionally block PWS-related traffic from BBUs 115 on S1-mme interface 114. Fifth, formatting and generating a local specificity alert message (received from MANO 220) and transmitting this message to the appropriate one or more BBUs 115 via their respective S1-mme interfaces 114. Send.

MANO 220 performs maintenance of edge alarm system 120 and network operations. First, it receives PWS messages copied or blocked by S1-Conn 215 from S1-mme interfaces 112 and 114 and logs the associated data contained in these messages. Second, data that can be used by S1-Conn 215 to receive alert message sending requests from local on-site IT infrastructure via API 230 and direct this message information to one or more appropriate cells 215. Convert to Both of these functions are described below.

The application server 225 hosts an application program interface (API) 230 that provides the functionality of the MSE 210 with any application running with local, on-site IT infrastructure access, and for signaling and data from the MSE 210. A conduit is provided to applications running on site IT infrastructure 130.

Edge alarm system 120 performs three basic functions: receives and logs PWS restart assertion signals from each BBUs via interface 114; receives, logs, and inhibits PWS messages from MME 110; route to each cell 235 via the corresponding BBU 115 without being routed; and generate locally specific PWS messages and transmit these messages to the appropriate cell 235 via the corresponding BBU 115. Each of these features is further described below.

Figures 3a and 3b illustrate a process 300 and signal flow and timing diagram for receiving and logging data from each BBU upon restart.

At step 310, one or more BBUs 115 restart and send a signal asserting that the cell has restarted. An example of a cell restart assertion signal is a PWS restart assertion message sent by BBU 115 to MME 110 via S1-mme interface 114. S1-Conn 215 executes instructions to detect each PWS restart assertion on each S21-mme interface 114. In step 330, S1-Conn 215 copies the data from each received PWS restart assertion and also sends this data to MANO 220. In doing so, S1-Conn 215 may receive the following information: Cell ID, Emergency Area ID, and Tracking Area ID, along with a timestamp. At step 340, MANO 220 receives data from S1-Conn 215 and stores it in memory, which may be non-volatile memory. In doing so, MANO 220 maintains a list of all active cells 235 that are ready to accept alert messages, along with their corresponding cell IDs, etc.

In step 320, S1-Conn 215 executes an instruction to aggregate each of the S1-mme streams received from each BBU 115 via the corresponding interface 114, including the copied PWS restart assertion, and also mme stream to MME 110 on aggregate S1-mme interface 112. In doing so, S1-Conn 215 includes the PWS restart assertion received in step 310 and transmits it unhindered, so that the presence of S1-Conn 215 is not detected and between each BBU 115 and MME 110. S1-mme data is aggregated and relayed to provide transparency to communication.

FIG. 3b shows a signal flow and timing diagram for process 300. Although this chart shows an example of multiple PWS restart assertions from multiple BBUs 115 via multiple interfaces 114, any given iteration of process 300 may be for a single receipt of a PWS restart assertion from a single cell 235. Note that you get Data copying and aggregation at the S1-mme interface 114 is performed in real time in boost mode from multiple simultaneous receptions of PWS restart assertions, as long as the process 300 can be executed or received in a single reception, and the BBU 115 and MME 110 It will be appreciated that communication between S1-Conn 215 and S1-Conn 215 remains transparent.

4a and 4b illustrate a process 400 and a S1 that routes PWS messages from an MME 110 to the appropriate BBU 115, collects and stores MME-derived PWS message information, and aggregates and aggregates PWS message information from each BBU 115, respectively. -mme interface 112 to MME 110;

In step 405, S21-Conn 215 executes an instruction to monitor aggregated S1-mme interface 112 to detect receiving a write-rewrite alert request (W-RWReq) from MME 110. After the S1-Conn 215 detects the W-RWReq, it proceeds to steps 410 and 420. At step 410, S1-Conn 215 copies the relevant data from the message and sends it to MANO 220. The W-RWReq data copied by S1-Conn 215 includes a message identifier and serial number, and may optionally include a tracking area ID, cell ID (if any), and a timestamp.

At step 415, MANO 220 may store some or all of this data in non-volatile memory. The purpose of doing this is that by logging the message identifier and serial number of the identified write-rewrite alarm request, the MSE 210 (specifically the MANO 220) will receive an alert message from the MME 110 via conflicting or duplicate data. The objective is to be able to generate alarm messages that are consistent with the above.

At step 420, S1-Conn 215 executes instructions to route the received W-RWReq to the appropriate BBU 114. If W-RWReq includes a cell ID or tracking area ID, S1-Conn 215 identifies the BBU 115 that corresponds to either the tracking area ID or the cell ID (this information was logged by MANO in step 340). MANO 220 and then routes the W-RWReq to the appropriate BBU 115 via the corresponding S1-mme interface 114. Optionally, S1-Conn 215 can simply broadcast the W-RWReq to all BBUs 115. Note that S1-Conn 215 performs steps 410 and 420 at the same time, or as much as possible simultaneously, to ensure transparency of S1-Conn 215 in the communication link between MME 110 and each BBU 115.

After each BBU 115 receives its corresponding write-rewrite alarm request, it generates a write-rewrite alarm response (W-RWResp) and returns it to the MME via the corresponding S1-mme interface 114.

In step 425, S1-Conn 215 detects each W-RWResp transmitted by each BBU 115 via its respective S1-mme interface 114. Next, in step 430 , S1-Conn 215 aggregates the S1-mme data stream including the W-RWResp from S1-mme interface 114 and sends it to MME 110 over aggregated S1-mme interface 112 . Optionally, S1-Conn 215 can copy and send the response data to MANO 220 for logging.

When an authorized entity involved in transmitting PWS messages via MME 110 chooses to do so, a shutdown alert request (SWReq) may be sent to BBUs 115. When that occurs, S1-Conn 215 monitoring S1-mme traffic from aggregated S1-mme interface 112 detects the presence of SWReq. In step 440 S1-Conn 215 routes the SWReq to the appropriate BBUs 115. In doing so, if SWReq includes a tracking area ID, S1-Conn copies the tracking area ID from the message and also queries MANO 220 for the cell ID that corresponds to the tracking area ID. With these cell IDs, S1-Conn 215 can selectively route SWReqs to the appropriate BBUs 115. Alternatively, S1-Conn 215 can simply broadcast the SWReq to all BBUs 115. Regardless of the approach adopted, S1-Conn 215 relays SWReq in real time to maintain transparency.

After each BBU 115 receives the shutdown alarm request, it may take appropriate actions and send a shutdown alarm request (SWReq) to the MME 110 via the corresponding S1-mme interface 114. In step 445, the S1-Conn 215 monitoring traffic from each S1-mme interface 114 detects the SWReq. S1-Conn 215 copies data from each detected SWReq and also sends the information to MANO 220 so that MANO 220 can log information indicating that the alert message has ended. This is optional.

In step 450 , S1-Conn 215 aggregates each S1-mme data stream including SWResp from S1-mme interface 114 and sends it to MME 110 over aggregated S1-mme interface 112 .

FIG. 4b shows a signal flow and timing diagram illustrating process 400.

5a and 5b illustrate a process 500 and signal flow and timing diagram for locally generating and providing location-specific alert messages to specific cells, respectively, in accordance with the present disclosure. Referring to FIG. 5a, steps 510-535 include the MSE 210 generating an alert message and transmitting it to one or more cells 235, and steps 540-550 include the steps of the MSE 210 generating an alert message and transmitting it to the BBUs 115 corresponding to the appropriate cell 235. Steps 555-570 include MSE 210 sending a stop message request to the appropriate cell 235, and steps 575-585 include receiving a response from the BBUs 115 corresponding to the appropriate cell 115. receiving an appropriate stop message response.

In steps 505 and 510, MANO 220 receives an alert message request from the authorized security guard via on-site IT infrastructure 130 and API 230 in application server 225 with location information or a location identifier (e.g., within a particular university building) corresponding to the alert message. all cell equipment, all cell equipment within a particular area of the stadium, etc.). Each of these locations may be identified by one or more cell IDs or as one or more "emergency zones" as described in more detail below. The authorized security guard may provide more than one alert message, each corresponding to a separate location identifier.

At step 515, if a cell ID is not provided by the security office, MANO 220 may execute instructions to correlate location information to a particular cell ID. In this case, MANO 220 may implement a look-up table or similar technique to derive the desired cell identifier from the identified location. It will be appreciated that there are many ways to implement this, each of which is within the scope of the present disclosure. Additionally, MANO 220 stores information regarding the readiness of cell 235 to receive alert messages to its appropriate memory (i.e., MANO 220 has logged PWN restart assertions from BBU 115 corresponding to cell 235). Can be inquired.

Therefore, when a field cellular network is deployed, the MANO 220 can act as a critical storage location for the mapping of cells to emergency zones, allowing the security office to simply identify which messages to direct to which emergency zones. The MANO 220 also maps the emergency zone to the actual cell. Furthermore, the security office may issue a single alert message to a cluster of emergency zones (a subset of the total number of emergency zones) and/or may have an individual distribution of messages to clusters of emergency zones. For example, some contiguous emergency zones within a core area may be designated to receive one set of messages, and remaining emergency zones may be designated to receive individual messages, with some of the individual messages Some may be shared with the core area and some may be different. Examples may be instructions to proceed to a particular exit, which may or may not be obvious in the emergency zone, instructions to continue or remain in place, and so on.

In steps 520 and 525, MANO 220 provides instructions to: combine the messages with their corresponding cell IDs and send them to each BBU 115 via the corresponding S1-mme interface 114, and also send an alarm message and the corresponding An instruction may be executed to send the cell identifier to S1-Conn 215 for transmission to the associated BBU 115. Regarding step 520, MANO 220 may further combine messages using message identifiers and serial numbers that are not apparent among those identified and stored in step 415 of process 400. In doing so, MSE 210 prevents collisions or confusion with existing messages sent by MME 110. This involves MANO 220 querying non-volatile memory for the message identifier and serial number of the previously identified W-RWReq identified in step 405 and stored in step 415, and if there is a match. deriving different message identifiers and/or serial numbers.

In step 530, S1-Conn 215 sends instructions to format the data for the write-rewrite alert request for insertion into the appropriate downlink S1-mme interface 114 for transmission to the appropriate cell 235 via the corresponding BBU 115. Execute.

Steps 505-530 may be performed once for a message cluster received by the field IT infrastructure 130, or the steps may be performed repeatedly, once for each received message. If the latter is true, in step 535 MANO 220 may query application server 225 to determine whether there are other alert messages and whether corresponding location information is waiting to be sent. can. If so, process 500 returns to step 505 and repeats from step 530 with the next message. Otherwise, process 500 continues to step 540.

Thus, at the end of step 535 (or step 530 if all alarm messages to be sent are processed in one pass), MSE 210 receives the requested alerts provided by the security office via on-site IT infrastructure 130. All messages are sent to the appropriate cell 235 via the corresponding BBUs 115 and S1-mme interface 114. At this point in process 500, MSE 210 is waiting for a response from each of BBUs 115.

In step 540, S1-Conn 215 executes instructions to monitor each S1-mme interface 114 for write-rewrite alarm responses (W-RWResp) via 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 forwarded to the MME 110. This is to prevent confusion within the EPC 105 due to receiving the W-RWResp without correlating it with any W-RWReq sent from the MME 110.

In step 545, S1-Conn 215 forwards to MANO 220 all or a portion of the W-RWResp asserting that the response was received from the cell ID indicated in the response. Additionally, in step 550, MANO 220 logs relevant information stating that the cell 235 corresponding to the cell ID in the W-RWReq is executing (or has executed) the instruction. Steps 540-550 repeat for each W-RWResp intercepted by S1-Conn 215 until received for each W-RWReq sent by MSE 210. At this point in process 500, MSE 210 waits for instructions from the security office via on-site IT infrastructure 130 to terminate the alarm message.

At step 555, MANO 220 receives instructions from the security office via on-site IT infrastructure 130 and API 230 to terminate the alarm message. In response, at step 560, MANO 220 generates a cell ID-enabled outage alert request (SWReq) corresponding to the cell ID or location asserted in the request from the security room. In doing so, if a request from the security room identifies an emergency zone, MANO 220 must correlate the location information or emergency zone to the specific cell ID, and this correlation must be included in the SWReq. Become.

At step 565, MANO 220 relays the generated SWReq data to S1-Conn 215 for transmission to the appropriate cell 215. Also in step 570, S2-Conn 215 inserts the message data into the appropriate S1-mme interface 114 for transmission to the designated cell 235 via the corresponding BBU 115. Steps 555-570 are repeated for each W-RWReq sent.

In step 575 , S1-Conn 210 executes instructions to monitor each S1-mme interface 114 to identify and block each Shutdown Alarm Request (SWResp) issued by each cell 250 via BBU 115 . After S1-Conn 210 identifies the SWResp, it terminates the signal and retrieves data to relay to MANO 220 in step 580. Additionally, with respect to step 580, MANO 220 updates logged PWS message information stating that the cell ID indicated in the retrieved SWResp has terminated the alert.

At step 585, MANO 220 sends a response to the security office via application server 25 and on-site IT infrastructure 130 that the alarm message is finished and that the message is completed in a cell 235.

Each iteration of steps 555-570 may be necessary to run through all of the messages sent before the process can proceed to steps 575-585. Thus, at any time, MSE 210 may execute instructions to perform any of step sequences 555-570 and 575-585 based on the timing of receiving the SWResp signal.

Claims (13)

a plurality of baseband devices, each correspondingly connected to one of the plurality of S1-mme interfaces;
an aggregate S1-mme interface configured to be connected to a mobility management entity;
an S1-mme aggregator and access component connected between the plurality of S1-mme interfaces and the aggregated S1-mme interface, each of which is a plurality of uplink S1-mme signals from each baseband device; aggregating signals as an aggregate S1-mme signal, transmitting the aggregate S1-mme signal on the aggregate S1-mme interface, terminating a downlink S1-mme signal from the aggregate S1-mme interface, and splitting a downlink S1-mme signal into a plurality of downlink S1-mme signals, routing each of the plurality of downlink S1-mme signals to one of the plurality of S1-mme interfaces ; -mme signals and the S1-mme aggregator and access component configured to access the downlink S1-mme signals;
a management and network operation component connected to the S1-mme aggregator and access component, the management and network operations component receiving an alarm command with location information from a field information technology (IT) infrastructure and generating a write-rewrite alarm request message; , the management and network operations component configured to send the write-rewrite alert request message to one or more of the plurality of baseband devices according to the location information provided by the on-site IT infrastructure;
A mobile edge computing system with A method for providing local warning messages in an LTE (Long Term Evolution) network,
a receiving step of receiving a cell restart assertion signal from one of a plurality of S1-mme interfaces, each of the plurality of S1-mme interfaces corresponding to a baseband device;
retrieving cell information from the cell restart assertion signal;
storing the cell information;
aggregating the plurality of S1-mme interfaces into an aggregate S1-mme interface, wherein the cell restart assertion signal is received from the S1-mme interface;
including methods. The method according to claim 2,
The method, wherein the cell information includes a cell ID. The method according to claim 2,
The method, wherein storing the cell information further comprises storing a timestamp corresponding to receipt of the cell reactivation assertion signal. The method according to claim 2,
The cell restart assertion signal includes a PWS (Public Warning System) restart assertion. A method for providing local warning messages in an LTE (Long Term Evolution) network,
receiving an alarm command from on-site information technology (IT) infrastructure;
retrieving location information from the alert instruction;
generating a write-rewrite alarm request corresponding to the alarm instruction;
inserting the write-rewrite alert request into a destination S1-mme data stream corresponding to a destination cell according to the location information provided by the on-site IT infrastructure, the destination cell being one of a plurality of cells; and the destination S1-mme data stream is one of a plurality of S1-mme data streams, each S1-mme data stream corresponding to at least one of the plurality of cells, the insertion step and
including methods. The method according to claim 6,
The step of generating the write-rewrite alarm request includes:
retrieving a location identifier from the alert instruction;
correlating the location identifier with a cell ID;
inserting the cell ID into the write-rewrite alert request;
including methods. The method according to claim 6,
The step of generating the write-rewrite alarm request includes:
querying a memory storing the previously identified write-rewrite alarm request data for an existing message identifier and an existing serial number;
generating a new message identifier and a new matching serial number that are not equal to the existing message identifier and the existing serial number;
including methods. The method according to claim 6, further comprising:
identifying a write-rewrite alarm response within a designated uplink S1-mme data stream, wherein the designated uplink S1-mme data stream corresponds to a destination cell, and the write-rewrite alarm response corresponds to the write-rewrite alarm response; the identifying step corresponds to a rewrite alarm request;
terminating the write-rewrite alarm response;
storing information corresponding to the write-rewrite alarm response;
including methods. The method according to claim 9,
The steps to terminate are:
removing the write-rewrite alarm response from the designated uplink S1-mme data stream;
aggregating a plurality of uplink S1-mme data streams with the designated uplink S1-mme data stream into an aggregate S1-mme data stream;
including methods. The method according to claim 9, further comprising:
receiving an outage alarm command from the on-site IT infrastructure;
generating a shutdown alarm request corresponding to the shutdown alarm instruction;
inserting the outage alarm request into a destination S1-mme data stream;
including methods. The method according to claim 11, further comprising:
identifying an outage alarm response within the specified uplink S1-mme data stream;
terminating the stop alarm response;
storing information corresponding to the stop alarm response;
including methods. The method according to claim 12, further comprising:
A method comprising sending an acknowledgment signal to the on-site IT infrastructure acknowledging receipt of the alert response.

Images