Abstract
Multimedia broadcast is the most efficient method to distribute identical content to multiple users in the Evolved Packet System (EPS). EPS enables efficient usage of network resources and provisioning of quality of service for every user. Third-party control allows applications in an enterprise domain to invoke network functions like multimedia broadcast. In this paper, an approach to modeling the behavior of Service Capability Server (SCS) for multimedia broadcast in EPS is presented. Third-party applications can access multimedia broadcasting capabilities by using Parlay X Web Service interfaces. The SCS for multimedia broadcast exposes Parlay X interfaces toward 3rd-party applications and control protocols toward the network. The SCS functional behavior has to be synchronized with the application view on message broadcast and the state of the network resources intended for the broadcast session. Models of multicast session, IP connectivity session, and bearers’ and charging session are proposed and formally described using the notation of Label Transition Systems. The concept of weak bisimilarity is used to prove that models expose equivalent behavior; that is, they are synchronized.
1. Introduction
The Evolved Packet System (EPS) is standardized to provide ubiquitous access to multimedia services from any end user device. It encompasses both access network and core network. The multimedia packet core network plays an important role in providing superior user experience from services and applications. It is in charge of provisioning quality of service (QoS) for multimedia bearer services and charging mechanisms.
Multimedia broadcast/multicast service (MBMS) allows data to be transmitted to multiple endpoints. It allows optimizing network resources using a distribution mechanism. The broadcast mode is a unidirectional point-to-multipoint transmission of multimedia data (e.g., text, audio, picture, and video) from a single source entity to all users in a broadcast service area. A broadcast service received by the end user device involves one or more successive broadcast sessions. A broadcast service might, for example, consist of a single ongoing session (e.g., a media stream) or may involve several intermittent sessions over an extended period of time [1, 2]. Examples of content appropriate to a distribution scheme are broadcasting TV channels and distribution of area-based multimedia messaging service including commonly interested traffic, weather, or emergency information. The content provider (broadcast/multicast source) may provide discrete and continuous media, as well as service descriptions and control data. The multimedia content may be provided by a 3rd-party content provider.
The broadcast mode is intended to efficiently use EPS resources. Current research on MBMS covers different aspects related to optimisation of radio technology used for data transmission. Relatively low attention is paid on MBMS third-party control, which allows third-party providers from an IT domain to create applications that use network connections, streaming, messaging, and multimedia.
In this paper, we discuss some model aspects of deployment open access on multimedia message broadcast service in EPS. The open service access allows third-party applications to use broadcast function in the network. The Parlay X Web Services (WS) model provides a high level of abstraction of communication network functions and it facilitates the development of value added applications.
The paper is organized as follows. In Section 2, the related work is presented and the novelty of the proposed approach is highlighted. In Section 3, the broadcast service architecture in EPS is discussed where the Broadcast Multicast Service Centre (BMSC) mediates between third-party applications and the network infrastructure. Next, the Parlay X Message Broadcast WS functionality is analyzed in Section 4. The behavior of BMSC is modeled by formal descriptions of MBMS session state and message broadcast status in Section 5. In Section 6, it is proved that models considering QoS and charging aspects of MBMS are synchronized. The conclusion summarizes the contribution.
2. Related Work
Research community has studied different architectural aspects of MBMS deployment in next generation networks. In [3], the authors propose service architecture for efficient content delivery based on enhanced MBMS in LTE (Long-Term Evolution), which reduces backhaul traffic. A context-aware architecture for social networking multimedia distribution, which enhances the evolved MBMS systems by adding users’ situation knowledge on their assessments and allows personalized services delivery over optimized networks, is proposed in [4]. In [5], the authors describe the design and implementation of an open-source virtualized platform that supports both LTE broadcast services and video streaming services and analyze service performance.
The performance of enhanced MBMS in LTE has been thoroughly examined in previous research works. A comparison of multicast/broadcast services support in LTE-advanced and WiMAX IEEE 802.16m is provided in [6]. Challenges in supporting multicast services over LTE with particular attention to resource management, considered as key aspects for efficient provisioning of MBMS services over cellular networks, are analyzed in [7]. In [8], the authors discuss the relationship between LTE evolved MBMS and next generation broadcast television and propose some recommendations aimed at improving efficiency of the respective systems. In [9], the authors present a compact, convenient model for broadcasting in LTE, as well as a set of efficient algorithms to define broadcasting areas and to actually perform content scheduling. A joint multicast/unicast scheduling strategy for MBMS delivery, which improves QoS performance, is proposed in [10]. In [11], the authors propose a method for forming broadcasting area and assignment of content to them so that radio resources are efficiently exploited and user requests satisfied. In [12], a distributed resource allocation scheme is proposed, which includes device-to-device communication broadcasting groups and minimizes interference relationships. In [13], MBMS with inherently low requirement for network resources as a candidate solution for using such resources in a more efficient manner is proposed. High level considerations related to implementation of a session controller, supporting application programming interfaces for message broadcasting/multicasting, can be found in [14].
The proposed solutions have to be implemented by the telecom network operator. We study another multimedia broadcasting issue that has been scarcely addressed so far, namely, third-party control which allows external applications outside the network to control service provisioning. Our research is focused on two standardized technologies whose synergy has not been studied to date. The Parlay X WS is technology aimed at providing a horizontal service architecture which may be shared by different applications. It defines highly abstracted technology neutral application programming interfaces (APIs). Integration of MBMS and Parlay X requires translation of high level interfaces into telecommunication control protocols. The innovative approach to efficient MBMS provisioning requires considering also other advanced network functions such as policy-based quality of service control and flexible charging. We examine how three different functions in EPS, related to multimedia broadcasting, policy and charging control, and third-party control can collaborate and take the advantage of network convergence in provisioning of value added services.
3. Broadcast Service Architecture in EPS
Different broadcast business cases may be considered and the relevance of each used case is up to network operators and their relationship with the content owners, agencies, and broadcasters. Used case examples include mobile TV, digital radio, video on demand, electronic magazines and newspapers, and configuration and management of intelligent objects with internet connectivity.
As to 3GPP TS 23.246, the components of the 3GPP solution of MBMS are MBMS bearer service and MBMS user service. The MBMS bearer service enables efficient distribution of content to multiple users while MBMS user service is used by user devices when specific end user applications are activated. The architecture of MBMS for EPS with the proposed third-party control is depicted in Figure 1.
The multimedia content that has to be broadcasted is provided by an Application Sever (AS). The MBMS AS may be deployed by network operator or third-party application provider. The Broadcast Multicast Service Centre (BMSC) stores multimedia content to be transmitted, controls the multimedia broadcast service, and interacts with media sources and the end users’ devices via Packet Data Network Gateway (PDN GW). It provides interfaces for both signaling and data transfer to the MBMS GW. The MBMS Gateway (GW) distributes the data received from the BMSC to the relevant base stations in the access network. The Mobility Management Entity (MME) communicates with the access network in the concerned area, relaying session control information received by MBMS GW [15].
The end users discover the available MBMS services by service announcement, which provides information about services. Service announcement is used to distribute to users information about MBMS, service activation parameters like IP multicast address, and service start time. Service announcement mechanisms may include short message broadcasting, MBMS broadcasting or multicasting mode, and a push mechanism. Service announcement details may be found in [16].
An MBMS service may contain multiple distinct multimedia streams and it is provided by session setup and termination. Each session is bundled with bearer establishment and release. Signaling procedures related to MBMS session initiation, update, and termination are specified in [15].
In EPS, the network controls QoS parameters for session broadcast MBMS bearer services. QoS Class Identifier, Allocation and Retention Priority, Maximum Bit Rate (MBR), and Guaranteed Bit Rate (GBR) are applicable to MBMS bearer service, where the MBR is set to be equal to the GBR. The QoS management in EPS is provided by means of policy and charging control (PCC) which allows network operator to authorize and control the usage of resources intended for multimedia traffic [17]. PCC ensures that multimedia services are provided with appropriate transport and charging. The Policy and Charging Rule Function (PCRF) encompasses policy control decision and flow based charging control functions. It receives MBMS session information from BMSC as well as information from the access network and makes policy-based decisions about bearer service session, which are then provided to the MBMS GW. The PCC decisions determine the QoS treatment of the bearer traffic.
Both MBMS content provider and MBMS user may be charged for multimedia broadcasting sessions. EPS provides offline and online charging mechanisms [18]. The BMSC contains triggers that generate events for online and offline charging. The Online Charging System (OCS) performs real-time credit control and its functionality includes transaction handlings, online correlation, and management of user account balances. The Charging Data Function (CDF) receives offline charging information from BMSC and creates call detail records.
4. Parlay X Message Broadcast Web Service
The Parlay X Message Broadcast WS (MBWS) allows third-party applications to send messages to end user devices in a specific geographical area [19]. It provides APIs for sending a broadcast message to the network, for monitoring the delivery status of a sent broadcast message, and for notifications about the message delivery status.
The sendBroadcastMessage operation is used to send a broadcast message into the designated area(s).
The getBroadcastStatus operation is used by the 3rd-party application to retrieve the status of sent broadcast message. The broadcast status values are as follows:(i)MessageWaiting. The message is still queued and not delivered to the network yet.(ii)Broadcasting. The message is being broadcasted as many as requested in the send operation.(iii)Broadcasted. The message is successfully delivered to network as many as requested.(iv)BroadcastImpossible. This indicates a final state that delivery of broadcast message is impossible due to specific reasons.(v)BroadcastUnknown. The message delivery state is unknown.Figure 2 illustrates the MBMS time line and the message status as seen by 3rd-party application. The cancelBroadcastMessage operation may be used by the third-party application to cancel message broadcasting. The operation affects the subsequent broadcast message delivery.
The notifyBroadcastDeliveryReceipt operation is used to notify the third-party application about the delivery status of the message. In order to receive notification the third-party application needs to start notifications using startDeliveryReceiptNotification operation. The application may end the receipt of notifications using the stopDeliveryReceiptNotification operation.
We propose a modified model compared to that presented in [19], which is shown in Figure 3. In Null state, there is no message to be broadcasted. As far as the BroadcastUnknown state is of temporary kind it is absorbed by the BroadcastImpossible and Broadcasting states.
5. Model Aspects of Broadcast Multicast Service Centre
5.1. Modeling Views on Message Broadcast
BMSC needs to communicate with the third-party application using the Parlay X MBWS. Toward the network, BMSC has to communicate with MBMS GW to maintain the MBMS session; PCRF to provide information about the MBMS session and to receive notifications about bearers authorized for the session; and CDF to send charging data. Therefore, the BMSC behavior has to be synchronized with the behavior of MBMS GW, PCRF, and CDF, and its view on the MBMS session has to be synchronized with the application view on the state of message broadcast. MBMS GW is in charge of establishment of IP-CAN resources for the MBMS session where IP-CAN stands for Internet Protocol Connectivity Access Network. PCRF controls the QoS that has to be assured for the MBMS session and CDF gathers charging data.
Figure 4 shows the respective state models that have to be synchronized with the BMSC behavior. The BMSC has to transform the MBWS operations and to control the MBMS session appropriately. In practice, the state models of BMSC, MBMS GW, PCRF, and CDF should expose direct correspondence between the transitions and the information they provide; that is, they have to expose equivalent behavior.
The MBMS session state model describes the states of the MBMS session and it is maintained by MBMS GW. The MBMS QoS provisioning requires an MBMS QoS state model reflecting the state of bearer resources allocated by PCRF for the broadcast session. The control protocol used for PCC is Diameter. Similar considerations are applied to the MBMS charging model which holds the states of the MBMS charging session. The control protocol used for charging is also Diameter.
Typical information flows related to multimedia message broadcasting with MBMS session establishment, QoS resource authorization, notification about message broadcast status, and reporting offline charging data are shown in Figure 5.
The MB WS can be used for remote management of intelligent devices like smart meters, which are uniquely identified, gather information from their environment, and communicate that information with network applications. Remote entity management provides means for managing device life cycle including software and firmware upgrade and configuration management. With the increasing number of connected devices, the device management becomes cumbersome and costly for the device operator. So, an EPS operator can sell the MBMS to the device operator to keep the fleet updated. The MBMS can deliver all the software and firmware updates as well as configurations needed to manage the devices up to date.
It is a general assumption that IP connectivity is provided to all devices, which means that for each device there is an established default bearer. Let us assume that the device operator makes use of a message broadcast application. By using the application, the device operator sets the target area, where the devices are deployed, and writes a message with configuration data. Then the message broadcast application invokes the MB WS which in turn sends a message delivery operation to the BMSC. Subsequently EPS functional entities supporting MBMS deliver the configuration data to all devices in the target area.
When the message broadcast application invokes sendBroadcastMessage operation the BMSC opens a Diameter session with the PCRF for the multimedia broadcast session and provides the required session information. The BMSC can subscribe to QoS events related to MBMS bearer resources. The BMSC performs the MBMS session start procedure. The MBMS GW in turn indicates to the PCRF that an IP-CAN session modification is required and waits for PCC rules. Based on session information, the PCRF performs session authorization and sends an acknowledgement with the PCC decisions to the MBMS Gateway. The MBMS starts resources reservation in the access network. When the IP-CAN session modification is completed the MBMS GW sends acknowledgement to the PCRF. The BMSC waits for resource authorization and reservation during the initial protection period and the message broadcast status is MessageWaiting. Before starting the MBMS data transfer, the BMSC contacts with the CDF in order to provide charging information. The MBMS content is sent by the BMSC to the MBMS gateway, and then to the respective part of access network. During the MBMS data transfer the message broadcast status is Broadcasting. The broadcasted content is received and decoded by the devices (user equipment) that are authorized to join the MBMS service. Using the message broadcast application and the interfaces of the MBWS, the device operator can subscribe for notifications about message delivery (startDeliveryReceiptNotification operation) and be notified of a broadcast delivery status of a specific area. Once the MBMS data (configuration data) are broadcasted, the BMSC starts the procedure for session termination, which is followed by release of bearer resources authorized for the MBMS session. The BMSC contacts with the CDF to write the charging data. The message broadcast status becomes Broadcasted. The stopDeliveryReceiptNotification operation is used to end delivery receipt notification. The content provider is charged for the broadcasted content. The PCRF enables also QoS-based charging. The PCC mechanism supports traffic plane event reporting (e.g., bearer lost) which may reflect in charging. In case of active subscription, the PCRF may notify the BMSC about any QoS events occurring during message broadcasting.
In the course of service provisioning, the BMSC needs to maintain in a synchronized manner three state machines describing the MBMS session, QoS resources authorized for the session, and charging session. These state machines have to be synchronized with the application view on the states of the message broadcast.
On receiving an indication about IP-CAN session modification, the PCRF may reject the requested modification (due to overloading in the respective access network or spending credit limits of the content provider in case of online charging). In this case, the PCRF rejects the IP-CAN session modification requested by the MBMS GW and notifies the BMSC about the event during the initial protection period. The message broadcast status becomes BroadcastImpossible. During message waiting or broadcasting, the device operator may decide to cancel message broadcast. In this case, the third-party application invokes the cancelBroadcastMessage operation to request cancelation of the previous sendBroadcastMessage. The BMSC in turn initiates session termination toward the MBMS GW and PCRF, which results in IP-CAN session termination and release of QoS resources.
In the next subsection, we provide formal description of the models representing the view on message broadcast of third-party application, BMSC, MBMS GW, PCRF, and CDF, respectively. This will be used to prove formally that the models are synchronized.
5.2. Formal Description of Models Representing Message Broadcast Status
Let us present the state machines as labeled transition systems (LTS).
Definition 1. A labeled transition system (LTS) is a quadruple (), where is countable set of states, is a countable set of elementary actions, is a set of transitions, and is the set of initial states.
5.2.1. Application View on Message Broadcast Status
The message broadcast status from application point of view may be Null, MessageWaiting, Broadcasting, or Broadcasted. The status is Null when there is no message to be broadcasted. The status is MessageWaiting if the message is waiting to be delivered to the network. The status is Broadcasting or Broadcasted if the MBMS data transfer is ongoing or terminated, respectively.
By an LTS representing the 3rd-party view on the message broadcast status is denoted where(i)Null, MessageWaiting, Broadcasting, Broadcasted, BroadcastImpossible};(ii)sendMessage, getBroadcastStatus, notifyBroadcastDeliveryReceipt, cancelMessage, successfulDelivery, unsuccessfulDelivery, stopAnnouncement, unableToDeliver, successfulMessageCompletion};(iii) Null sendMessage MessageWaiting, MessageWaiting getBroadcastStatus MessageWaiting, MessageWaiting unsuccessfulDelivery Null, MessageWaiting successfulDelivery Broadcasting, MessageWaiting cancelMessage Null, MessageWaiting unableToDeliver BroadcastImpossible, Broadcasting successfulMessageCompletion Broadcasted, Broadcasting cancelMessage Null, Broadcasting getBroadcastStatus Broadcasting, Broadcasted stopAnnouncement Null, Broadcasted getBroadcastStatus Broadcasted, Broadcasted notifyBroadcastDeliveryReceipt Broadcasted, BroadcastImpossible getBroadcastStatus BroadcastImpossible, BroadcastImpossible notifyBroadcastDeliveryReceipt BroadcastImpossible, BroadcastImpossible stopAnnouncement Null};(iv)Null}.The getBroadcastStatus and notifyBroadcastDeliveryReceipt operations do not change the session state or message broadcast status.
5.2.2. BMSC Model of MBMS Session
The simplified BMSC view on the MBMS session states includes the following states. In MBMSIdle state, there is no MBMS session. When the application invokes the sendBroadcastMessage operation, the BMSC sends session information to the PCRF, a session start request to the MBMS GW, and it moves to InitialWaiting state. While being in InitialWaiting state, the BMSC waits for resource authorization and QoS resource reservation. The time delay between a session start indication and actual data should be long enough for the required network actions. When the network is ready to send MBMS data, the BMSC sends charging data and moves to DataTransfer state. In DataTransfer state, MBMS data are transferred to any user equipment which is present. When the MBMS user service determines that there are no more data to send, the BMSC initiates session termination, sends charging data, and moves to MBMSIdle state. In InitialWaiting or DataTransfer state, the BMSC may be notified about any problems related to MBMS bearers and the MBMS session is terminated. It is also possible for third-party application to invoke the cancelBroadcastMessage operation while the BMSC is in InitialWaiting or DataTransfer state, which cancels the MBMS session.
By an LTS representing the BMSC view on the message broadcast status is denoted where(i)MBMSIdle, InitialWaiting, DataTransfer};(ii)sendBroadcastMessage, initialPeriod, dataTransferStop, resourceFailed, resourceLost, cancelBroadcastMessage};(iii)MBMSIdle sendBroadcastMessage InitialWaiting, InitialWaiting initialPeriod DataTransfer, InitialWaiting resourceFailed MBMSIdle, InitialWaiting cancelBroadcastMessage MBMSIdle, DataTransfer dataTransferStop MBMSIdle, DataTransfer resourceLost MBMSIdle}; DataTransfer cancelBroadcastMessage MBMSIdle};(iv)MBMSIdle}.Figure 6 illustrates the MBMS session state machine.
5.2.3. MBMS GW Model of IP-CAN Session
The MBMS GW view on the IP-CAN session states for the MBMS user service includes the following states. In IPCANIdle state, there is no dedicated IP-CAN session. On receiving session start instructions, the MBMS GW indicates an IP-CAN session modification to the PCRF and moves to WaitForPCCRules state. In WaitForPCCRules state, the MBMS waits for authorization of IP-CAN session modification. Upon receiving the PCC rules, the MBMS GW initiates IP-CAN session establishment in the access network and moves to ResourceReservation state. The MBMS GW moves to SessionActive state after it receives an acknowledgement that the resources in the access network are reserved. The transition to ResourceRelease state occurs when a session stop request is received by the BMSC. In ResourceRelease state, the MBMS waits for the release of IP-CAN bearers. In WaitForTermAck state, the MBMS GW waits for acknowledgement for session termination from PCRF and then moves to the initial IPCANIdle state. In ResourceReservation or SessionActive state, network, the MBMS GW may receive indications from the PCRF that the bearer modification fails or that the bearers are lost. These cause the transition to IPCANIdle state.
By an LTS representing the MBMS GW view on the MBMS IP-CAN session state is denoted where(i)IPCANIdle, WaitForPCCRules, ResourceReservation, SessionActive, ResourceRelease, WaitForTermAck};(ii)sessionStart, pccRules, ipCanBearerEstablishment, sessionStop, sessionCancel, ipCanBearerRelease, ipCanSessionTermAck, ipCanBearerFailed, ipCanBearerLost};(iii)IPCANIdle sessionStart WaitForPCCRules, WaitForPCCRules pccRules ResourceReservation, WaitForPCCRules sessionCancel IPCANIdle, ResourceReservation ipCanBearerEstablishment SessionActive, ResourceReservation sessionCancel IPCANIdle, ResourceReservation ipCanBearerFailed IPCANIdle, SessionActive sessionCancel ResourceRelease, SessionActive sessionStop ResourceRelease, SessionActive ipCanBearerLost IPCANIdle, ResourceRelease ipCanBearerRelease WaitForTermAck, WaitForTermAck ipCanSessionTermAck IPCANIdle};(iv)IPCANIdle}.The IP-CAN session state machine is depicted in Figure 7.
5.2.4. PCRF Model of MBMS QoS Resources
The PCRF view on the state of QoS resource intended for MBMS session is as follows. In ResourceNull state, no QoS resources are authorized for the MBMS session. When the BMSC sends session information, the PCRF performs session binding which takes into account the IP-CAN parameters and moves to IPCanSession state storing this information. In IPCanSession state, the PCRF may receive an indication about IP-CAN session modification and correlates appropriate service information with IP-CAN session. In ResourceAuthorizing state, the PCRF makes policy decisions and sends them as PCC rules to the MBMS GW. On receiving provision acknowledgement the PCRF moves to ResourceAuthorized state. The QoS resources for the MBMS session are authorized and reserved, and the MBMS data transfer can start. When the MBMS GW detects that the IP-CAN session termination is required, it sends an indication to the PCRF. In case of subscription, the PCRF may find the PCC rules that require the BMSC to be notified and sends a notification. The QoS resources authorized for the MBMS session are released which causes the transition to ResourceNull state. In ResourceAuthorizing state, the PCRF may decide to reject the IP-CAN session modification. Also, during MBMS data transfer any QoS problems may be reported by the MBMS GW to the PCRF, thus affecting the online charging. In case the MBMS GW reports that all bearer resources authorized for the MBMS session are lost, the PCRF moves to ResourceNull state.
By an LTS representing the PCRF GW view on the QoS resource state is denoted where(i)ResourceNull, IPCanSession, ResourceAuthorizing, ResourceAuthorized};(ii)sessionInfo, ipCanSessionModification, provisionAck, provisionNonAck, ipCanSessionTermination, ipCanBearerRemoved, ipCanSessionCancel};(iii)ResourceNull sessionInfo IPCanSession, IPCanSession ipCanSessionModification ResourceAuthorizing, IPCanSession ipCanSessionTermination ResourceNull, ResourceAuthorizing provisionAck ResourceAuthorized, ResourceAuthorizing ipCanSessionCancel ResourceNull, ResourceAuthorizing provisionNonAck ResourceNull, ResourceAuthorized ipCanSessionCancel ResourceNull, ResourceAuthorized ipCanBearerRemoved ResourceNull};(iv)ResourceNull}.Figure 8 illustrates the QoS resource state machine.
5.2.5. MBMS Charging Session Model
Both offline and online charging are possible. By applying policy and charging control on MBMS sessions, online charging can reflect the QoS experience during message broadcasting. The BMSC collects charging data such as identification of the content source, type of user service, type of bearer resources used to deliver the content broadcast, and identification of users receiving the service. The BMSC collects also charging data such as session duration, data transfer time, and data volume for mobile users receiving the service through MBMS and/or content providers delivery of the MBMS content. The triggers for charging data are bearer service initiation and termination. In ChargingIdle state, no charging data are gathered. Charging data are provided by the BMSC upon MBMS session initiation, IP-CAN bearer resource establishment/failure, and MBMS session termination. The charging data are sent to the CDF (in case of offline charging) or to the Online Charging System. On receiving charging data related to session start, the charging session moves to state. In state, when charging data for IP-CAN session establishment are received, the charging session moves to state. The charging data stop instructions may be received due to normal completion of message broadcast, due to some problems in the network, or due to message broadcast cancelation by the third-party application. On receiving charging data stop instructions the charging session moves to ChargingIdle state.
By an LTS representing the charging session states is denoted where(i)ChargingIdle, Activ, Activ;(ii)chargingDataStar, chargingDataStar, chargingDataSto, chargingDataSto, chargingDataSto;(iii)ChargingIdle chargingDataStar Activ, Activ chargingDataStar Activ, Activ chargingDataSto ChargingIdle, Activ chargingDataSto ChargingIdle, Activ chargingDataSto ChargingIdle, Activ chargingDataSto ChargingIdle Activ chargingDataSto ChargingIdle};(iv)ChargingIdle}.The charging session state machine is depicted in Figure 9.
Having formal description of the models representing message broadcast status as seen by both the third-party application and the network, we can prove that these models are synchronized; that is, they expose equivalent behavior.
6. Formal Verification of Models
6.1. Bisimilarity Concept
Intuitively, in terms of observed behavior, two state machines are equivalent if one state machine displays a final result and the other state machine displays the same result. The idea of equivalence is formalized by the concept of bisimilarity [20]. Strong bisimilarity requires existence of homomorphism between transitions in both state machines. In practice, strong bisimilarity puts strong conditions for equivalence which are not always necessary. For example, internal transitions can present actions, which are intrinsic to the system (i.e., not observable). In weak bisimilarity, internal transitions can be ignored.
The concept of weak bisimilarity is used to study some model aspects of BMSC.
We will use the following notations:(i) stands for the transition ;(ii) means that ;(iii), where , such that ;(iv) means that , such as ;(v) means if or , otherwise,where is one or more internal (invisible) actions.
Definition 2. Two labeled transition systems and are weakly bisimilar ( if there is a binary relation such that if and , then :(i) implies and ;(ii) implies and .So in order to prove that considered LTS expose equivalent behavior, it is necessary to identify a relation between their states that satisfies the above conditions.
6.2. Equivalence of Models Representing Message Broadcast Status
6.2.1. Behavioral Equivalence between Models of IP-CAN Session and QoS Resources
It can be shown that the MBMS GW model of MBMS session and PCRF model of MBMS QoS resources provide the lower level of abstraction, so we will start with considering the synchronization aspects of these models.
Proposition 3. The labeled transition systems and are weakly bisimilar.
Proof. To prove the bisimilarity between two labeled transition systems, it has to be proved that there exists a bisimilar relation between their states. By a relation between the states of and is denoted where (IpCANIdle, ResourceNull), (WaitForPCCRules, IpCanSession), (ResourceReservation, ResourceAuthorizing), (SessionActive, ResourceAuthorized)}.The following homomorphism based on functional mapping may be defined between transitions of and : sessionStartsessionInfo); pccRuleipCanSessionModification); ipCanBearerEstablishmentprovisionAck); sessionStopipCanSessionTermination); sessionCancelipCanSessionCancel); ipCanBearerFailedprovisionNonAck); ipCanBearerLostipCanBearerRemoved).The homomorphism between the and messages shows the action’s similarity.
Table 1 represents the functional mapping between the transitions in the IP-CAN session state machine and transitions in the QoS resources state machine.
Based on the established relation between the states of and , and on the homomorphism between their transitions, it is proved that ; that is, they are weakly bisimilar and expose equivalent behavior.
6.2.2. Equivalence of Models of MBMS Session, IP-CAN Session, and QoS Resources
A higher level of abstraction on the network resource state for MBMS is provided by the state of MBMS session.
Proposition 4. The labeled transition systems , , and are weakly bisimilar.
Proof. The weak bisimilarity has the property transitivity; that is, as a relation it is transitive. Then, having proved that , it has to be proved that .
By a relation between the states of , , and is denoted where (MBMSIdle, IpCANIdle), (InitialWaiting, WaitForPCCRules), (DataTransfer, SessionActive)}.The following homomorphism based on functional mapping may be defined between transitions of , , and : sendBroadcastMessage(sessionStartsessionInfo); initialPeriodpccRuleipCanSessionModification); dataTransferStopsessionStopipCanSessionTermination); cancelsessionCancelipCanSessionCancel); resourcesFailed(ipCanBearerFailedprovisionNonAck); resourcesLostipCanBearerLostipCanBearerRemoved).The functional mapping between the transitions in the MBMS session and IP-CAN state machines represented in Table 2 shows that is a bisimilar relation.
From the homomorphism and bisimilar property of it follows that .
From the bisimulation transitivity it follows that .
This means that MBMS session state machine, IP-CAN state machine, and the QoS resources state machine are weakly bisimilar.
6.2.3. Equivalence of Application and Network Models
The highest level of abstraction on message broadcast status is provided by 3rd-party application. Its view has to be synchronized also with the network resource state and charging session state.
Proposition 5. The labeled transition systems , , , , and are weakly bisimilar.
Proof. By a relation between the states of , , , , and is denoted where (Null, MBMSIdle, IpCANIdle, ResourceNull, ChargingIdle), (MessageWaiting, InitialWaiting, WaitForPCCRules, IpCanSession, Activ), (Broadcasting, DataTransfer, SessionActive, ResourceAuthorized, Activ)}.The following homomorphism based on functional mapping may be defined between transitions of , , , , and : sendMessagesendBroadcastMessagesessionStartsessionInfosendBroadcastMessagechargingDataStar); successfulDeliveryinitialPeriodpccRuleipCanSessionModificationchargingDataStar; successfulMessageCompletiondataTransferStopsessionStopipCanSessionTerminationchargingDataSto); cancelMessagecancelsessionCancelipCanSessionCancelchargingDataSto); unsuccessfulDeliveryresourcesFailedipCanBearerFailedprovisionNonAckchargingDataSto.In order to define a weak bisimilar relation between the states of , , , , and we establish the valid sequences of ordered transitions from - , - , - , - , and - that correspond to .
Let , where , be the following transition sequences: Null sendMessage MessageWaiting); MessageWaiting getBroadcastStatus MessageWaiting, MessageWaiting successfulDelivery Broadcasting); Broadcasting getBroadcastStatus Broadcasting, Broadcasting successfulMessageCompletion Broadcasted, Broadcasted getBroadcastStatus Broadcasted, Broadcasted notifyBroadcastDeliveryReceipt Broadcasted, Broadcasted stopAnnouncement Null); MessageWaiting unableToDeliver BroadcastImpossible, BroadcastImpossible getBroadcastStatus BroadcastImpossible, BroadcastImpossible notifyBroadcastDeliveryReceipt BroadcastImpossible, BroadcastImpossible stopAnnouncement Null); MessageWaiting cancelMessage Null); Broadcasting cancelMessage Null).Let , where , be following transition sequences: MBMSIdle sendBroadcastMessage InitialWaiting); InitialWaiting initialPeriod DataTransfer); DataTransfer dataTransferStop MBMSIdle); InitialWaiting resourceFailed MBMSIdle); InitialWaiting cancelBroadcastMessage MBMSIdle); DataTransfer resourceLost MBMSIdle).Let , where , be the following: IPCANIdle sessionStart WaitForPCCRules); WaitForPCCRules pccRules ResourceReservation, ResourceReservation ipCanBearerEstablishment SessionActive); SessionActive sessionStop ResourceRelease, ResourceRelease ipCanBearerRelease WaitForTermAck, WaitForTermAck ipCanSessionTermAck IPCANIdle); ResourceReservation ipCanBearerFailed IPCANIdle); WaitForPCCRules sessionCancel IPCANIdle, ResourceReservation sessionCancel IPCANIdle); SessionActive ipCanBearerLost IPCANIdle).Let , where , be the following: ResourceNull sessionInfo IPCanSession); IPCANSession ipCanSessionModification ResourceAuthorizing, ResourceAuthorizing provisionAck ResourceAuthorized); ResourceAuthorized ipCanSessionTermination ResourceNull); ResourceAuthorizing provisionNonAck ResourceNull); IPCANSession ipCanSessionCancel ResourceNull, ResourceAuthorized ipCanSessionCancel ResourceNull); ResourceAuthorized ipCanBearerRemoved ResourceNull).Let , where , be following transition sequences: ChargingIdle chargingDataStar Activ); Activ chargingDataStar Activ); Activ chargingDataSto ChargingIdle); Activ chargingDataSto ChargingIdle); Activ chargingDataSto ChargingIdle); Activ chargingDataSto ChargingIdle).Then, based on the defined homomorphism between the actions of , , , , and , it follows that for the sequences for agree with Definition 2 for weak bisimilarity.
Hence, the state machines that represent the 3rd-party application view on message broadcast, MBMS session, IP-CAN session, QoS resources, and charging session are bisimilar; that is, these state machines expose equivalent behavior.
7. Conclusion
In EPS there are specific features, nodes, and interfaces defined to support broadcasting of content to multiple users simultaneously. Parlay X Message Broadcast WS allows third-party applications to send messages to all mobile terminals in a specific geographical area. The deployment of 3rd-party control on multimedia broadcasting implies more research on synergy between WS APIs and respective communication control protocols.
The paper presents a study on modeling aspects of a network node that mediates between 3rd-party application servers and the evolved packet core of a mobile network. It explores the way the network agnostic WS interfaces collaborate with specific control functionality in order to provide value added multimedia broadcasting services.
The results regard model aspects of the behavior of a Service Capability Server, namely, BMSC, which exposes Parlay X WS interfaces toward applications and “talks” network protocols toward the network. The focus is on collaboration of different functionalities, namely, service control, session management, QoS control, and charging control. In the context of message broadcast, we modeled the states of MBMS session, IP-CAN session, QoS resources, and charging session and showed that these models are synchronized with the 3rd-party application view on message broadcast. The proof is based on functional mapping between the transitions in state machines and the identification of a homomorphism between actions. The concept of weak bisimilarity is used to prove that the state machines expose equivalent behavior. Thus, the novelty of contribution might be summarized as model definitions and proof for bisimilarity.
The utilization of standardized Message Broadcast APIs provides a unified approach for 3rd-party application management and provisioning. It allows development of converged multimedia broadcast applications in a way which is independent of the underlying access technologies.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.