Integration of Multipath Transmission into the IMS Framework.
IP multimedia subsystem (IMS) is an open standardized architecture for delivering multimedia service over IP network in a route-agnostic manner. With the increasing popularity of conversational class service, the delivery of a traffic flow with a certain bandwidth demand over a single network path is either not possible or not cost-effective. Multipath transmission is considered to be a promising solution to provide high-quality delivery service. This paper proposes a software defined service overlay network (SDSON) based multipath transmission framework for IMS, which is complementary to existing network architecture. The framework transforms original two-party session negotiation into three-party session negotiation that supports participants to negotiate multipath transmission capacity and path information by signaling message. Based on existing IETF standards, SIP and SDP are scalable to support these functions. Finally, the proposed framework is fully implemented on open source platform and examined by experiments. Experimental results show that multipath-enabled IMS is an effective way to improve the delivery performance of conversational class service.
Keywords: IP multimedia subsystem; multipath transmission; software defined service overlay network; conversational class service
I P multimedia subsystem (IMS) is an architecture framework for delivering multimedia services over an IP network . Thanks to fast development of information and communication technologies, conversational class services are recently available anytime and anywhere. The demand for conversational class services in IMS has been rapidly increasing. It is well known that the available resource over IP network has been becoming very limited because network subscriber grows rapidly and the traffic volume per subscriber increases rapidly. To improve delivery performance of conversational class service, it is vital to employ effective transport techniques. General, user experiences a well-connected access network through 3G/4G/WiFi, end-to-end path metric constraints occur in transport network. These facts make the problem of providing high-quality delivery service for conversational class service in IMS more challenging.
Services in IMS are agnostic on the way of media delivery in network. In traditional IP network, end-to-end media stream mainly depends on single path determined by network layer routing protocol. In most cases, a single path is not capable to completely support the delivery of conversational video service.
State-of-the-art terminals have remarkable characteristics, such as high computing power and large storage size. Thus, users may expect to explore new transport techniques through remarkable characteristics of terminal. Using multiple paths concurrently, termed multipath transmission, is regarded as one of the most potential transport techniques to support a variety of conversational class service requirements. This is mainly because multipath transport is able to make full use of link resource and to enhance quality of service (QoS). In order to establish multiple end-to-end paths, some research effort has been proposed. Comparing with IP layer multipath transmission and transport layer multipath transmission techniques, overlay network technique is an easy way to implement a new application without any requirement on underlying network. Zhang et al. proposed a multipath transmission framework, named software defined service overlay network (SDSON) . SDSON establishes a new multipath routing system that decouples routing control and data forwarding over overlay network. SDSON consists of three kinds of logical entities including user agent, relay server, and relay controller. All logical entities form an overlay network. The relay controller and the relay server compose the relay service system. Network intelligence is centralized in relay controller. The relay controller provides an access interface for applications to provide relay service. s
IMS presents the demand on transmission capacity to provide high quality delivery service for conversational class service. To address the problem, we propose a SDSON-based multipath transmission framework for IMS. Considering route-agnostic of IMS, end hosts have to negotiate multipath transmission during signaling exchange. However, existing IMS signaling mechanism does not support multipath transmission negotiation. This paper presents the requirements for IMS to support multipath transmission. Our main contributions are summarized as below:
* Propose SDSON-based multipath transmission framework for IMS.
* Present multipath transmission related information expression in SIP and SDP.
* Design three-party negotiation mechanism that replaces original two-party negotiation mechanism to negotiate multipath transmission.
The remainder of this paper is organized as follows. Section 2 briefly reviews related work. Section 3 presents the details of SDSON based multipath transmission framework for IMS. Section 4 conducts performance studies of the proposed solution. Section 5 draws conclusions.
2. Related Work
2.1 IMS Media Negotiation Mechanism
A complete solution to support IMS consists of user equipment (UE), IP-connectivity access networks (IP-CAN), and the specific functional elements of IMS CN [1, 3, 4]. IMS CN for call control includes different specialized call session control functions (CSCFs), such as proxy CSCF (P-CSCF) which transfers signaling message between UE and IMS CN.
Before media transmission, participants have to arrive at a common view of multimedia session between them. SIP messages carry session descriptions to support session negotiation. Session descriptions are formatted using SDP and exchanged using offer/answer model defined by RFC3264 .
An SDP session description consists of a session level section followed by one or more media level sections. Each section includes several SDP attribute lines, e.g., "c=" line and "m=" line. SDP offer/answer model supports participant to offer peer participant a description of the desired session from his viewpoint and the peer participant to response the offer with the desired session description from his viewpoint.
Several SDP related RFCs [6-8] define framework and mechanism to support participant to negotiate transport address, media type, transport protocol, and codec format, etc. However, they do not negotiate method and route of media transmission. In practice, media streaming is transmitted from source to destination over a single path selected by network layer routing protocol.
2.2 Multipath Routing
The idea of multipath transmission was first introduced in the 1990s . Multipath transmission has been introduced to various applications in order to achieve bandwidth aggregation, load balancing, and error recovery .
In multimedia communications, the delivery quality is affected by link quality metrics, such as bandwidth, delay, jitter, and loss rate. In multipath transmission, path correlation and transport control mechanism also have an important impact on the delivery quality. General, disjoint paths have the strongest disparity. However, focusing solely on disjointedness may cause the use of low quality link, which may result in a worse performance than the use of sharing some good quality links. An optimal path selection mechanism should jointly consider disjointedness and link quality. An excellent transport control mechanism can coordinate the relationship between transmission requirement and link capacity and make full use of path resource.
Multiple end-to-end paths can be established in several ways. Source routing allows the sender of a packet to partially or completely store the route in packet header in advance . Intermediate network node forwards packet to next node as indicated in the packet header. State-of-the art smart mobile devices have multiple advanced networking interfaces. Multiple end-to-end paths can be established by using multiple networking interfaces simultaneously. The Internet engineering task force (IETF) has proposed multipath TCP (MPTCP)  and stream control transport protocol (SCTP) [13, 14] for multi-homed host scenario. Overlay network technique is an alternative solution [15, 16]. All participating nodes form a new network over underlying network, and each logical link between them consists of one or more underlying network links . Each participating node performs as application layer routing/switching module.
In multipath transmission, control mechanism is the key to explore the benefit of multipath transmission. Xu et al. proposed a quality aware adaptive concurrent multipath transfer solution (CMT-QA) . CMT-QA monitors and analyses regularly each path's data handling capability, and distributes data over available paths intelligently. It mitigates the out-of-order reception by reducing reordering delay and unnecessary fast retransmission. Wu et al. proposed a goodput-aware load distribution model to address large end-to-end delay and consecutive packet losses caused by the path diversity and unreliability in heterogeneous overlay networks . Wu et al. proposed a distortion-aware concurrent multipath transfer (CMT-DA) solution that analyzes the data distribution over available paths to minimize the end-to-end video distortion and derive the solution based on the utility maximization theory .
Source routing contains the address of each node the packet will traverse, which incurs high overhead for long paths. Multi-homed host scenario requires that at least one of the end devices is multi-homed. Therefore, it is hard to implement source routing and multi-homed host scenario within the scope of whole network. Overlay network is an easy way to reconstruct a new routing system without any changes on underlying network.
2.3 Software Defined Service Overlay Network
SDSON is a multipath transmission framework that establishes a new routing system over underlying network . The routing system decouples the system that makes decision where the traffic is sent from the system that forwards traffic to the selected destination. The SDSON architecture consists of three kinds of logical entities (LEs), i.e., user agent, relay controller and relay server, that form an overlay network, as shown in Fig. 1. Although SDSON has no control over how the packet is routed in the underlying network between two logical entities, it can control the sequence of logical entities the packet traverses before reaching its destination.
Two terms to be used in the following parts are defined as follows:
* Default path: A path between the source and destination does not pass through any relay server.
* Relay path: A path between the source and destination passes through one or more relay servers.
Relay controller and relay server compose of relay service system that provides data forwarding service to user agent. Relay controller maintains a global view of the overlay network and serves as administrator of the network. Relay controller allocates/releases relay path considering the service features, transmission requirement, and its own predefined policy. Relay controller has two alternative methods to collect service features and transmission requirement: (1) indirect signaling message exchange with user agent through out-of-band signaling server, and (2) direct signaling message exchange with user agent.
Relay server runs as a routing module that accepts routing instructions from relay controller. It maintains a flow table and forwards data flow to next hop logical entity. Massive deployment of relay server is regarded as an efficient way to provide a better multipath condition for relay service system. Meanwhile, relay service system subscriber can provide data forwarding service for each other.
User agent is responsible for sending and receiving data packet. At the sender side, user agent maintains a path list including a default path and one or more relay paths. Before data transmission, user agent requests relay controller to allocate relay path for the session. During data transmission, user agent selects path from path list for each data packet. At the receiver side, user agent reorders the data packets received from multiple paths and sends it to the upper application orderly. After data transmission termination, user agent requests relay controller to release the allocated resource.
Relay path is composed of a set of continuous next hop of relay servers between the source and destination, and it is identified by a unique path identity (PID) assigned by relay controller. Each item of flow table includes a PID and the next hop address of relay server or user agent. Packet header contains a PID simply to select next hop LE. In addition to PID, data packet header contains a transport sequence number (TSN) and a flow sequence number (FSN) to support delivery status collection and packet reorder. In order to improve execution efficiency, relay path is designed to be unidirectional.
3. Multipath Transmission Framework for IMS
Due to service requirements are constantly changing and increasing, IMS architecture is open to service by decoupling session control and service process which benefits new service implementation. IMS CN only provide session connection and service management mechanism.
In this work, multipath transmission is regarded as a IMS service. IMS UE and application server can choose whether to use the multipath transmission service. To achieve above description, there are some specific considerations to support multipath transmission in IMS, such as architecture, multipath transmission capacity expression, multipath information expression, and multipath transmission negotiation procedure.
3.1 SDSON Based Multipath Transmission Framework for IMS
IMS framework that supports multipath transmission service is shown in Fig. 2 which does not include all IMS entities for brevity. A new IMS function element, multipath transport control function (MTCF), is defined. MTCF locates in P-CSCF and communicates with relay service system working as an out-of-band signaling server as shown in Fig. 1.
IMS CN adds a function block to process multipath transmission service. Multipath transmission related message is processed by MTCF. MTCF is the executives of media multipath transmission including multipath-related authorization, relay path allocation and release, and relay path information publication. In order to achieve this, MTCF has to participate in session negotiation procedure.
3.2 Multipath Transmission Service Negotiation
Within the session establishment procedure, session description carried by SIP message enables participants to arrive at a common view of multimedia session between them. Therefore, participants also have to agree on whether to use multipath transmission service.
Although RFC 3264 defines message format and offer/answer procedures for session negotiation, it did not define how to negotiate multipath transmission service, such as one or more alternative transport protocols or attributes. RFC 5939 overcame these shortages and defined a general SDP capacity negotiation framework which specified how to negotiate attribute and transport protocol as a capacity. RFC 6871 further extended the framework by defining media capabilities, such as media types and their associated parameters. In order to support multipath transmission service, SDP message needs to carry multipath transmission related information. During register procedure, MTCF detects multipath transmission capacity label from REGISTER message. If user agent support multipath transmission, MTCF provides multipath transmission authorization for user agent. SIP message is easy to be extended to support new functions. Thus, we define a new header field, "P-Capacity-Set: sdson", which is a mandatory field in REGISTER, INVITE/200OK, BYE. Entities that do not support the new header field simply processes as regular RFC 3261.
Basing on RFC 5939, multipath transmission service negotiation can be done by several newly defined attributes. Entities that do not support the capacity negotiation framework simply processes as regular offer/answer procedure. An attribute, "a=creq:<option tag>", lists extensions to the framework must be supported by participants. A new option tag, mpt-v0, indicates the usage of relay service system. Another attribute, "a=tcap:<option tag>", lists transport protocols as capacities. An option tag, MPRTP/SDSON, represents multipath RTP .
An example of multipath transport capacity expression is described. Part of an SDP session description offer is shown below. It shows that sender supports the usage of relay service system ("mpt-v0") and configures RTP and MPRTP as alternatives transport protocol where RTP is an actual configuration and MPRTP is a potential configuration indicated by the attribute, "pcfg=".
m=audio 34567 RTP/AVP 18
3.3 Relay Path Information Publication
If participants reach an agreement on the usage of multipath transmission service, MTCF manages relay path for the multipath-enabled session. MTCF collects transmission related information, e.g., session label, media label, transmission address and port, and requests relay controller to allocate one or more relay path for media transmission. Then, it publishes relay path information to participants using SDP offer/answer procedure.
Existing SDP attributes cannot carry relay path information, a new attribute is defined, as follows.
a= relay path: <direction> <priority> <path identity> <transport address>,
where <direction> instructs participant that received the SDP session description how to use the relay path. "send" means that participant can use this relay path to send data, while "recv" means that the participant can receive data from this relay path. <priority> indicates relay path priority. Packet in high priority relay path is treated as more important than packet in other low priority relay paths. If a relay server is congested and needs to discard some packets, it will discard packets in the relay path with lowest priority first. <path identity> and <transport address> indicate path identity and next/last-hop address, respectively. The new SDP attribute can be provided at session level and media level.
For example, in an audio session, the callee receives an SDP session description with relay path information as follows,
a= relay path: send 1 1234 IP4:192.168.139.101:54326
a= relay path: recv 3 4321 IP4:192.168.139.102:45671
It describes two relay-paths. The first one means that the callee can send data flow on relay path (1234) with next hop address (192.168.139.101:54326) and priority (1). The second one indicates that the callee receives data flow from relay path (4321) with last hop address (192.168.139.102:45671) and priority (3).
3.4 Multipath Transmission Negotiation Procedure
In original IMS framework, two participants arrive at a common view of media by exchanging session description. To support multipath transmission service, MTCF participants in original two-party session negotiation. Two rounds of offer/answer procedure support new session negotiation model to negotiate multipath transmission service and to publish relay path information, respectively. Fig. 3 shows an example of session negotiation procedure.
A newly defined header field, P-Capacity-Set, triggers MTCF to process multipath transmission related message. "mpt-v0" in Alice's offer implies that Alice supports relay service system. "MPRTP" and "RTP" in "a=tcap" indicate that MPRTP and RTP are configured as alternative transport protocol. MTCF identifies the connection information needed (IP address and port of down link multimedia flow) and forwards the SDP offer to Bob. Bob supports "mpt-v0" and MPRTP, and responds Alice's offer using 183. Upon the reception of 183 from Bob, MTCF identities the connection information needed (IP address and port of uplink multimedia flow) and forwards it to Alice. After Alice receives 183, multipath transmission capacity negotiation has been completed.
Basing on the result of the first round negotiation, Alice generates a new offer, UPDATE, to assist MTCF to publish relay path information to Bob. The new offer does not use SDP capacity negotiation framework. After receiving UPDATE, MTCF inquires connection information and requests relay controller to allocate relay path. Then it publishes relay path information for Bob using the newly defined SDP attribute ("a= relay path"). Similarly, MTCF publishes relay path information for Alice using 200 which is the response of UPDATE. When Alice receives the 200, both Alice and Bob have received relay path information to be used in data delivery.
4. Performance Evaluation
This section evaluates the performance of multipath transmission enabled IMS which is fully implemented in an open source platform (Kamailio, and IMSDroid). It is examined in an experimental network and compared with single path transmission.
The experimental topology is presented in Fig. 4. Di represents router or relay server. Between UEs, there are N (N > 1) alternative paths. The bottleneck of these paths fluctuate with the network environment. All testing results displayed are calculated by the mean value of the results of 50 runs in order to avoid being influenced by any stochastic factors.
4.1 Performance Verification
In this section, performance verification of multipath transmission enabled IMS is presented.
The first experiment is to evaluate the transmission capacity of the framework. For this case, the number of the used path ranges from one to five. Fig. 5 shows trace of session's throughput and the sum of bandwidth. As the number of the used path increases, the throughput has a significant increase. The throughput increases from 1.8 Mbps to 5.8 Mbps when the number of used path varies from 1 to 5. Comparing to the sum of path's bandwidth, the difference between throughput and sum becomes larger for further increase in the number of used path. As UE has to manage multiple paths which leads to incomplete bandwidth utilization. The result indicates that multipath transmission technique is able to significantly improve throughput.
Then we conduct experiment to compare the performance of multipath transmission enabled IMS with that of conventional single path transmission (default path) based IMS in terms of delay. In multipath transmission model, relay service system provides two relay-paths for the session. Fig. 6 shows trace of delay collected at evenly spaced points in time. We can see that the delay over relay path is quite stable with no significant changes. As relay path may not be the shortest link set from the source to the destination and has low relevance with underlying links in congestion. After test case 4, the delay of default path increases shapely. It is mainly caused by congestion in one or more underlying links. The average delay of default path is smaller than that of relay path as additional delay necessary for media relay at overlay network. But the difference of average delay between two relay-paths and default path is quite small, due to additional delay for media relay at overlay network is very small comparing to transmission delay in underlying link.
4.2 Performance Study for Conversational Class Service
In multipath transmission, how to schedule data packet across available paths is a key issue that affects the performance of transmission. In order to reduce the amount of data to be transferred, original data streaming may be compressed, which makes it very vulnerable to delivery error and packet loss. In order to achieve a good experience, service subscriber is willing to pay for additional bandwidth consumption in most cases. In this work, we introduce a redundancy transmission model to distribute traffic.
In the redundancy transmission, packets are redundantly transmitted over multiple paths, and receiver delivers the first correctly arriving packet to the upper application and discards further copies of the packet if they correctly arrive. According to redundancy ratio, redundancy transmission model is divided into two types, i.e., complete redundancy transmission and partial redundancy transmission model, as shown in Fig. 7. According to traffic characteristics, we select redundancy ratio to balance additional fee and the benefit of redundancy transmission.
UEs establish an audio-video session. The test uses single path transmission model and multipath transmission model to deliver traffic, respectively. In multipath transmission model, relay service system provides two relay-paths for the session. We select complete redundancy transmission model to distribute traffic.
Conversational class service is always performed between live user (human). Hence, user's quality of experience is a key measurement of delivery service. Mean opinion score (MOS) is a subjective spatial video stream metric from the perspective of user's experience. To evaluate the performance of multipath-enabled IMS, we invite subjects who are non-experts with no experience with transmission technology to mark their scores. The complete test panel consists of 50 subjects, 20 subjects are male and 30 subjects are female. The maximum age is 60, the minimum age is 20, and the average age is 36.5. During the voting times, they are asked to mark their option at evenly spaced points in time. For each subject, the scores have been normalized to the range of [0, 5]. The MOS is computed by averaging subjects normalized scores. Fig. 8 displays trace of MOS collected at evenly speed points in time. We observe that multipath transmission model outperforms conventional single path transmission model in all test cases. As multipath transmission provides an opportunity to improve transmission performance.
This paper proposed a framework for IMS to support multipath transmission in an easy way. Our proposal was motivated by the high bandwidth requirement of conversational class service over IP network. SDSON is an effective way to establish multiple end-to-end paths and is complementary to existing network architecture. Participants negotiate multipath transmission capacity and relay path information by two rounds of offer/answer mechanism. MTCF that communicates with relay service system participant in original two-party session negotiation. A new SIP header is used to trigger MTCF to process multipath transmission related SIP message. Extension of SDP attribute is able to carry relay path information. The proposed solution is implemented on open source platform and is examined in an experimental network. Considering the multipath characteristic, we introduce redundancy transmission model to improve reliability. The experimental results show that the multipath-enable IMS is effective to provide a higher bandwidth for application and to improve the delivery quality.
This work was supported by the National Natural Science Foundation of China [No. 61401081], the Fundamental Research Funds for the Central Universities [No. N150404005], and the Ministry of Education - China Mobile Research Funds [No. MCM20150103].
 IP Multimedia Subsystem (IMS) Stage 2, 3GPP TS 23.228, 2015. Article (CrossRef Link)
 W. Lei, W. Zhang, and S. Liu, "A Framework of Multipath Transport System Based on Application-Level Relay (MPTS-AR)," IETF, Internet-Draft, Jan, 2017. Article (CrossRef Link)
 Network architecture, 3GPP TS 23.002, 2014. Article (CrossRef Link)
 IP Multimedia Subsystem (IMS) Stage 1, 3GPP TS 22.228, 2014. Article (CrossRef Link)
 An Offer/Answer Model with the Session Description Protocol (SDP), RFC 3264, Jun, 2002. Article (CrossRef Link)
 SDP: Session Description Protocol, RFC 4566, Jul, 2006. Article (CrossRef Link)
 Session Description Protocol (SDP) Capability Negotiation, RFC 5939, Sep, 2010. Article (CrossRef Link)
 Session Description Protocol (SDP) Media Capabilities Negotiation, RFC 6781, Feb, 2013. Article (CrossRef Link)
 N.F. Maxemchuk, "Dispersity routing in high-speed networks," computer networks and ISDN systems, vol. 25, no. 6, pp. 645-661, 1993. Article (CrossRef Link)
 E. Gustafsson and G. Karlsson, "A literature survey on traffic dispersion," IEEE Network, vol. 11, no. 2, pp. 28-36, Mar. 1997. Article (CrossRef Link)
 D. Johnson, Y. Hu, D. Maltz, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4," RFC 4728, Feb, 2007. Article (CrossRef Link)
 A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar, "Architectural guidelines for multipath TCP development," RFC 6182, Mar, 2011. Article (CrossRef Link)
 R. Stewart, "Stream control transmission protocol," RFC 4960, 2007. Article (CrossRef Link)
 J.R. Iyengar, P.D. Amer, and R. Stewart, "Concurrent multipath transfer using SCTP multihoming over independent end-to-end paths," IEEE/ACM Transactions on Networking, vol. 14, no. 5, pp. 951-964, Oct. 2006. Article (CrossRef Link)
 Z. Li and P. Mohapatra, "QRON: QoS-aware routing in overlay networks," IEEE Journal on Selected Areas in Communications, vol. 22, no. 1, pp. 29-40, Jan. 2004. Article (CrossRef Link)
 V. Bui, W. Zhu, A. Botta, and A. Pescape, "A markovian approach to multipath data transfer in overlay networks," IEEE Transactions on Parallel and Distributed Systems, vol. 21, no. 10, pp. 1398-1411, Oct. 2010. Article (CrossRef Link)
 W. Zhang, W. Lei, S. Liu, and G. Li, "A general framework of multipath transport system based on application-level relay," Computer Communications, vol. 51, pp. 70-80, Sep. 2014. Article (CrossRef Link)
 C. Xu, T. Liu, J. Guan, H. Zhang, and G.-M. Muntean, "CMT-QA: Quality-aware adaptive concurrent multipath data transfer in heterogeneous wireless networks," IEEE Transactions on Mobile Computing, vol. 12, no. 11, pp. 2193-2205, Nov. 2013. Article (CrossRef Link)
 J. Wu, C. Yuen, B. Cheng, Y. Shang, and J. Chen, "Goodput-aware load distribution for real-time traffic over multipath networks," IEEE Transactions on Parallel and Distributed Systems, vol. 26, no. 8, pp. 2286-2299, Aug. 2015. Article (CrossRef Link)
 J. Wu, B. Cheng, C. Yuen, Y. Shang, and J. Chen, "Distortion-aware concurrent multipath transfer for mobile video streaming in heterogeneous wireless networks," IEEE Transactions on Mobile Computing, vol. 14, no. 4, pp. 688-701, Apr. 2015. Article (CrossRef Link)
 W. Zhang, W. Lei, S. Liu, G. Li, "A General Framework of Multipath Transport System Based on Application-level Relay," Computer Communications, vol.51, pp.70-80, 2014. Article (CrossRef Link)
 W. Lei, W. Zhang, and S. Liu, "Multipath Real-Time Transport Protocol Based on Application-Level Relay (MPRTP-AR)," IETF, Internet-Draft, January, 2017. Article (CrossRef Link)
Shaowei Liu, Weimin Lei (*), Wei Zhang and Hao Li
Shaowei Liu is a Ph.D. candidate with School of Computer Science and Engineering, Northeastern University, China. His current research interests include media transmission, network architecture, and network protocol.
Weimin Lei is a professor and a supervisor with Institute of Communication and Electronic Engineering, Northeastern University, China. His current research interests include protocols and services in IP multimedia system, multipath transport, overlay network, SDN and adhoc network.
Wei Zhang is a lecturer with Institute of Communication and Electronic Engineering, Northeastern University, China. Her current research interests include multimedia communication, protocols and services in next generation network, and network architecture of cloud computing.
Hao Li is a Ph.D. candidate with School of Computer Science and Engineering, Northeastern University, China. His current research interests include media transmission and network protocol.
School of Computer Science and Engineering, Northeastern University Shen Yang, Liao Ning 110819--China
[e-mail: email@example.com, firstname.lastname@example.org]
(*) Corresponding author: Weimin Lei
Received February 16, 2017; revised April 19, 2017; accepted May 3, 2017; published August 31, 2017
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||internet protocol multimedia subsystem|
|Author:||Liu, Shaowei; Lei, Weimin; Zhang, Wei; Li, Hao|
|Publication:||KSII Transactions on Internet and Information Systems|
|Date:||Aug 1, 2017|
|Previous Article:||A Range-Based Monte Carlo Box Algorithm for Mobile Nodes Localization in WSNS.|
|Next Article:||An Effective Viewport Resolution Scaling Technique to Reduce the Power Consumption in Mobile GPUs.|