When a group of machine type communication (MTC) ‘smart mobile devices’ in vehicular area network move together as a single unit, the network requires to resolve how to manage the group-based location transition and handoff for all group members with efficient signaling exchange and congestion mitigation. As an attractive solution, the Session Initiation Protocol (SIP) based Network Mobility (SIP-NEMO) has attracted much interests among the industry and academia. However, SIP-NEMO is vulnerable to the simultaneous handoff problem and weak in supporting seamless services, because of the direct binding updates between both mobile SIP nodes, as well as a potentially large number of mobile devices. In this paper, we investigate a novel group-based SIP sessions mobility management scheme for the MTC devices that are onboard traveling among long term evolution base stations. Firstly, some novel basic attributes of the SIP protocol are defined and the corresponding key SIP session procedures, including session setup, location registration and location update, are optimized. Then, we propose a predictive resource reservation algorithm for group-based handoff to achieve seamless services. Furthermore, we develop an analytical model to study the performance from the aspect of the average handoff delay. The simulation results indicate that the network congestion caused by the simultaneous handoff of a group of MTC devices onboard could be reduced effectively.
1 Introduction
According to various research forecast, the amount of machine type communication (MTC) devices and applications based on long term evolution (LTE) cellular network will boom rapidly over next decade [1, 2]. With the widespread deployment of vehicular area network (VAN) and the increasing affordability of MTC smart devices, the scenarios of uninterrupted access services on-the-go on vehicle are booming. VAN is a typical mobile network and generally roams among LTE cellular networks with higher mobility rates. There are frequent location transitions and collective handoffs for all of the smart machines onboard, which will lead to heavy signaling overhead or even network congestions [3]. Therefore, there are strong needs for efficient handoffs and group mobility management mechanisms for seamless service access.
In light of this, several group mobility management mechanisms have been proposed, such as Network Mobility Basic Support Protocol (NEMO-BSP) [4], Mobile IP version 6 (MIPv6) [5], MIP with Location Registers (MIP-LR) [6, 7], Session Initiation Protocol (SIP) based network mobility (SIP-NEMO) [8] and etc., and SIP-NEMO is the most inspiring solution. It uses SIP header translation instead of bi-directional tunneling, all the traffic is delivered directly to the current location of SIP nodes without transferring by any intermediate nodes [9]. Hence it can provide the optimized route path and reduce the handoff delay even for the complicated nested mobile sub-network scenario. This is very attractive for standardizations and research institutes [8].
Anzeige
However, SIP-NEMO also has some weaknesses. It uses direct binding updates for all the correspondent nodes (CNs) which are moving at the same time. Therefore, SIP-NEMO is vulnerable to the simultaneous handoff problem [10]. Meanwhile, the congestions due to simultaneous signaling messages could be significant [11], especially when a potentially large number of MTC devices work as a group unit and concurrently trigger the access attempts to registration or handoff for new network in a short time period. In that scenario, the signaling traffic is considerably heavy, and the network performance is seriously dropped, it is hard for SIP-NEMO to achieve seamless mobility. Considering that the disruption of services caused by the simultaneous group mobility may far exceed the typical one caused by non-simultaneous mobility [8], it should be solved properly.
In response to these problems, researchers have discussed possible solutions based on the modification of SIP-NEMO [12, 13]. Proposal [12] presents a proxy-aided simultaneous handover (PASH) mechanism. It products two new user-defined SIP headers,it fast re-establishes the optimized routing path and ensures signaling messages buffered in local proxy could be sent to the correct destination without loss. However, so far as we know, until now, the potential of protocol-layer implementation for group-based simultaneous handover features has not been considered in detail yet, and the corresponding procedure and the handoff delay have not been optimized to achieve seamless mobility.
In our earlier works, we have proposed the group-based SIP session aggregation mechanism [14]. This paper further contributes by extending that work to support seamless SIP session mobility management for a group of MTC machines collectively travelling into new network. The contributions include: (1) Novel attributes in SIP header extension field are defined as the group identifier. (2) Key procedures for group-based simultaneous SIP-NMO are optimized to improve the session efficiency. (3) Predictive resource reservation algorithm for group-based handoff is proposed to achieve seamless mobility for MTC devices in Vehicular Area Networks.
The remainder of this paper is organized as follows. Section 2 analyzes the related work about the SIP-NEMO and the scenario model. Section 3 introduces the location management framework for MTC services based on SIP-NEMO infrastructure in VAN. Section 4 describes the group based mobility management mechanism. Section 5 analyzes the performance of proposed mechanism. Section 6 concludes this paper.
Anzeige
2 System Model and Key Issues Analysis
In this section, we first make a description of the SIP-NEMO architecture and the key components. Then the scenario of group-based simultaneous handoff for LTE cellular MTC network on vehicle is presented and analyzed.
2.1 SIP-NEMO
SIP-NEMO is based on the SIP architecture. SIP network mobility server (SIP-NMS) is the key functional entity. It is the MTC gateway for the roaming mobile network and takes the responsibility to manage the SIP sessions and keeps globally connectivity of all attached nodes. Each SIP-NMS has its corresponding SIP home server (SIP-HS) with a registrar service containing the latest location information. The SIP foreign server (SIP-FS), which acts as the SIP Back-to-Back User Agent (B2BUA), plays an important role by providing Uniform Resource Identifier (URI) list service [15]. Home Subscriber Server (HSS) is the main database containing subscription related information of the MTC mobile devices. Usually it takes charge of the authentication, authorization, accounting and charging.
2.2 Group-Based Handoff Scenario for SIP-NEMO
As illustrated in Fig. 1, mobile VAN consists of SIP-NMS and a group of mobile ‘smart devices’ onboard. They travel among various LTE evolved Node Bs (eNBs) as a single unit and communicate with the LTE network via SIP-NMS, which maybe an individual network entity or one of the MTC mobile devices in this group. Each MTC mobile device also has its own home registrar at its home domain.
Fig. 1
Scenario of group-based handoff for LTE based cellular MTC network on vehicle
×
When a vehicle network is moving from one access network to another, the corresponding SIP-NMS collects the source and destination addresses of all its ongoing SIP sessions into a SIP-URI list. Once it gets a new point of attachment, it will recover all ongoing sessions and inform its SIP-HS about its new location. Therefore, the corresponding node (CN) can consult the registrar to find out a MTC mobile device’s location. The application server which collaborates with the registrar can support various MTC applications.
3 Group-Based Location Management for Simultaneous Handoff
The aim of this section is to examine the key procedures of SIP sessions for group-based simultaneous mobility management. To implement the bulk processing mechanism, which is common to handling a group of similar SIP sessions, the group identifier for a bulk of VAN mobile devices with common behavior features (e.g. collectively handoff to the new network, encamp in the same area and etc.) are defined in the SIP basic extension attribute fields. Then, the corresponding mobility management procedures are optimized to solve the simultaneous handoff problem of SIP-NEMO.
3.1 Extension Attributes for Group-Based SIP-NEMO
Thanks to the scalability of Session Discovery Protocol (SDP) [16], some novel extension attributes are defined in the SDP media description domain with the attribute “a =” as the Traffic Type Indication (TTI), the Group Identification (GID) and the Global Unique Identifier (GUI) for a SIP-NEMO group or a single mobile device [10], and the Serving Naming Server (SNS) is a distributed database that maintains mapping relationships between GID or GUI and SIP URI. The SNS provides query services similar to Domain Name Server (DNS) and Object Name Server (ONS) [17].
The following statements show these SDP novel attributes in the form of command lines.
Considering the MTC group features, the SIP URI of mobile device in MTC group can be generated by the SNS hierarchically. For instance, in the VAN of alice, the monitors of MTC devices in this network form one MTC group named as vehicle-monitor-alice. The SIP URI of this MTC group could be in the form of vehicle-monitor@alice, while one MTC sensor device that belongs to this group may be named as sensor1.vehicle-monitor@alice. By using hierarchical SIP URI naming rule, both the SIP URI of mobile machine and MTC group could be easily resolved by SNS.
3.2 Location Registration and Updating Procedure
The SIP-NMS triggers the location registration procedure on behalf of the individual mobile device. To do this, the SIP-NMS needs the SIP URI by referencing SNS. Once obtaining the SIP URI, the SIP-NMS updates the current location of this MTC mobile device by sending a REGISTER message to SIP-HS (S-CSCF) in its home domain. The current location, i.e. in the foreign domain, is contained in the CONTACT field of the REGISTER message.
For example, we assume that the concerned MTC device’s home domain is alice_eNB1 and the MTC device’s SIP URI is bupt-20394x.vehicle-monitor@alice_eNB1. The MTC device moves from alice_eNB1 domain to the foreign domain, alice_eNB2.
The location registration procedures shown in Fig. 2 consist of the following steps:
Fig. 2
SIP procedure of location registration
1.
SIP-NMS forwards the MTC GUIGID and related information (e.g. its own IP address) to the visit SIP-FS (P-CSCF).
2.
Once receiving the related information the visit SIP-FS (P-CSCF) performs authentication with HSS to verify the MTC mobile device or the MTC group.
3.
After completing authentication processes the visit SIP-FS (P-CSCF) consults the SNS to obtain the SIP URI corresponding to the MTC device (e.g. bupt-20394x).
4.
The SNS finds out the SIP URI and then returns the SIP URI (e.g. bupt-20394x@alice_eNB1) to the visit SIP-FS (P-CSCF).
5.
The visit SIP-FS (P-CSCF) performs a location registration by sending a REGISTER message that contains the current location of the mobile device bupt-20394x@alice_eNB2, in the CONTACT field.
6.
If the REGISTER message is successfully processed the visit SIP-HS (S-CSCF) registrar server sends a response message, 200 OK, back to the visit SIP-FS (P-CSCF).
×
The SIP-FS (P-CSCF) also registers this current location to the corresponding local registrar, i.e. home SIP-HS (S-CSCF) registrar in alice_eNB1 domain. The aim of this registration is to forward tracking messages that arrive at alice_eNB1 domain to the device’s current location, i.e. alice_eNB2 domain. By this message, the visit SIP-FS (P-CSCF) learns the precise location of this mobile device and the future SIP messages for this device can be forwarded to the visit SIP-FS (P-CSCF).
3.3 Location Tracking Procedure
If CN wants to track the current location of the MTC mobile device or MTC group, the CN queries the SIP URI of this MTC mobile device or MTC group. After sending the INVITE message to the corresponding SIP-NMS (MTC Gateway), the gateway replies with the mobile device’s current location. In other words, if a tracked device resides under one SIP-HS (S-CSCF)’s administration, the SIP-HS (S-CSCF) informs the CN of the device’s current location by sending a 200 OK message which contains the device’s IP address in the CONTACT field. After receiving this 200 OK message, the CN learns the mobile device’s current location by parsing the CONTACT field [18].
Figure 3 illustrates the location tracking and session setup procedure initiated by a CN.
Fig. 3
SIP procedure of location tracking
×
The location querying and session setup procedure initiated by a CN shown in Fig. 3 consist of the following steps:
1.
The CN that would like to know the current location of a MTC mobile device or MTC group consults the SNS to finds their SIP URI.
2.
The SNS finds out the corresponding SIP URI and returns it to the CN.
3.
With the SIP URI found, bupt-20394x.vehicle-monitor@alice_eNB1, the CN sends an INVITE message to home SIP-FS (P-CSCF) in its domain. The home SIP-FS (P-CSCF) then forwards it to the visit SIP-FS (P-CSCF). Once receiving the INVITE message, the visit SIP-FS (P-CSCF) queries the visit SIP-HS (S-CSCF) to find the current location of MTC mobile device or MTC group.
4.
The visit SIP-HS (S-CSCF) informs the home SIP-FS (P-CSCF) of the movement. This notification is accomplished by sending a 302 moved temporarily response message, which contains the new SIP URI, alice_eNB2 in CONTACT field. This new SIP URI has already been registered through a location registration procedure when the MTC group moved to the alice_eNB2 domain.
5.
After receiving the response message, the SIP-FS (P-CSCF) sends an INVITE message again to visit SIP-HS (S-CSCF) in the alice_eNB2 domain.
6.
MTC gateway sends back a 200 OK response message. The CONTACT field of the 200 OK messages includes the IP address (i.e. 147.46.0.1) as well as the SIP URI (i.e. bupt-20394x.vehicle-monitor@alice_eNB2). After receiving this response, the SIP-HS (S-CSCF) relays the 200 OK messages to the visit SIP-FS (P-CSCF), which in turn relays the response to the CN.
Group-based handoff can be defined as a way to carry out the handoff process for the MTC devices that belong to one same group. As the network behaviors happen simultaneously for all members in a group, the required traffic of SIP sessions is much less than the one if these devices perform their handoffs separately. In other words, the group mobility is assumed as an optimized set of procedures so that the required SIP sessions traffic is minimized. In addition, predictive resource reservation is a promising mechanism for mitigating harmful high-latency effects which are produced by address re-allocation while performing handoff process. The underlying idea is that the MTC devices which anticipate handoff start the necessary resource reservation and the Re-INVITE operations before the actual handoff procedure initiates, by which the handoff delay is reduced significantly [19].
The predictive handoff progress for MTC network is similar to the one for LTE network. The handoff process is controlled by SIP-NMS device and the handoff decision is based on the measurement taken by the MTC mobile device. The MTC mobile device measures the radio signal strength by the metrics such as Reference Signal Receiving Power (RSRP) or Received Signal Strength Indication (RSSI). Then the measured RSRP or RSSI samples can be averaged incoherently by L1-filter (also named as the physical layer filter) for every measurement time period, the implement of L1-filter is controlled by the vendor of mobile devices. The L3-filter (also named as the network layer filter) is introduced to the handoff criteria evaluation, of which the results are based on the L1-filter measure results and the L3-filter previous outputs (Fig. 4).
where Rn is the updated L3 filtered measurement at the time period of n, Rn−1 is the L3 filter outputs at the time period of n − 1. Mn is the latest RSSI/RSRP measurement result after L1-filter. K is the filter coefficient configured by network.
The SIP-NMS monitors the filtered RSRP or RSSI of all detected cells. Once the entry condition in (2) is fulfilled, the handoff timer T1 is restarted.
$${R_{n,i}} \ge {R_{n,s}} + {T_h},$$
(2)
$${R_{n,i}} \le {R_{n,s}} - {T_h},$$
(3)
where Rn,I is the filtered RSRP or RSSI of any detected cell other than serving cell. Rn,s is the filtered RSRP or RSSI of the serving cell. Th is the handoff threshold configured by network and its value is generally positive to avoid Ping-Pong effect.
When the condition in (2) is satisfied during the given period, and the leaving condition in (3) is not triggered, the timer T1 expires. The timer T1 will stop when the leaving condition in (3) meets, once the timer T1 expires, the SIP-NMS prepares to handoff the MTC group to the new target cell by using an internal procedure as following.
As illustrated in Fig. 5, when SIP-NMS triggers the handoff, it will send the HO_Reserv_Req to the Serving SIP-FS (P-CSCF) (In the example, @alice_eNB1) which parses the header line and extracts the relevant information. The Serving SIP-HS (S-CSCF) consults the neighboring database to make decision in which domain the neighbor target cell belongs to. If the target cell and the serving belong to the same IMS domain, only link level (L2) handoff is necessary. Otherwise, network layer (L3) handoff is initiated. The HO_Reserv_Req message contains information including Group SIP URI (vehicle-monitor@alice_eNB1), the number of MTC devices and the required resource to support MTC group services.
Fig. 5
SIP session of MTC predictive group handoff
×
Taking inter-domain L3 handoff as an example, it is assumed that the target cell belongs to the alice_eNB2 domain. Serving SIP-HS (S-CSCF) will transfer the HO_Reserv_Req to the target SIP-HS (S-CSCF). Target cell will decide to accept or reject the session depending on the authentication, resource requirements and session capacity capability. If the HO_Reserv_Req is accepted, target SIP-HS (S-CSCF) will generate a new Group SIP URI (for example: vehicle-monitor@alice_eNB2), MIPV6 is also utilized to get a new IP address. The updated Group SIP URI and negotiated resource parameters are fed back to SIP-NMS via the HO_Reserv_Response message. On the other hand, if the request is rejected due to some reasons such as limited resource in target cell, HO_Reserv_Response with NACK is also required to SIP-NMS. Similarly, the resource negotiation between target cell and CN is also implemented simultaneously to guarantee the resource availability throughout the path.
For the MTC group with different services and resource requirements, individual precondition negotiation is vital since some clients/applications require certain precondition (that is, QoS level) to be met before handing-off a session. MTC gateway combines all resource reservation requests from the Group SIP URI into a single SIP session message and forwards it to the CN. Hence the signaling overhead of handoff session is obviously reduced.
Then the MTC gateway will implement the resource reservation process after received the HO_Reserv_Response message. After the negotiation is finished between SIP-NMS, target Cell and CN, SIP-NMS will initiate the Re-INVITE message with new Group SIP URI and negotiated SDP parameters to the target SIP-FS (P-CSCF). Then, a REGISTER request with update call-ID is sent from target SIP-HS (S-CSCF) to HSS/SNS to update the SIP address of MTC group.
The establish process of the new sessions is the same as that of the normal SIP sessions. However, the packet exchange now happens through both new sessions and old sessions until the handoff procedure is completed successfully. The Real-time Transport Protocol (RTP) connection is bi-casting to minimize the chance of packet loss during handoff procedure. The old session is breakup after the handoff is completed. Once the CN responds with a 200 OK message, the SIP-NMS and CN will send the BYE message to terminate the old session, the MTC group will be reachable globally via the new network. It means that both old and new SIP signaling sessions used for handoff management are maintained until the handoff procedure is completed successfully, which guarantee the seamless access experience.
SIP-NMS configures the RTP packet replicator and the filter for the particular on-going dialog to send a copy of packets directed toward Serving SIP-HS (S-CSCF) to target SIP-HS (S-CSCF) and filter duplicate packets coming from the SIP-NMS via the two RTP connections. Therefore, for a transient period, the RTP packets reach both interfaces of the SIP-NMS. The duplicate RTP packets at the MTC gateway are filtered by the packet filter and delivered to the upper layers, while those at the media gateway are filtered and sent to the CN [23].
To support the group handoff, the HO_Reserv_Req and HO_Reserv_Response messages have to be modified to contain explicit information of the MTC group. One example for HO_Reserv_Req and HO_Reserv_Response message is given respectively as following:
5 Performance Evaluation
In this section, we discuss the average handoff delay for this proposed mechanism. The handoff delay is comprised of several factors, including transmission delay, processing delay and queuing delay.
$$D = {D_t} + {D_p} + {D_q},$$
(4)
where D, Dt, Dp and Dq denote the average total SIP delay, transmission delay, processing delay and query delay, respectively.
The transmission delay depends on message size and channel bandwidth. The handoff procedure given in former section consists of six exchanges between SIP-NMS and CN.
$${D_t} = 6 \times {D_{tcp}},$$
(5)
where Dtcp is the average delay for successful TCP segment transmission.
The processing delay is the delay incurred during packet encapsulation and de-capsulation at the network layer.
where 8 and 5 denote the processing times of signaling messages at the corresponding nodes, i.e. SIP-FS (P-CSCF) and SIP-HS (S-CSCF). Dp-pcscf and Dp-scscf denote the average unit message processing delay at SIP-FS (P-CSCF) and SIP-HS (S-CSCF), respectively [21].
Taking a queuing theoretical method, each network node can be presented by a separate queue. We assume M/M/1 queues for the network nodes and Poisson process for the SIP signaling arrival rate.
Considering the network with MTC group service and normal service, and the normal service has higher priority than MTC service. The traffics in the same priority class obey the rule of FIFO service. Figure 6 shows a transmission path with three intermediate nodes and two traffic classes. Although the two classes share a common transmission path, both classes can be treated as have virtual separate queues at each node.
Fig. 6
Priority based query for MTC service
×
Denote the arrival rate and the service process rate of MTC service as λm and μm, the arrival rate and the service process rate of normal service is λn and μn. Hence, \({\rho_m} = {\lambda_m}/{\mu_m}\) and \({\rho_n} = {\lambda_n}/{\mu_n}\) is the system load for MTC and normal service, respectively.
Based on Little’s theory [22], the average queue time of signaling in one node is:
where Wq and W denote the queuing delay and residual delay, respectively. The priority of class 1, i.e. the normal service is considered having the higher priority, while that of the class 2, i.e. MTC service, is considered having the lower priority. Higher the priority is, lower queuing delay the corresponding traffic class has.
1.
Non-Stricte Priority
Assumed in the priority queue, the higher priority traffic is served immediately after the current serving traffic. Therefore, the traffic queue is formed by several logical sub-queues based on the priority, in which the non-empty sub-queue with higher priority is served next.
For the first priority class (Normal service in the scenario), the queuing delay can be written as:
Assume the low priority traffic would be interrupted by incoming high priority traffic and resume after the high priority service has been completed. For the low priority traffic of class k, the average queuing delay is
Based on the experiment data and experience value, the process times in MTC group message and normal service message are μn = 30 and μm = 40. The traffic arrival rate of single MTC and normal service are λn = 1 and λm = 0.1. The number of MTC devices in MTC group is Nm = 10. The number of normal UE is Nn = 10.
Firstly, we analyze the queuing delay due to the introduction of MTC service. Figures 7 and 8 compare the average queuing delay adopting proposed scheme with traditional scheme in terms of the number of MTC group device and the MTC traffic arrival rate separately. In traditional scheme, the SIP handoff message is initiated by each MTC device separately. With the growth of MTC device number or MTC traffic load, the expected queuing delay grows obviously, causing a rapid decline in system performance and handoff latency. Meanwhile, the group handoff scheme decrease the queuing delay significantly, especially in heavy traffic load cases for the convergence of SIP messages.
Fig. 7
Average queuing delay of MTC handoff schemes with MTC device number
Fig. 8
Average queuing delay of MTC handoff schemes with MTC service load
×
×
Secondly, analysis of numerical handoff delay is discussed considering the transmission delay, process delay and queuing delay. Table 1 presents the simulated total handoff latency for the proposed predicative group handoff and traditional handoff scheme as the function of MTC traffic arrival rate. The unit packet processing delay for the network nodes is assumed to be 8 ms. For normal SIP message size and transmission bandwidth, the unit TCP transmission delay is 4 ms [21].
Table 1
Total handoff latency (ms) of different schemes
Device group number
Conventional handoff
Predictive group handoff
1
240
120
2
344
136
4
542
242
6
946
340
8
1486
428
10
1238
424
12
2860
484
As the queuing delay is the main factor of handoff latency, more queuing delay means more handoff latency. As depicted in Table 1, the benefits compared with conventional handoff become visible with large groups of MTC devices. The reason is that the resource preservation method leads to reduction of queuing delay and less SIP messages.
6 Conclusion
In this paper, we investigate the group mobility management of MTC network from the aspects of location registration update and handoff. Predictive group handoff scheme is proposed to reduce the handoff delay and SIP signaling. Simulation results prove the proposed mobility management framework and procedures could alleviate the network signaling congestion caused by the simultaneous handoff of a group of MTC devices onboard.
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
