Patent Application
20160249388
The invention generally relates to communication technologies, in particular to a method and a device for emergency handling in communication network.
The 3rd Generation Partner Project (3GPP) had some discussion on emergency call, for example, IMS and SRVCC. Emergency is discussed in some 3gpp standards including, for example, TS 23.167 (“IP Multimedia Subsystem (IMS) emergency sessions”); TS 23.509 (“TISPAN; NGN Architecture to support emergency communication from citizen to authority”); TR 23.870 (“Single Radio Voice Call Continuity (SR-VCC) support for IMS Emergency Calls”), etc.
Conventionally, the emergency handling mentioned above mainly focuses on a UE level. Generally, UE-level emergency handling provides communication service to individual in emergency. While under emergency situation, the network traffic model is changing dramatically, as well as the urgency requirement on basic voice service, so how to optimize network resource to ensure basic voice service and avoid network overload become very important.
Thus, an optimized solution is desired to handle above problem from the whole communication network point of view.
To the end, this disclosure introduces and develops an emergency network mode, and provides a method and a device for network-level emergency handling in the emergency situation. This will significantly enhance the handling efficiency in an emergency case. The enhanced method and device provided herein may preferably mitigate, alleviate or eliminate one or more of the above mentioned disadvantages singly or in any combination.
In one aspect of embodiments of the invention, there is provided an emergency handling method, comprising: receiving, by an emergency support function (ESF) entity, an emergency indicator indicating an emergency event from a network application server; handling the emergency indictor to derive related parameters including impacted network elements in a network; and triggering the impacted network elements to switch into a network emergency mode by sending an emergency command based on the related parameters.
In another aspect of embodiments of the invention, there is provided an emergency handling apparatus in a network, comprising: a receiving module for receiving an emergency indicator indicating an emergency event from a network server; a handling module for handling the emergency indictor to derive related parameters including impacted network elements in a network; and a distributing module for triggering the impacted network elements to switch into a network emergency mode by sending an emergency command based on the related parameters.
In yet another aspect of embodiments of the invention, there is provided a device comprising an emergency support function, ESF, entity performing any method of the embodiments of the present invention.
According to the embodiments of the invention, the whole network may take real time action and communication network behavior is adjusted when public emergency events happened. The action may be predefined and thus may increase the access and basic service capacity, which is very vital to the users and to Operator in an emergency.
According to the embodiments, an emergency network mode may be triggered by a 3rd Party or an Operation Support System (OSS). All or partial NEs within a network may adjust parameter, including UE QoS policy simultaneously without individual UE level signaling interactions. This may save lots of time and signaling exchange in emergency case. Further, all or partial standard message procedure may be simplified, for example, all or partial Call Data Record (CDR) may be deactivated to save network resource and thus provide larger capability. These improve efficiency of emergency handling in a network.
The features and advantages of the present invention will be more apparent from the following exemplary embodiments illustrated with reference to the accompanied drawings, in which:
The embodiments will be described thoroughly hereinafter with reference to the accompanied drawings. It will be apparent to those skilled in the art that the disclosure may, however, be implemented in many different forms and should not be construed as being limited to the specific details set forth in the given embodiments. Like numbers refer to like elements throughout the description.
In this disclosure, although specific terminologies have been used to exemplify the embodiments, this should not be seen as limiting the scope of the embodiments to only the aforementioned communication system. With the rapid development in communications, there will of course also be future type of technologies and systems with which the present invention may be adapted.
The disclosure may be described in detail from the following aspects hereinafter: the network emergency mode triggered by an OSS or an authorized 3rd party, and the network behavior in the network emergency mode.
In
In the context, the network emergency mode may refer to a special communication mode supported by all or partial NEs in the network for dealing with emergency.
The OSS device or the authorized 3rd party device may be implemented as any computing device, such as a network application server, a mainframe, etc. In the context, the NEs may generally refer to various network node devices in different networks, not limited to the listed above. Generally, NEs do not include end user devices (e.g., mobiles).
Particularly, when received an emergency indicator from the Operation Support System (OSS) device or the pre-defined authorized 3rd party device, the NEs in the network within the emergency area will be initiated by the Emergency Support Function (ESF) entity to switch into the emergency network mode, adjusting all parameters/policies for each UE groups within the emergency area to cope with the emergency. For example, the network may be adjusted immediately when an earthquake administrator server sends out the level of emergency, for the users located in the zone. In the context, the term “UE” generally refers to the wireless user equipment, including mobile phones and machine type communication device, etc.
The ESF entity may handle the emergency indicator (including emergency location, command type, emergency type, emergency level, special user list) sent from the OSS or the authorized 3rd party device to derive all impacted network elements in the network and trigger these NEs to switch into the network emergency mode. Further, the ESF entity may also maintain all pre-defined emergency policy/parameters for all NEs, which will be sent to all NEs when the emergency indicator is received. Optionally, each NE may have local pre-defined emergency policy/parameter.
The ESF entity may be implemented as hardware or software which may be deployed in different modes. For example, the ESF entity may be implemented as a single node, or a set of program codes resided in the node. Alternatively, the ESF entity may be co-existed within all NEs (e.g., MME, GW, etc.). The ESF entity may also be separated into a client end and a server end, which may separately be deployed in different nodes. The ESF entity may include several instances in each mode for the purpose of High Availability (HA). For example, one ESF entity may be deployed with a backup. The switching between the active and backup need inform the OSS or 3rd party. Virtual Router Redundancy Protocol (VRRP) is also another option.
In the embodiment, the emergency handling apparatus 20 incorporated an Emergency Support Function (ESF) entity therein may include a receiving module 21, a handling module 22, and a distributing module 23.
The receiving module 21 may be configured to interface with the OSS device or the authorized 3rd party device and receive an emergency indicator from a network server. The emergency indicator may be used to indicate an emergency occurs, which may include following information as shown in Table 1, such as, geographic location representing where emergency occurs, e.g., via latitude/longitude or administrative area; non-affected Access Point Name (APN); non-affected MSISDN/IMSI series; emergency type describing emergency caused by e.g. flood or earthquake; command type (e.g., Create, Delete, Modify) indicating respectively e.g. emergency occurring, emergency eliminated, emergency level changed; emergency level describing the severity level, e.g., level 1 refers to the highest level emergency; actions representing specific adjustment measures taken, e.g., decreasing QoS level, disabling Gx interface, etc.
The ESF entity may derive the impacted NE list, Cell ID, Tracking Area (TA), Location Area (LA), Routing Area (RA), etc. from the mapping tables based on the location information. The message sent from the ESF entity to each NE may contains the information e.g. Cell ID/TA/LA/RA.
The handling module 22 may be configured to handle the emergency indictor to derive, e.g., the impacted network elements in a network, emergency level, and other related parameters. Alternatively or additionally, the handling module 22 may further be configured to derive the impacted network elements based on geographic location information contained in the emergency indicator; and define different emergency configuration parameters for different network elements. The distributing module 23 may be configured to trigger the impacted network elements to switch into a network emergency mode by sending an emergency command to each of the impacted NEs based on the related parameters, such as the emergency level.
The emergency handling apparatus 20 may further include a configuration module which may configure all network element addresses in the apparatus 20. The address of the apparatus 20 may also be configured in all network elements in the network.
In this method, when an emergency support function (ESF) entity receives, in step 31, an emergency indicator indicating an emergency event, e.g., earthquake, from an OSS device or an authorized 3rd party device, in step 32, the emergency support function (ESF) entity handles the emergency indictor to derive the impacted network elements in a network within the emergency area and related parameters. The definition of the emergency indicator is described in the table 1 as above. Then, in step 33, the emergency support function (ESF) entity triggers the impacted network elements to switch into the network emergency mode by sending an emergency command to each of the impacted network elements based on the related parameters.
The network emergency mode may be triggered by one/more entities, including OSS, 3rd party or their combination via the ESF entity deployed in the network. Security of authentication of 3rd party is necessary, for example, via source IP check, etc.
It is to be noted that all the following signaling messages may be transmitted over Transfer Control Protocol (TCP), User Datagram Protocol (UDP), Diameter, Stream Control Transmission Protocol (SCTP), or GPRS Tunneling Protocol (GTP) etc.
In the embodiment, in Step 40, the ESF entity need know the address of each NE. Alternatively or additionally, all NE addresses may be pre-configured in the ESF entity, and/or the address of the ESF entity may also be pre-configured in each NE.
In Step 41, a 3rd party application server may send an “emergency indicator” to the ESF entity when some public emergency situation happens (preparing for the emergency is also allowed).
In the “emergency indicator”, it may contain the information of command type “create/modify/cancel”, location, emergency type, emergency level, special user list (MSISDN/IMSI list) or the combination of them.
In Step 42, the ESF entity may handle the “emergency indicator”. For example, for the command type “Create”, it may be described as including at least the following acts:
a) Location handling: the ESF entity may derive the affected NEs based on the location information contained in “emergency indicator”;
b) Type/level mapping: the ESF entity may define different levels, actions, or other parameter for different affected NEs.
In Step 43, the ESF entity may send an “emergency command” to each affected NE. The emergency command may include information such as mapped emergency type, emergency level, and optional NE parameter adjustment, etc.
In step 44, alternatively or additionally, the affected NE under emergency mode may inform a surrounding NE, so the surround NE may handle the relevant UEs (e.g., roaming users) accordingly, for example, the surrounding network element (e.g., eNB) may increase radio coverage. In another example, home GW may handle the target UEs in affected NE.
In Step 45, each affected NE enforces the emergency command.
In one example, QoS adjustment may be performed, e.g., all Maximum Bit Rate (MBR) or Guaranteed Bit Rate (GBR) may be adjusted to half when emergency level=2; or adjusted to 2/3 when emergency level=3. All bears which have MBR may be decreased to 2/3 of legacy amount. Alternatively or additionally, Call Data Record (CDR) may be disabled for some users. According to the embodiment, adjusting MBRs of a majority of UEs need NOT extra messages, this will save lots of signaling in this scenario.
In another example, some other feature, e.g. UE signaling function may be activated automatically. This may also advantageously save lots of signaling. Particularly, functions related to UE signaling reduction may be activated automatically even if, in the network, the related license or switch control are not granted. One example of how UE signaling reduction works is that, for the mis-behaved UE, or UE not following 3GPP standardized behavior, the network has the option to ignore any incoming request messages from the UE.
Another example is location service. This license feature can be open, so network can launch this function for some UE even Operator of the network does not buy the license.
Alternatively or additionally, MME may use piggyback method, which means inserting emergency information, including adjusted UE related parameter, for example QoS, to inform UE the change of QoS in any legacy Non-Access Stratum (NAS) signaling.
The behavior in the network emergency mode may be described in detail hereinafter.
In the emergency situation, the traffic model is changing dramatically, e.g. earthquake, it requires UEs connecting each other in shorter time, and less interaction among the telecom nodes. Thus, the network (i.e., NEs) needs to go into emergency mode to meet the following countermeasures: A. increase network capacity; B. decrease network load; and C. fair usage of the network resource.
The ESF entity may initiate the network element, e.g. eNB, to activate a pre-defined emergency configuration set to increase the capacity or coverage, such as increasing emission of radio.
The basic role is to ensure accessibility or capacity base on emergency requirement. The configuration set includes, but not limited to Admission Control, Load Control, Congestion Control, Channel Configuration, etc.
E.g. some of the eNBs break in emergency. To increase radio coverage using remain eNBs, a pre-defined Physical Random Access Channel (PRACH) preamble Format 0˜3 may be reset to, or the power emission may be increased temporarily to provide different cell radius, for example, from 15 km to 100 km in such emergency situation.
Alternatively or additionally, non-emergency area cells which are adjacent to the emergency area may absorb UEs in the emergency area, to increase capacity. For UEs in IDLE mode, in the emergency configuration set, the SIB (System information Blocks) contents may be changed, to set proper values for cell selection and reselection related parameters, so that UEs may easily camp on non-emergency cells in those overlapping area. For the UEs in connect mode, neighbour cell configuration can be a part of the emergency configuration set. For example, by deleting neighbor cells which are inside the emergency area, the connected UEs may not perform handover into the emergency area.
For example, in emergency, access license limitation may be eliminated temporarily according to the emergency level; in other words, the node capability license may be disabled according to e.g. the emergency level.
For example, according to indication from the ESF entity, the emergency area will be analyzed as RAs/LAs/TAs, for UEs in these areas, the network will automatically open location feature for them. Regardless of emergency level, location feature will be opened. The location of UEs in the emergency area may be captured and uploaded to some location server for latter usage.
For example, generally, default bearers of the IMS PDN connection provide IMS signaling. This is very important in emergency situation, and we need to keep those default bearers unchanged. Paging in the network may consume much radio resource. It may reserve the network resource significantly if paging for other low priority dedicated bears are disabled, i.e., if UE is in idle state, downlink traffic of partial/all low priority dedicated bearers will not trigger paging.
In the emergency area, services which have high authorized QoS may be adjusted to a certain low QoS level, depending on emergency level, to increase network capacity for new access requests. New access requests may be authorized a certain QoS level, depending on emergency level. The aim is to retain user basic service requirements (e.g., IP Multimedia Subsystem (IMS) service) and not occupy extra network resource.
In order not to introduce additional signaling for QoS modification, the QoS adjustment level in emergency may be pre-defined in all the relevant network elements (i.e., PCRF, Policy and Charging Enforcement Function (PCEF), PGW/SGW, SGSN-MME, eNB, etc). Once the network emergency mode is triggered, the emergency level is distributed among all the network elements, the QoS adjustment may be done immediately.
Alternatively or additionally, as shown in
It is to be noted that the QoS adjustment depends on emergency levels. For example, the QoS of PDN connection on the IMS APN shall be guaranteed. Generally the QoS of voice bearer shall be kept unchanged during the emergency period. In the most serious emergency situation, the QoS of voice bearer may be downgraded to the lowest level but the bearer shall be able to afford very basic IMS voice service.
Various procedures in communication systems are complex. It is reasonable regarding availability, integrity, confidentiality in normal cases, even though it takes time. However, when emergency event happens, e.g. earthquake, it requires UEs connecting each other in shorter time, and less interaction among the telecom nodes. The usable resource shall be utilized maximally.
Therefore, procedure simplification may be applied in emergency to assure the minimum requirement of communication, e.g. phone conversation.
In one embodiment, as shown in
Alternatively or additionally, for a new UE executing the attach procedure, ciphering level may be set to 0 (i.e., no ciphering). The attached UE may keep the current status.
Alternatively or additionally, International Mobile Equipment Identity number (IMEI) check procedure may be disabled, as shown in
Alternatively or additionally, as shown in
As shown in
Alternatively or additionally, according to emergency level, different duration of connection may be allowed for users. For example, for the lowest emergency level, it may allow 30-min connection for one user; while for the highest emergency level, it may allow 3-min connection at most for one user. Specifically, as shown in
Alternatively or additionally, according to emergency level, different times of re-attach in a period after attach failure may be allowed. For example, for the lowest emergency level, 10 seconds of back off timer may be set for one user, which means retry times are 6 times per minute; while for the highest emergency level, back off timer may be set to 5 minutes (300 seconds), which means retry times are 12 times per hour. For example, as shown in
For privileged users, fair usage function may not work for them. IMSI of these privileged users may be notified in advance from the ESF entity to NEs, such as, SGSN, MME, eNB, GW, PCRF.
It will be appreciated that the above description for clarity has described the embodiments with reference to different functional units/modules, processors, and servers. However, it will be apparent that any suitable distribution of functionality between different functional units/modules, processors or servers may be used without detracting from the invention. For example, functionality illustrated to be performed by separate modules, processors or servers may be performed by the same module, processor or server. Hence, references to specific functional units/modules or servers are only to be seen as references to suitable means for providing the described functionality rather than indicative of a strict logical or physical structure or organization.
Although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also the inclusion of a feature in one category of claims does not imply a limitation to this category but rather indicates that the feature is equally applicable to other claim categories as appropriate. Furthermore, the order of features in the claims do not imply any specific order in which the features must be worked and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. Reference signs in the claims are provided merely as a clarifying example shall not be construed as limiting the scope of the claims in any way.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit to the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless otherwise stated. It will be further understood that the terms “including”, “comprising” and conjugation thereof when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
Although the invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the spirit and scope of the invention as defined by the appended claims. The exemplary embodiments should be considered in descriptive sense only and not for purposes of limitation. Therefore, the scope of the invention is defined not by the detailed description of the invention but by the appended claims.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CN2013/084562 | 9/29/2013 | WO | 00 |
