Abstract:
A method for handling an emergency session for a network in a wireless communication system is disclosed. The method comprises having an emergency context for a mobile device corresponding to the emergency session; not deactivating the emergency context for the mobile device when the network does not allocate radio resources to the emergency context; and preserving the emergency context.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. Provisional Application No. 61/370,813, filed on Aug. 5, 2010 and entitled “Method to handle emergency session in abnormal scenarios”, the contents of which are incorporated herein. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The present invention relates to a method of handling emergency sessions in a wireless communication system and a communication device thereof, and more particularly, to a method of handling emergency sessions in abnormal scenarios and a related communication device. 
         [0004]    2. Description of the Prior Art 
         [0005]    In a wireless communication system such as Universal Mobile Telecommunications System (UMTS) or long-term evolution (LTE) system, an emergency session is often provided by a network to a mobile device that is in a limited service state. Receiving emergency services in the limited service state does not require a subscription, yet the mobile device must first establish a session with the network to access emergency services provided by the system. 
         [0006]    UMTS provides both circuit switching (CS) and packet switching (PS) services, while the LTE system has been designed to support only packet switched (PS) services. In UMTS, the network is referred to as a universal terrestrial radio access network (UTRAN), comprising a plurality of base stations (Node-Bs) and Radio Network Controllers (RNCs), whereas the mobile devices are referred to as user equipments (UEs). In LTE, an evolved universal terrestrial radio access network (E-UTRAN) includes a plurality of evolved Node-Bs (eNodeBs) and communicates with a plurality of mobile stations, also referred to as user equipments (UEs). 
         [0007]    In UMTS, before accessing a service in an external network (e.g. the Internet), the UE needs to perform a packet data protocol (PDP) context activation procedure to activate a PDP context (containing routing information for tunneling packets) to a belonging serving general packet radio service (GPRS) support node (SGSN) and a specific gateway GPRS support node (GGSN), which can support the service. 
         [0008]    In LTE, seamless Internet Protocol (IP) connectivity is provided between a UE and a packet data network (PDN) via an evolved packet system (EPS) bearer for accessing the Internet. The EPS bearer is established via an EPS bearer context activation procedure. Note that, in the LTE/LTE-Advance system, the GGSN may be referred to a packet data network gateway (P-GW), the SGSN to a serving gateway (S-GW). 
         [0009]    The 3GPP Technical Specification TS 24.301 Release 9 specifies that a UE and a Mobility Management Entity (MME) in the network would locally deactivate an EPS or PDP context when corresponding user plane radio bearers are not established during a service request procedure. This means that when establishing an Emergency EPS or PDP context to make an emergency call, if radio resources are not available in the network (e.g. E-UTRAN doesn&#39;t have enough resource) and the E-UTRAN doesn&#39;t allocate user plane radio bearers for the emergency context, then the UE and the network will deactivate the EPS context for the emergency bearer services. Thus, when the user dials an emergency call again, the UE needs to initiate the context activation procedure and the service request procedure again to establish the emergency session. This redundant deactivation and activation of the emergency context takes extra time, which is critical in emergencies. In the worst case, if the UE has only an EPS context for emergency bearer services and the network is unable to allocate the resource to it, the UE would locally deactivate the emergency EPS context and perform the attach procedure again. This results in unnecessary additional signaling and hence delays in the establishment of the emergency session. 
         [0010]    Additionally, according to the prior art, the emergency session may also be interrupted by a collision between a service request procedure for the emergency session and a network-initiated detach procedure during abnormal scenarios. The 3GPP Technical Specification TS 24.008 Release 9 specifies that when the UE has initiated the service request procedure for the emergency service session (i.e. in a GMM-SERVICE-REQUEST-INITIATED state, or an EMM-SERVICE-REQUEST-INITIATED state), a UE will abort the service request procedure and proceed with the detach procedure after receiving a detach request message from the network. For example, after receiving a detach request message with a detach type “IMSI detach” to detach the UE from CS services, the UE needs to perform a combined tracking area update procedure to attach for CS services again. This procedure will abort the emergency call activation procedure, hence a user will not be able to initiate another emergency service before the detach procedure and a subsequent attachment procedure finishes. Alternatively, if a UE receives a detach request message with a detach type “re-attach not requited” to detach the UE from PS services, then the UE will abort the service request procedure and proceed with the detach procedure. Similarly, the network will abort the service request procedure and proceed with the detach procedure. In this case, the emergency session can only be established after the detach procedure and a subsequent emergency attach procedure is finished. Thus, the emergency call will be delayed. In some time-critical cases this delay will be significant. 
         [0011]    Finally, the network can send a detach request message with a detach type “Re-attach not required” and a GPRS mobility management (GMM) cause “IMSI unknown in HLR” to detach the UE from CS services. In a case the UE is attempting a Routing Area Update (RAU) procedure to update a location of the UE in the network, while the network initiates a detach procedure, the UE and the network will abort the RAU_procedure and the network initiated detach procedure will proceed. In this case, the next RAU_procedure will be started when a periodic RAU timer expires or the UE changes a Routing Area. During this period the UE will miss paging from the network and hence an emergency call-back will fail. 
         [0012]    As can be seen from the above, various abnormal scenarios in the prior art could cause unnecessary and redundant signaling delays in the establishment of emergency sessions. Therefore, improvement over the prior art is necessary. 
       SUMMARY OF THE INVENTION 
       [0013]    A method of handling emergency sessions for a wireless communication system and related communication device are provided. 
         [0014]    A method of handling an emergency session for a network in a wireless communication system is disclosed. The method comprises having an emergency context for a mobile device corresponding to the emergency session; not deactivating the emergency context for the mobile device when the network does not allocate radio resources to the emergency context; and preserving the emergency context. 
         [0015]    A method of handling an emergency session for a mobile device in a wireless communication system is disclosed. The method comprises having an emergency context from a network corresponding to the emergency session; and not deactivating the emergency context when the network does not allocate radio resources to the emergency context. 
         [0016]    A method of handling an emergency session for a mobile device in a wireless communication system is disclosed. The method comprises initiating a service request procedure corresponding to the emergency session in a network; receiving a detach request message from the network when initiating the service request procedure or after having initiated the service request procedure; and not aborting the service request procedure when the detach request message is received. 
         [0017]    A method of handling an emergency session for a network in a wireless communication system is disclosed. The method comprises receiving a service request message from a mobile device when the network is initiating a detach procedure; and neither aborting nor ignoring the service request message and proceeding with a service request procedure corresponding to the service request message. 
         [0018]    A method of handling an emergency session for a mobile device in a wireless communication system is disclosed. The method comprises receiving a detach request message from a network when a Routing Area Update procedure is ongoing; not aborting the RAU_procedure when the detach request message is received; and concurrently proceeding with the RAU_procedure and a detach procedure corresponding to the detach request message. 
         [0019]    A method of handling an emergency session for a network in a wireless communication system is disclosed. The method comprises receiving a Routing Area Update request message corresponding to an RAU_procedure from a mobile device when the network is sending a detach request message to the mobile device; and processing the RAU request message and responding the mobile device with an RAU accept message or an RAU reject message when the RAU request message is received. 
         [0020]    A method of handling an emergency session for a mobile device in a wireless communication system is disclosed. The method comprises receiving a detach request message from a network when a Routing Area Update procedure is ongoing; aborting the RAU_procedure and proceeding with a detach procedure corresponding to the detach request message when the detach request message is received; and restarting the RAU procedure immediately upon completion of the detach procedure. 
         [0021]    These and other objectives of the present invention will no doubt become obvious to those of ordinary skill in the art after reading the following detailed description of the preferred embodiment that is illustrated in the various figures and drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0022]      FIG. 1  is a schematic diagram of a wireless communication system. 
           [0023]      FIG. 2  is a schematic diagram of an exemplary communication device according to an embodiment. 
           [0024]      FIG. 3  is a flowchart of an exemplary process according to an embodiment. 
           [0025]      FIG. 4  is a flowchart of an exemplary process according to an embodiment. 
           [0026]      FIG. 5  is a flowchart of an exemplary process according to an embodiment. 
           [0027]      FIG. 6  is a flowchart of an exemplary process according to an embodiment. 
           [0028]      FIG. 7  is a flowchart of an exemplary process according to an embodiment. 
           [0029]      FIG. 8  is a flowchart of an exemplary process according to an embodiment. 
           [0030]      FIG. 9  is a flowchart of an exemplary process according to an embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0031]    Please refer to  FIG. 1 , which illustrates a schematic diagram of a wireless communication system  10 . Briefly, the wireless communication system  10  is composed of a network and a plurality of mobile devices. In  FIG. 1 , the network and the mobile devices are simply utilized for illustrating the structure of the wireless communication system  10 . The wireless communication system  10  can be a Global System for Mobile communications (GSM), universal mobile telecommunications system (UMTS), long-term evolution (LTE) system or LTE-Advanced system. For example, if the wireless communication system  10  is an LTE system, the network can be referred to as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) comprising a plurality of base stations (eNodeBs), whereas the mobile devices are referred to as user equipments (UEs). The UEs can be devices such as mobile phones, computer systems, etc. Furthermore, the network and the UE can be seen as a transmitter or a receiver according to a transmission direction, e.g., for uplink (UL), the UE is the transmitter and the network is the receiver, and for downlink (DL), the network is the transmitter and the UE is the receiver. 
         [0032]      FIG. 2  illustrates a schematic diagram of an exemplary communication device  20 . The communication device  20  may be the mobile device shown in  FIG. 1 , but is not limited herein. The communication device  20  may include a processing means  200  such as a microprocessor or Application Specific Integrated Circuit (ASIC), a storage unit  210  and a communication interfacing unit  220 . The storage unit  210  may be any data storage device that can store program code  214 , for access by the processing means  200 . Examples of the storage unit  210  include but are not limited to a subscriber identity module (SIM), read-only memory (ROM), flash memory, random-access memory (RAM), CD-ROMs, magnetic tape, hard disk, and optical data storage device. The communication interfacing unit  220  is preferably a radio transceiver and can exchange wireless signals with the network according to processing results of the processing means  200 . 
         [0033]    Please refer to  FIG. 3 , which is a flowchart of an exemplary process  30 . The process  30  is utilized for a network NT 1  (such as the network of  FIG. 1 ) for handling an emergency session in the wireless communication system  10 , including the network NT 1  and a UE UE 1 . The process  30  can be compiled into the program code  214  and includes the following steps: 
         [0034]    Step  300 : Start. 
         [0035]    Step  310 : Have an emergency context EC 1  for the UE UE 1  corresponding to the emergency session. 
         [0036]    Step  320 : Not deactivate the emergency context EC 1  for the UE UE 1  when the network NT 1  does not allocate radio resources to the emergency context EC 1 . 
         [0037]    Step  330 : Preserve the emergency context EC 1 . 
         [0038]    Step  340 : End. 
         [0039]    According to the process  30 , the network NT 1  has an emergency context EC 1  for the UE UE 1 . The emergency context EC 1  may be an emergency EPS bearer context for LTE, or an emergency PDP context for UMTS. The network NT 1  may be E-UTRAN for LTE. When radio resource is not available and the network does not assign the radio bearer to the emergency context EC 1 , the network NT 1  does not deactivate the emergency context EC 1  for emergency bearer services and preserves the emergency context EC 1 . Preferably, the emergency context EC 1  is an emergency Evolved Packet System (EPS) context. In this situation, the UE UE 1  does not need to initiate an EPS context procedure again when the UE UE 1  has to make an outgoing emergency call. Therefore, redundant deactivation and activation steps could be skipped. Further, unnecessary additional signaling and delays in establishment of the emergency session are avoided. 
         [0040]    Accordingly, the UE UE 1  in the wireless communication system may take corresponding actions. Please refer to  FIG. 4 , which is a flowchart of an exemplary process  40 . The process  40  is utilized in the UE UE 1  in the wireless communication system  10  for handling the emergency session. The process  40  can be compiled into the program code  214  and includes the following steps: 
         [0041]    Step  400 : Start. 
         [0042]    Step  410 : Have the emergency context EC 1  from the network NT 1  corresponding to the emergency session. 
         [0043]    Step  420 : Not deactivate the emergency context EC 1  when the network does not allocate radio resources to the emergency context EC 1 . 
         [0044]    Step  430 : End. 
         [0045]    According to the process  40 , if the network NT 1  has the emergency context EC 1  for the UE UE 1  but does not assign radio resources to the emergency context EC 1 , the UE UE 1  is forbidden to deactivate the emergency context EC 1  locally. Therefore, the UE UE 1  does not need to initiate an EPS context procedure again when the UE UE 1  makes an emergency call. Therefore, the redundant deactivation and activation steps could be skipped. Further, unnecessary additional signaling and delays in establishment of the emergency session are avoided. 
         [0046]    Briefly, according to the processes  30  and  40 , the network NT 1  and the UE UE 1  preserve the emergency context EC 1  (e.g. an emergency EPS bearer context) when the network NT 1  does not assign user plane radio resources to the UE UE 1 , such that unnecessary additional signaling and delays in establishment of the emergency session are avoided. 
         [0047]    Please refer to  FIG. 5 , which is a flowchart of an exemplary process  50 . The process  50  is utilized for a UE UE 2  which is attached for both PS and CS services in a network NT 2 , for handling an emergency session in a wireless communication system including the network NT 2  and the UE UE 2 . The process  50  can be compiled into the program code  214  and includes the following steps: 
         [0048]    Step  500 : Start. 
         [0049]    Step  510 : Initiate a service request procedure SRQ_p corresponding to the emergency session in the network NT 2 . 
         [0050]    Step  520 : Receive a detach request message DRQ_m from the network NT 2  when initiating the service request procedure SRQ_p or after having initiated the service request procedure SRQ_p. 
         [0051]    Step  530 : Not abort the service request procedure SRQ_p when the detach request message DRQ_m is received. 
         [0052]    Step  540 : End. 
         [0053]    According to the process  50 , the UE UE 2  is attached for both PS and CS services in the network NT 2 . The network NT 2  may be E-UTRAN for LTE or U-TRAN for UMTS. The service request procedure SRQ_p is for PS services in the network NT 2  corresponding to the emergency session, e.g. for establishing an emergency EPS context, an emergency PDP context, or user plane radio bearers in the network NT 2 . The UE UE 2  receives the detach request message DRQ_m from the network NT 2  when initiating the service request procedure SRQ_p or after having initiated the service request procedure SRQ_p, i.e. the UE UE 2  is in a mobility management (MM) state of GMM-SERVICE-REQUEST-INITIATED (for UMTS) or EMM-SERVICE-REQUEST-INITIATED (for LTE). In this situation, the service (e.g. emergency bearer service) can keep going without being aborted. Redundant delay may be avoided. 
         [0054]    In one case, the detach request message DRQ_m may correspond to a detach procedure DRQ 1 _p to detach the UE UE 2  from CS services in the network NT 2 . When the UE UE 2  receives the detach request message DRQ_m from the network NT 2  while initiating or having initiated the service request procedure SRQ_p for PS services, the UE UE 2  is forbidden to abort the service request procedure SRQ_p for PS domain. The UE UE 2  continues with the service request procedure SRQ_p. For example, the UE UE 2  may be IMSI attached for both PS and CS services to a network in Network Operation Mode I (NMO I) and receives the detach request message DRQ_m with a detach type “IMSI detach” or with a detach type “Re-attach not required” with a GMM cause “IMSI unknown in HLR” while the UE UE 2  is initiating the PS service request procedure SRQ_p to establish the PDP context or establish the user plane bearers, then the UE UE 2  does not abort the PS service procedure SRQ_p and proceeds with the PS services request procedure SRQ_p. Therefore, the network NT 2  will not ignore the service request for the PS services from the UE UE 2 , and unnecessary additional signaling and delays in establishment of the emergency session is avoided. 
         [0055]    In another case, the detach request message DRQ_m may correspond to a detach procedure DRQ 2 _p to detach the UE UE 2  from PS services in the network NT 2 . If the detach request message DRQ_m received has a detach type “Re-attach not required” to detach the UE UE 2  from the PS services while the UE UE 2  is initiating the service request procedure SRQ_p or has initiated a service request procedure SRQ_p, the UE UE 2  is forbidden to abort the service request procedure SRQ_p and continues the service request procedure SRQ_p. The service request procedure SRQ_p may be for establishing a PDP context for emergency bearer services. The UE UE 2  deactivates all non-emergency PDP contexts if any. The UE UE 2  sends a detach accept message to the network and considers itself attached for emergency bearer services only. The UE UE 2  initiates a PDP or EPS context activation procedure for emergency PDP or EPS context. 
         [0056]    Accordingly, the network NT 2  in the wireless communication system may take corresponding actions. Please refer to  FIG. 6 , which is a flowchart of an exemplary process  60 . The process  60  is utilized for the network NT 2 , for handling an emergency session in the wireless communication system including the network NT 2  and the UE UE 2 . The process  60  can be compiled into the program code  214  and includes the following steps: 
         [0057]    Step  600 : Start. 
         [0058]    Step  610 : Receive a service request message SRQ_m from the UE 2  when the network NT 2  is initiating a detach procedure DRQ_p. 
         [0059]    Step  620 : Neither abort nor ignore the service request message SRQ_m and proceed with a service request procedure SRQ_p corresponding to the service request message SRQ_m. 
         [0060]    Step  630 : End. 
         [0061]    According to the process  60 , the service request message SRQ_m corresponds to the service request procedure SRQ_p, for PS services in the network NT 2  corresponding to the emergency session, e.g. for establishing an emergency EPS/PDP context, or user plane radio bearers. The detach procedure DRQ_p may be the detach procedure DRQ 1 _p or the detach procedure DRQ 1 _p, to detach the UE UE 2  from CS and PS services, respectively. The network NT 2  is forbidden to ignore or abort the service request message SRQ_m for PS services and proceeds with the corresponding service request procedure SRQ_p. 
         [0062]    For example, if the network NT 2  is operating in a network mode of operation I (NMO I) and receives PS service request message SRQ_m from the UE UE 2  attached for both PS and CS services, while it has sent the detach request message DRQ_m with a detach type “IMSI detach” or “Re-attach not required” with a GMM cause “IMSI unknown in HLR”, the network NT 2  shall not ignore the PS Service Request message SRQ_m from the UE UE 2  and proceeds with the PS Service Request procedure SRQ_p, i.e. the network NT 2  may establish the PDP context or assign resources for user plane bearer services. Therefore, delays caused by the detach procedure DRQ_p and subsequent redundant re-attach steps could be skipped, and unnecessary delays in establishment of the emergency session are avoided. 
         [0063]    Briefly, according to the processes  50  and  60 , the network NT 2  does not abort or ignore the service request message SRQ_m from the UE UE 2  when initiating the detach procedure DRQ_p, such that establishment of the emergency session is not delayed by the detach procedure DRQ_p. 
         [0064]    Please refer to  FIG. 7 , which is a flowchart of an exemplary process  70 . The process  70  is utilized for a UE UE 3  for handling an emergency session in a wireless communication system including a network NT 3  and the UE UE 3 . The process  70  can be compiled into the program code  214  and includes the following steps: 
         [0065]    Step  700 : Start. 
         [0066]    Step  710 : Receive a detach request message DRQ′_m from the network NT 3  when a Routing Area Update procedure RAU_p is ongoing. 
         [0067]    Step  720 : Not abort the RAU_procedure RAU_p when the detach request message DRQ′_m is received. 
         [0068]    Step  730 : Proceed with the RAU_procedure RAU_p and a detach procedure DRQ′_p corresponding to the detach request message DRQ′_m concurrently. 
         [0069]    Step  740 : Start a timer T 1  and change to a state S 1  indicating the UE UE 3  is attempting the RAU_procedure RAU_p. 
         [0070]    Step  750 : End. 
         [0071]    According to the process  70 , when the UE UE 3  receives a detach request message DRQ′_m corresponding to a detach request procedure DRQ′_p from the network NT 3  while the RAU_procedure RAU_p is ongoing, the UE UE 3  does not abort the RAU_procedure RAU_p. The detach request message DRQ′_m may have a detach type “Re-attach not required” and GMM cause “IMSI unknown in HLR” to detach the UE UE 3  from CS services in the network NT 3 . The UE UE 3  proceeds with the RAU_procedure RAU_p and the detach procedure DRQ′_p to detach from CS services in the network NT 3 , and then starts the timer T 1  and changes to the state S 1  indicating the UE UE 3  is attempting the RAU_procedure RAU_p. The timer T 1  may be a timer T 3302 , and the state  51  may be a GMM-REGISTERED-ATTEMPTING-TO-UPDATE state according to the 3GPP Technical Specification TS 24.008, but not limited thereto. Therefore, the RAU_procedure RAU_p is not aborted and will be successful when collided with the detach procedure DRQ′_p. Further, the RAU_procedure RAU_p is not delayed until the timer T 1  expires or the UE UE 3  changes a routing area. 
         [0072]    Accordingly, the network NT 3  in the wireless communication system may take corresponding actions. Please refer to  FIG. 8 , which is a flowchart of an exemplary process  80 . The process  80  is utilized for the network NT 3  for handling the emergency session in the wireless communication system including the network NT 3  and the UE UE 3 . The process  80  can be compiled into the program code  214  and includes the following steps: 
         [0073]    Step  800 : Start. 
         [0074]    Step  810 : Receive a Routing Area Update request message RAU_m corresponding to the RAU_procedure RAU_p from the UE UE 3  when sending a detach request message DRQ′_m to the UE UE 3 . 
         [0075]    Step  820 : Process the RAU request message RAU_m and respond the UE UE 3  with an RAU accept message RAU_AC_m or an RAU reject message RAU_RJ_m when the RAU request message RAU_m is received. 
         [0076]    Step  830 : Proceed with the RAU_procedure RAU_p concurrently with the detach procedure DRQ′_p corresponding to the detach request message DRQ′_m. 
         [0077]    Step  840 : End. 
         [0078]    According to the process  80 , when the network NT 3  receives the RAU request message RAU_m from the UE UE 3  while sending the detach request message DRQ′_m to detach the UE UE 3  from CS services, the network NT 3  proceeds with the RAU_procedure RAU_p and the detach procedure DRQ′_p to detach the UE UE 3  from CS services concurrently and responds the UE UE 3  with the RAU accept message RAU_AC_m or the RAU reject message RAU_RJ_m. 
         [0079]    Alternatively, it is possible for the network NT 3  to not proceed with the RAU_procedure RAU_p and the detach procedure DRQ′_p concurrently. Please refer to  FIG. 9 , which is a flowchart of an exemplary process  90 . The process  90  is utilized in the UE UE 3 . The process  90  can be compiled into the program code  214  and includes the following steps: 
         [0080]    Step  900 : Start. 
         [0081]    Step  910 : Receive the detach request message DRQ′_m from the network NT 3  when the RAU_procedure RAU_p is ongoing. 
         [0082]    Step  920 : Abort the RAU_procedure RAU_p and proceed with the detach procedure DRQ′_p corresponding to the detach request message DRQ′_m when the detach request message DRQ′_m is received. 
         [0083]    Step  930 : Restart the RAU_procedure RAU_p immediately upon completion of the detach procedure DRQ′_p. 
         [0084]    Step  940 : End. 
         [0085]    According to the process  90 , the RAU_procedure and the detach procedure DRQ′_p to detach the UE UE 3  from CS services of the network NT 3  are not proceeded concurrently. Instead, the RAU_procedure will be aborted and restarted after the detach procedure DRQ′_p is finished. 
         [0086]    Briefly, according to the processes  70 ,  80 , and  90 , the RAU procedure RAU_p is processed concurrently with the detach procedure DRQ′_p, or restarted immediately after the detach procedure DRQ′_p is finished. Thus, the RAU_procedure RAU_p is not delayed until the time T 1  expires or until the UE UE 3  changes a routing area, and thus the UE UE 3  will not miss paging from the network NT 3 , and emergency call-back procedures will not fail. 
         [0087]    Please note that, the abovementioned steps of the processes  30  to  90  including suggested steps can be realized by means that could be hardware, firmware known as a combination of a hardware device and computer instructions and data that reside as read-only software on the hardware device, or an electronic system. Examples of hardware can include analog, digital and mixed circuits known as microcircuit, microchip, or silicon chip. Examples of the electronic system can include system on chip (SOC), system in package (SiP), computer on module (COM), and the communication device  20 . 
         [0088]    In conclusion, the exemplary examples and means are provided for handling emergency sessions and keeping the emergency context active during abnormal scenarios, so as to minimize unnecessary additional signaling and delays in the establishment of the emergency sessions. 
         [0089]    Those skilled in the art will readily observe that numerous modifications and alterations of the device and method may be made while retaining the teachings of the invention. Accordingly, the above disclosure should be construed as limited only by the metes and bounds of the appended claims.