WO2015144196A1

WO2015144196A1 - Solution for critical communication security based on mbms security

Info

Publication number: WO2015144196A1
Application number: PCT/EP2014/055818
Authority: WO
Inventors: Anja Jerichow; Rainer Liebhart
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2014-03-24
Filing date: 2014-03-24
Publication date: 2015-10-01

Abstract

The present invention provides apparatuses, methods, computer programs, computer program products and computer-readable media regarding solution for critical communication security based on MBMS security. Certain aspects of the present invention include receiving data packets and an indication regarding application of security functionality from an application server, encrypting the received data packets based on the received indication regarding the application of security functionality, transmitting the encrypted data packets to user equipments using multicast/broadcast, and forwarding the encrypted data packets to the application server from which the data packets and the indication are received.

Description

DESCRIPTION

TITLE

Solution for critical communication security based on MBMS security

Field of the invention

The present invention relates to apparatuses, methods, systems, computer programs, computer program products and computer-readable media regarding solutions for critical communication security based on MBMS (Multimedia Broadcast and Multicast Service) security.

Background of the invention

GCSE (Group Communication Service Enabler) is a service enabler for critical communication in the public safety sector. It is currently under specification in 3GPP (cf. 3GPP TS 22.468 for requirements, TR 23.768 and TS 23.468 for architecture, and the study report TR 33.888 for security). In group communication scenarios, unicast or broadcast/multicast can be used for the delivery of media such as voice/video. In the following "multicast" refers always to "multicast/broadcast".

Multicast/broadcast is reasonable in particular for distribution of the same content to multiple devices in the same areas as this can be done in a fast and efficient way. According to TS 22.468, GCSE should allow flexible modes of operation, e.g. it is expected to support voice, video or, more general, any kind of data communication. Furthermore, a Group Communication Service in LTE (Long Term Evolution) can allow users to communicate to several groups at the same time in parallel. The Group Communication Service Enabler provides modular functions and open interfaces that can be used to design Group Communication Services.

The new entity GCS AS (Group Communication Service Application Server) interfaces with the LTE network to establish unicast connections (where data are delivered via the SGi interface) and to establish multicast/broadcast connections (using the MB2 interface) among group members. In addition application layer signaling between UE (User Equipment) and GCS AS for critical communication takes place over a new GC1 interface. Fig. 1 is a diagram illustrating a non-roaming architecture model for GCSE LTE, as described in TS 23.468, showing the above mentioned entities and interfaces.

GCSE security needs to specify, how data is secured on the unicast uplink, unicast downlink and multicast/broadcast downlink. While the MB2 interface only affects the multicast/broadcast connection, the requirement of service continuity when switching between unicast and multicast/broadcast, or even receiving both in parallel, needs to be fulfilled, which may have additional impact on the MB2 interface, as described in the present application.

According to TS 23.468, group communication over LTE covers the following aspects:

• Group Communication among entitled group members via E-UTRAN

• Group Communication among entitled group members using E-UTRAN and/or ProSe (proximity services) communication paths via a ProSe UE-to-Network Relay

• The relationship between ProSe and GCSE for Group Communication

While public safety networks (e.g. network used by policemen, firemen, etc.) can use their own application server (GCS AS, in the following called AS) for group management, they would like to use a multipoint service functionality within the EPS (Evolved Packet System) network for the efficient distributing of data (e.g. media). The GCSE LTE work item in 3GPP Release 12 has decided that eMBMS (see TS 23.468 for details and further references) is used for this purpose. Thus, the MB2 interface is the interface between GCS AS and BM-SC (Broadcast Multicast Service Center). TS 23.468 also discusses proposals for switching between unicast and multicast/broadcast delivery of data, which has been identified in the scope of 3GPP Rel-12 (see TS 23.468). MB2 consists of both user plane and control plane components.

The eMBMS (cf. TS 22.146, TS 23.246, TS 26.346, and TS 33.246) allows broadcast of multimedia data to users located in a service area. Broadcast can be received by any user of the area in which the service is offered. Security comes into play, if users have subscribed to a particular service. In terms of eMBMS terminology, they have joined a multicast group, i.e. the multimedia data are still received by everybody in the addressed broadcast area, but they can only be understood (decrypted) by members of the multicast group. Details on eMBMS security are described in TS 33.246. The Temporary Mobile Group Identity (TMGI) allocated by the BM-SC uniquely identifies an MBMS (Multimedia Broadcast / Multicast Service) Bearer Service. Members of a TMGI group need to receive a group key MSK (MBMS service key), if the service shall be secured from unauthorized access. It is noted that the AS could use any secure path to distribute a group key similar to the MSK to each member of the group. However, this is out of scope of this application. In the following description, the term MSK will be used although the present invention is not limited thereto.

The MSK can be seen as a long term key for a group service, i.e. it does not change very often. BM-SC uses the MSK to encrypt a short-term key, the MBMS traffic key MTK. MTKs are used for the media encryption. BM-SC sends encrypted media data (encrypted by MTK) together with the encrypted traffic key (encrypted by the MSK) via the MBMS-GW (MBMS- Gateway) to all devices in given the broadcast area.

End-to-end encryption at the GCSE application layer (i.e. between UE and AS) may only be needed in case of critical information to be distributed. In addition, this requires extra encryption on the application layer with increased development costs. In many situations standardized MBMS security could be used to encrypt the media stream, in which case there is a need to have a trust relationship between AS and network operator (including potentially secured links between network operator domain and group call service provider domain).

The problem that is solved with the present invention is to enable flexible network deployments where only application layer security, only MBMS security or a combination of both are used for unicast and multicast/broadcast communication to enable service continuity. Encryption of data (voice, multimedia, etc) is a security function that could be located in the GCS AS, BM-SC or UE depending on the trust relationship between service provider and network operator.

The focus of the present invention is set on the aspect of security related to session continuity, i.e. to allow a UE to switch between unicast and multicast mode for data reception. This requirement is a requirement of GCSE LTE in 3GPP Rel-12 and covered by TS 23.468. It requires a security solution that ensures backward compatibility between Rel- 13 and Rel-12. If MBMS security functionality is used for critical communication, AS needs to indicate this to the BM-SC. BM-SC can then provide the encryption function, but has only the interface towards MBMS GW for multicast/broadcast delivery of data. If all group members shall have the same level of confidentiality and integrity protection as requested by TR 33.888, but the UE does not encrypt the data in uplink (assuming that LTE hop-by-hop security in the uplink is sufficient), AS shall be able to distribute the same encrypted data to all group members via unicast and multicast in order to allow for fast and easy service continuity when a UE moves from unicast to multicast reception and back. To solve this problem, the MB2 interface needs to be defined accordingly.

Current assumption in 3GPP specifications is that the AS takes care of the group management. The MBMS bearer has been pre-established and the BM-SC provides the AS with a TMGI, used over the air interface to identify the broadcast transmission for the Group communication, and optionally a list of Cell ID'S at the boundary of the service area of the broadcast communications.

With this, the application can start sending data to the EPS on the downlink direction via the BM-SC over the MB2-U interface. This interface is simply a user plane interface.

However, no security is considered in this scenario yet.

Solution 9 in TR 23.768 discusses group management and associated UE interaction. In this context, the solution suggests avoiding membership management control at the BM-SC level (i.e., being aware of who is being added or removed to/from a particular GCSE group). Thus, it is proposed that the eMBMS security procedure (TS 33.246) is not used for this purpose. Furthermore, it is proposed that the GCSE media encryption (if required) is provided at the application layer by the GCS AS, and GCS AS is responsible to ensure the removed member will not be able to listen in to the media provided by Mulitcast Delivery (e.g., based on application specific methods). No requirement toward MB2 is needed with this approach.

This scenario assigns all security to the application layer.

TS 23.468 describes information exchanged between GCS AS and BM-SC on the MB2 interface; security is left for stage 3 and 3GPP SA3 (3GPP Service and System Aspect Working Group 3 - Security) is still in the process of defining the security concept (see study report TR 33.888).

Thus, the problem the invention solves has not been addressed yet in 3GPP SA2 or SA3 working groups.

Summary of the Invention

It is therefore an object of the present invention to overcome the above mentioned problems and to provide apparatuses, methods, systems, computer programs, computer program products and computer-readable media regarding solutions for critical communication security based on MBMS security.

According to an aspect of the present invention there is provided a method comprising: receiving, at a multicast service center, data packets and an indication regarding application of security functionality from an application server,

encrypting the received data packets based on the received indication regarding the application of security functionality,

transmitting the encrypted data packets to user equipments using multicast/broadcast, and

forwarding the encrypted data packets to the application server from which the data packets and the indication are received.

According to another aspect of the present invention, there is provided a method comprising: receiving, at an application server, data packets from a first user equipment, forwarding the data packets and an indication regarding application of security functionality to a multicast service center,

receiving, at the application server, encrypted data packets from the multicast service center, and

transmitting the encrypted data packets to second user equipment via unicast.

According to another aspect of the present invention, there is provided an apparatus comprising:

at least one processor, and

at least one memory for storing instructions to be executed by the processor, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus at least to perform

receiving data packets and an indication regarding application of security functionality from an application server,

at least one processor, and

receiving data packets from a first user equipment,

forwarding the data packets and an indication regarding application of security functionality to a multicast service center,

receiving encrypted data packets from the multicast service center, and

transmitting the encrypted data packets to second user equipment via unicast.

According to another aspect of the present invention there is provided an apparatus comprising:

means for receiving, at a multicast service center, data packets and an indication regarding application of security functionality from an application server,

means for encrypting the received data packets based on the received indication regarding the application of security functionality,

means for transmitting the encrypted data packets to user equipments using multicast/broadcast, and

means for forwarding the encrypted data packets to the application server from which the data packets and the indication are received. According to another aspect of the present invention there is provided an apparatus comprising:

means for receiving, at an application server, data packets from a first user equipment,

means for forwarding the data packets and an indication regarding application of security functionality to a multicast service center,

means for receiving, at the application server, encrypted data packets from the multicast service center, and

means for transmitting the encrypted data packets to second user equipment via unicast.

According to another aspect of the present invention there is provided a computer program product comprising code means adapted to produce steps of any of the methods as described above when loaded into the memory of a computer.

According to a still further aspect of the invention there is provided a computer program product as defined above, wherein the computer program product comprises a computer- readable medium on which the software code portions are stored.

According to a still further aspect of the invention there is provided a computer program product as defined above, wherein the program is directly loadable into an internal memory of the processing device.

Brief Description of the Drawings

These and other objects, features, details and advantages will become more fully apparent from the following detailed description of aspects/embodiments of the present invention which is to be taken in conjunction with the appended drawings, in which:

Fig. 1 is a diagram illustrating a non-roaming architecture model for GCSE LTE;

Fig. 2 is a signaling diagram illustrating some examples of data encryption and distribution;

Fig. 3 is a signaling diagram illustrating the principle of re-using the existing security functionalities according to certain aspects of the present invention; Fig. 4 is a block diagram illustrating an example of an implementation of a proxy function within the GCS AS;

Fig. 5 is a flowchart illustrating an example of a method according to example versions of the present invention;

Fig. 6 is a diagram illustrating an example of an apparatus according to example versions of the present invention;

Fig. 7 is a flowchart illustrating another example of a method according to example versions of the present invention;

Fig. 8 is a diagram illustrating another example of an apparatus according to example versions of the present invention.

Detailed Description

In the following, some example versions of the disclosure and embodiments of the present invention are described with reference to the drawings. For illustrating the present invention, the examples and embodiments will be described in connection with a cellular communication network based on a 3GPP based communication system, for example an LTE/LTE-A based system. However, it is to be noted that the present invention is not limited to an application using such type of communication system or communication network, but is also applicable in other types of communication systems or communication networks and the like.

The following examples versions and embodiments are to be understood only as illustrative examples. Although the specification may refer to "an", "one", or "some" example version(s) or embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same example version(s) or embodiment(s), or that the feature only applies to a single example version or embodiment. Single features of different embodiments may also be combined to provide other embodiments. Furthermore, words "comprising" and "including" should be understood as not limiting the described embodiments to consist of only those features that have been mentioned and such example versions and embodiments may also contain also features, structures, units, modules etc. that have not been specifically mentioned.

The basic system architecture of a communication network where examples of embodiments of the invention are applicable may comprise a commonly known architecture of one or more communication systems comprising a wired or wireless access network subsystem and a core network. Such an architecture may comprise one or more communication network control elements, access network elements, radio access network elements, access service network gateways or base transceiver stations, such as a base station (BS), an access point or an eNB, which control a respective coverage area or cell and with which one or more communication elements or terminal devices such as a UE or another device having a similar function, such as a modem chipset, a chip, a module etc., which can also be part of a UE or attached as a separate element to a UE, or the like, are capable to communicate via one or more channels for transmitting several types of data. Furthermore, core network elements such as gateway network elements, policy and charging control network elements, mobility management entities, operation and maintenance elements, and the like may be comprised.

The general functions and interconnections of the described elements, which also depend on the actual network type, are known to those skilled in the art and described in corresponding specifications, so that a detailed description thereof is omitted herein. However, it is to be noted that several additional network elements and signaling links may be employed for a communication to or from a communication element or terminal device like a UE and a communication network control element like a radio network controller, besides those described in detail herein below.

The communication network is also able to communicate with other networks, such as a public switched telephone network or the Internet. The communication network may also be able to support the usage of cloud services. It should be appreciated that BSs and/or eNBs or their functionalities may be implemented by using any node, host, server or access node etc. entity suitable for such a usage.

Furthermore, the described network elements and communication devices, such as terminal devices or user devices like UEs, communication network control elements of a cell, like a BS or an eNB, access network elements like APs and the like, as well as corresponding functions as described herein may be implemented by software, e.g. by a computer program product for a computer, and/or by hardware. In any case, for executing their respective functions, correspondingly used devices, nodes or network elements may comprise several means, modules, units, components, etc. (not shown), which are required for control, processing and/or communication/signaling functionality. Such means, modules, units and components may comprise, for example, one or more processors or processor units including one or more processing portions for executing instructions and/or programs and/or for processing data, storage or memory units or means for storing instructions, programs and/or data, for serving as a work area of the processor or processing portion and the like (e.g. ROM, RAM, EEPROM, and the like), input or interface means for inputting data and instructions by software (e.g. floppy disc, CD-ROM, EEPROM, and the like), a user interface for providing monitor and manipulation possibilities to a user (e.g. a screen, a keyboard and the like), other interface or means for establishing links and/or connections under the control of the processor unit or portion (e.g. wired and wireless interface means, radio interface means comprising e.g. an antenna unit or the like, means for forming a radio communication part etc.) and the like, wherein respective means forming an interface, such as a radio communication part, can be also located on a remote site (e.g. a radio head or a radio station etc.). It is to be noted that in the present specification processing portions should not be only considered to represent physical portions of one or more processors, but may also be considered as a logical division of the referred processing tasks performed by one or more processors.

Unicast Delivery between UE and GCS AS uses p2p (point-to-point) EPS bearers. The EPS bearers are used as described in TS 23.468 for exchanging GC1 signaling between UE and GCS AS, transporting of data on the uplink from UE to the GCS AS and transporting of data on the downlink from GCS AS to UE when MBMS Delivery is not desirable or possible. The GCS AS uses the Rx interface to allocate EPS resources for p2p group communication.

Multipoint Service for GCSE will be based on eMBMS in 3GPP Rel-12. eMBMS has in-built security mechanisms specified. In case of critical communication scenarios the GCSE service itself will most likely not be operated by the telco operator. The GCSE service provider may want to apply security already at the application layer.

MB2 is a new interface that connects the GCSE application with the 3GPP network, i.e. the interface between GCS AS and BM-SC. MB2 is specified in 3GPP SA2 in 3GPP Rel-12 (TS 23.468). Security relevant parts for MB2 are specified in 3GPP SA3 in TR 33.888. Certain aspects of the present invention are about information sent over the MB2 interface to instruct the BM-SC what level of security has been applied by the AS and/or what needs to be done by the BM-SC in terms of security. This allows for flexible deployments where only application layer security, only MBMS security or a combination of both is used. In general, a split of security functions may be possible, but from a security point of view it seems more appropriate to apply a complete security solution by either of the layers (AS or MBMS). That is, if end-to-end encryption is used, GCS AS needs to indicate to the BM-SC that security has already been applied. If GCS AS has applied encryption for the downlink communication it needs to indicate this as well. If the AS does not demand end-to-end encryption, but still would like the BM-SC to protect the data on behalf of the AS, it needs to indicate this to the BM-SC.

Fig. 2 is a signaling diagram illustrating some examples of data encryption and distribution in connection with the options mentioned below.

There are the following options for encryption of data:

1. UE encrypts data in the unicast uplink to the AS. As shown in Fig. 2 (a), the UE sends SRTP (Secure Real-Time Transport Protocol) packets to the GCS AS in step S21 and the GCS AS sends encrypted data in step S22 to the BM-SC indicating that no security function is needed from MBMS. Further, the AS provides the same data via unicast to group members in step S23.

In this case the AS distributes via unicast and/or multicast/broadcast an encrypted data package to all group members. No additional security except the securing of the GC1 and GC2 interface is needed.

2. AS encrypts data received in UL by an UE before distribution via multicast.

In this case it is assumed that LTE security is sufficient for unicast (uplink and downlink) delivery and only the multicast delivery needs to be encrypted. As shown in Fig. 2(b), the UE sends media/data packets to the GCS AS in step S24, and after encryption by the GCS AS, the GCS AS distributes the encrypted SRTP packets per multicast in step S25.

3. AS encrypts data received by an UE before distribution via multicast and unicast. In this case, the distribution of the SRTP packets per unicast is illustrated in step S26 in Fig. 2(b). With this solution the same security level regardless of unicast or multicast delivery to group members or the transition between both for one group member is achieved. Note, in this case the GCSE provider assumes that unicast uplink is sufficiently protected by LTE hop-by-hop security.

4. MBMS security functionality is re-used (and requested by AS). In this case, BM-SC would provide the encryption of data. Certain aspects of the present invention describe methods for this option in relation to option 3.

Thus, according to certain aspects of the present invention, in order to allow for smooth continuity between multicast and unicast sessions and to enable a fast decryption even if the UE decides to switch between unicast and multicast data reception, it is proposed to implement a centralized security solution that re-uses the standardized MBMS security mechanisms. Thus, it relates to option 4 above. This can be achieved, if the BM-SC protects data for multicast delivery send towards the MBMS GW using MBMS security and provides the same encrypted data via the MB2 interface to the GCS AS for further distribution via p2p links to single UE(s).

According to certain aspects of the present invention, it is proposed that GCS AS indicates to the BM-SC via MB2 (more specifically via MB2-C control plane interface), if it requests the MBMS security function to encrypt data for both multicast and unicast transmission. In that case BM-SC provides data encrypted using MBMS security within a MBMS session to group members via multicast/broadcast and in parallel to the GCS AS for unicast distribution to particular group members.

In order to allow the GCS AS to correlate protected data received from the BM-SC with group members, the BM-SC has also to provide a correlation ID to the GCS AS. This can be e.g. the group ID previously received from the GCS AS or another ID that is negotiated between GCS AS and BMSC. The BM-SC can then establish a user plane tunnel at MB2 (MB2-U) towards the GCS AS for each particular group using the correlation ID. GCS AS forwards data received in this tunnel to all group members where it has a p2p connection established.

Optionally, GCS AS and BM-SC can negotiate specific IP addresses / port numbers where to send data for a particular group. Based on tunnel address or IP addresses / port numbers, the GCS AS is able to correlate an encrypted data stream with a special group and its group members. Certain aspects of the present invention comprise one or several information elements in a communication step via MB2 interface, which indicate to BM-SC what kind of security solution needs to be applied. Furthermore, the data field content that needs to be transferred via MB2 is described as part of this indication mechanism.

According to certain aspects of the present invention, also a new functionality is added to BM-SC: sending data to the GCS AS for processing and further distribution to group members that have chosen to listen to the group communication via unicast without changing anything of the BM-SC MBMS functionality itself.

Aim is not to change standardized MBMS security functions and BM-SC functionality. To keep the MB2 interface with respect to security as simple as possible, GCS AS could resemble an MBMS GW for the purpose of receiving the same data stream like any other MBMS GW and BM-SC just sends data for multicast delivery to the AS. Or GCS AS could resemble a multicast group member, in which case AS would receive the data stream as any other multicast group member.

Certain aspects of the present invention are specifically done for the re-usage of the encryption function of MBMS security for unicast distribution, but should not be limited to this example.

GCS AS could use a similar scheme to request other MBMS-security functions to be re-used by AS.

Fig. 3 is a signaling diagram illustration the principle of re-using the existing security functionalities according to certain aspects of the present invention.

As shown in Fig. 3, the UE sends data packets to the GCS AS in step S31 . Thus, there is unencrypted data on the uplink direction to the GCS AS, but the uplink is protected by LTE security and potentially inter-domain security.

The GCS AS then indicates to the BM-SC that it wants to re-use MBMS security, e.g. the encryption function, and the AS provides the data received from the sending UE in UL together with the group key MSK and the generated TMGI to the BM-SC in step S32. MSK can be generated by AS but shall have a format understood by BM-SC. In addition GCS AS provides a correlation ID to BMSC. This can be the group ID, IP address / port number pairs, MSK ID or any other identifier that allows the AS to identify a certain group.

GCS AS requests to receive the multicast stream, e.g. it requests to be part of the multicast group and receives the stream from a MBMS GW. In another version the GCS AS could implement the part of the MBMS GW that is responsible for reception of the encrypted data.

Then, in step S33, the BM-SC generates the MTKs, uses the MBMS security function, i.e. uses the MSK to encrypt the MTKs (signaling data in key management messages (UDP/MIKEY (User Datagram Protocol / Multimedia Internet Keying))), and uses the MTKs to encrypt the data packets (user data UDP/SRTP) to generate SRTP packets. Then, the BM- SC sends MTK encrypted (SRTP) packets (UDP/SRTP) via the MBMS GWs to all UEs that listen on the broadcast channel in step S34.

According to certain aspects of the present invention, the BM-SC provides the SRTP packets and MIKEY message with MTKs to the GCS AS for distribution to all group members that cannot be reached over broadcast channel. That is, the BM-SC returns to the GCS AS the same SRTP packets as generated for multicast.

That is, in addition to the broadcast functionality, BM-SC provides via MB2 the same UDP/SRTP and UDP/MIKEY packets as generated for multicast delivery together with the correlation ID to the GCS AS in step S35. Furthermore, BM-SC provides the key material in secured form (UDP/MIKEY) to the GCS AS. One option to do this is to establish a tunnel per group from BM-SC to GCS AS (or optionally vice versa).

The GCS AS acts as a proxy function for the received data. Fig. 4 is a block diagram illustrating the proxy function 42 within the GCS AS 41 , if the AS receives the encrypted data packets, e.g. via an imitated MBMS GW function 43. It is noted that according to one possible implementation, when using an imitated GW function, the MB2 interface can be kept as simple as possible. In this way, the BM-SC treats the AS like another MBMS GW. Further, this way it will not create much delay during re-distribution via SGi interface. The proxy function translates the UDP/SRTP packets, i.e. it extracts the UDP payload (i.e. SRTP packets of the multicast stream and MIKEY messages for the related MTKs (UDP a 44 in Fig. 4), and encapsulates new UDP packets for the unicast link (UDP b 45 in Fig. 4). SRTP is not touched, only the UDP part needs to be adapted for unicast delivery. Then GCS AS sends the SRTP and MIKEY packets to all group members to which it has a p2p connection established. Optionally, GCS AS and BM-SC can negotiate specific IP addresses / port numbers where to send the encrypted data for a particular group. The GCS AS forwards the unicast stream to the S/P-GW 46 via a router 47.

Then, in step S36 in Fig. 3, the GCS AS distributes the same SRTP packets that have been distributed per multicast, now per unicast. In this way, the GCS AS can perform a downlink unicast to UEs without multicast connection or that have chosen to use unicast instead of multicast.

In the example described above with respect to Fig. 3, the UE sends unencrypted data packets to the GCS AS in step S31 . However, it is noted that the present invention is not limited thereto. According to certain aspects of the present invention, the UE might also use some encryption mechanisms on the uplink to the GCS AS, which would then protect the final bit on the SGi interface. Even in such a case, the GCS AS may still decide to reuse the MBMS encryption functionality for downlink in both unicast and multicast/broadcast.

It is to be noted that SRTP is only an example of the encryption method and that the present invention is not limited thereto. Thus, also other encryption methods can be used.

According to certain aspects of the present invention, the following information is transferred via the MB2 interface from the GCS AS to the BM-SC:

• MSK, which shall be uniquely identifiable by its Key Domain ID and MSK ID, such that BM-SC can proceed without any delay.

• TMGI or another identifier by which BM-SC can map the group communication to the used TMGI

• Payload for downlink

• Indication whether and what kind of protection is needed (confidentiality, integrity)

• Indication if GCS AS requests the BM-SC to protect data for distribution over unicast.

Further, the expected output from the BM-SC to the GCS AS is as follows:

• Acknowledge reception of message

• Acknowledge the forwarding of MTK protected data to MBMS GW • MBMS protected data, if requested by GCS AS, for distribution over unicast.

According to certain aspects of the present invention, the following advantages are achieved.

MBMS encryption function can be re-used without implementation effort on the BM-SC side, MSK is either generated by AS or requested together with the TMGI from the BM-SC. It is assumed that AS takes care of the key management in 3GPP Rel-12. However, in Rel-13 or later releases, options could also include that the BM-SC takes care of the key management and distribution.

The MB2 interface needs to be newly defined anyway, thus there are minimal efforts for BM- SC: it sends via MB2 the same data to GCS AS as to MBMS GW. The AS does not need to implement any encryption function. Further, AS can re-use the MBMS security. Nevertheless, in this case, AS must implement a function that takes the UDP/SRTP data, extracts the SRTP packets received from BM-SC, encapsulates them in a new UDP stream for unicast delivery, and sends it to all unicast group members. Thus, a proxy in AS can re-use the SRTP part of MBMS security without modification and should be able to do without significant delay.

If the same key hierarchy as in MBMS security is to be used, the UE receiving the SRTP packets over unicast needs to also receive the relevant MTKs. TS 33.246 states "MTK is delivered to the UE using MIKEY over UDP" and specifies that "MIKEY messages transporting MTKs shall be sent using the same IP destination address as the RTP traffic. MIKEY messages shall be transported to UDP port number 2269 specified for MIKEY".

In MBMS, the BM-SC sends UDP/MIKEY message with the relevant MTKs (KEMAC contains one or more Key data payloads) to the same IP destination address as the UDP/SRTP payload.

According to certain aspects of the present invention, BM-SC provides together with the encrypted payload the key material to GCSE AS, which is responsible to process the relevant information and makes it available to group members receiving the data via unicast links. It is a further advantage of certain aspects of the present invention that if UE receives the same SRTP packets and MIKEY messages over unicast and multicast, it may only need to evaluate/process the MIKEY message of either unicast or multicast in order to retrieve the MTKs used for one MSK ID. However, it is noted that unicast signaling would affect GC1 interface.

Transition between unicast and multicast can be done smoothly if the same security mechanisms are used as proposed in the present application, i.e. can move from unicast to multicast/broadcast reception and back while receiving exactly the same encrypted data.

Furthermore, the SA3 requirement, as stated in TR 33.888: "The level of confidentiality and integrity protection provided shall be the same, regardless of whether a unicast or multicast bearer is used, including during transition between the two" is automatically fulfilled.

Existing MBMS security functions can be re-used, without changes to existing 3GPP specifications. Instead providing an own encryption function, the GCS AS re-uses MBMS security. Thus, AS needs only to implement a proxy function translating from UDP/SRTP packets received from BM-SC to UDP/SRTP packets forwarded to UE via unicast links.

In summary, certain aspects of the present invention are related to the information sent over the MB2 interface to instruct the BM-SC what level of security has been applied by the AS and/or what needs to be done by the BM-SC in terms of security. This allows for flexible deployments where only application layer security, only MBMS security or a combination of both is used.

According to certain aspects of the present invention, it is proposed that GCS AS indicates to the BM-SC via MB2 (MB2-C), if it wants to use the MBMS security function "encryption" for multicast and for unicast transmission of data. In that case, BM-SC takes the data provided by AS and encrypts them using MBMS security, then it sends the secured data within a MBMS session to group members via the MBMS GW and in parallel also to the GCS AS for unicast distribution to particular group members. Over the MB2 interface, data send to the AS needs to be tunneled, sent to specific IP addresses / port numbers or marked otherwise, and a proxy in AS prepares the data for re-distribution via unicast. Thus, security functions are implemented only at one place (in BM-SC) and are requested by AS. Unicast and multicast downlink delivery use the same level of security. In the following, a more general description of certain embodiments of the present invention is made with respect to Figs. 5 to 8.

Fig. 5 is a flowchart illustrating an example of a method according to example versions of the present invention.

According to example versions of the present invention, the method may be implemented in a multicast service center, like e.g. a BM-SC, or the like. The method comprises receiving, at a multicast service center, data packets and an indication regarding application of security functionality from an application server in a step S51 , encrypting the received data packets based on the received indication regarding the application of security functionality in a step S52, transmitting the encrypted data packets to user equipments using multicast/broadcast in a step S53, and forwarding the encrypted data packets to the application server from which the data packets and the indication are received in a step S54.

According to example versions of the present invention, the indication includes a service key, a temporary group identity, information on the kind of protection requested, and information whether protected data for unicast is requested.

According to example versions of the present invention, the method further comprises generating, at the multicast service center, a traffic key, encrypting the traffic key based on the service key, and encrypting the received data packets based on the traffic key.

According to example versions of the present invention, the method further comprises forwarding the encrypted traffic key to the application server.

According to example versions of the present invention, the data packets and the encrypted traffic key are forwarded to the application server via a tunnel between the multicast service center and the application server.

Fig. 6 is a block diagram showing an example of an apparatus according to example versions of the present invention. In Fig. 6, a block circuit diagram illustrating a configuration of an apparatus 60 is shown, which is configured to implement the above described aspects of the invention. It is to be noted that the apparatus 60 shown in Fig. 6 may comprise several further elements or functions besides those described herein below, which are omitted herein for the sake of simplicity as they are not essential for understanding the invention. Furthermore, the apparatus may be also another device having a similar function, such as a chipset, a chip, a module etc., which can also be part of an apparatus or attached as a separate element to the apparatus, or the like.

The apparatus 60 may comprise a processing function or processor 61 , such as a CPU or the like, which executes instructions given by programs or the like related to the flow control mechanism. The processor 61 may comprise one or more processing portions dedicated to specific processing as described below, or the processing may be run in a single processor. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors or processing portions, such as in one physical processor like a CPU or in several physical entities, for example. Reference sign 62 denotes transceiver or input/output (I/O) units (interfaces) connected to the processor 61 . The I/O units 62 may be used for communicating with one or more other network elements, entities, application servers, user equipments, terminals or the like. The I/O units 62 may be a combined unit comprising communication equipment towards several network elements, or may comprise a distributed structure with a plurality of different interfaces for different network elements. Reference sign 63 denotes a memory usable, for example, for storing data and programs to be executed by the processor 61 and/or as a working storage of the processor 61 .

The processor 61 is configured to execute processing related to the above described aspects. In particular, the apparatus 60 may be implemented in or may be part of a multicast service center like a BM-SC and the like, and may be configured to perform a method as described in connection with Fig. 5. Thus, the processor 61 is configured to perform receiving data packets and an indication regarding application of security functionality from an application server, encrypting the received data packets based on the received indication regarding the application of security functionality, transmitting the encrypted data packets to user equipments using multicast/broadcast, and forwarding the encrypted data packets to the application server from which the data packets and the indication are received. For further details in this regard, reference is made to the description of the method in connection with Fig. 5.

Fig. 7 is a flowchart illustrating an example of a method according to example versions of the present invention.

According to example versions of the present invention, the method may be implemented in an application server like a GCS AS or the like. The method comprises receiving, at an application server, data packets from a first user equipment in a step S71 , forwarding the data packets and an indication regarding application of security functionality to a multicast service center in a step S72, receiving, at the application server, encrypted data packets from the multicast service center in a step S73, and transmitting the encrypted data packets to second user equipment via unicast in a step S74.

According to example versions of the present invention, the method further comprises receiving, at the application server, a traffic key generated by the multicast service center.

According to example versions of the present invention, the method further comprises preparing multicast/broadcast traffic received from the multicast service center for usage in unicast.

According to example versions of the present invention, preparing the multicast/broadcast traffic comprises extracting the encrypted data packets from a first transmission data stream destined for multicast/broadcast delivery, encapsulating the extracted encrypted data packets into a second transmission data stream destined for unicast delivery, and transmitting the second transmission data stream to the second user equipments via unicast.

Fig. 8 is a block diagram showing an example of an apparatus according to example versions of the present invention. In Fig. 8, a block circuit diagram illustrating a configuration of an apparatus 80 is shown, which is configured to implement the above described aspects of the invention. It is to be noted that the apparatus 80 shown in Fig. 8 may comprise several further elements or functions besides those described herein below, which are omitted herein for the sake of simplicity as they are not essential for understanding the invention. Furthermore, the apparatus may be also another device having a similar function, such as a chipset, a chip, a module etc., which can also be part of an apparatus or attached as a separate element to the apparatus, or the like.

The apparatus 80 may comprise a processing function or processor 81 , such as a CPU or the like, which executes instructions given by programs or the like related to the flow control mechanism. The processor 81 may comprise one or more processing portions dedicated to specific processing as described below, or the processing may be run in a single processor. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors or processing portions, such as in one physical processor like a CPU or in several physical entities, for example. Reference sign 82 denotes transceiver or input/output (I/O) units (interfaces) connected to the processor 81 . The I/O units 82 may be used for communicating with one or more other network elements, entities, multicast service centers, user equipments, terminals or the like. The I/O units 82 may be a combined unit comprising communication equipment towards several network elements, or may comprise a distributed structure with a plurality of different interfaces for different network elements. Reference sign 83 denotes a memory usable, for example, for storing data and programs to be executed by the processor 81 and/or as a working storage of the processor 81 .

The processor 81 is configured to execute processing related to the above described aspects. In particular, the apparatus 80 may be implemented in or may be part of a multicast service center like a BM-SC and the like, and may be configured to perform a method as described in connection with Fig. 7. Thus, the processor 81 is configured to perform receiving data packets from a first user equipment, forwarding the data packets and an indication regarding application of security functionality to a multicast service center, receiving, at the application server, encrypted data packets from the multicast service center, and transmitting the encrypted data packets to second user equipment via unicast. For further details in this regard, reference is made to the description of the method in connection with Fig. 7.

In the foregoing exemplary description of the apparatus, only the units/means that are relevant for understanding the principles of the invention have been described using functional blocks. The apparatus may comprise further units/means that are necessary for its respective operation, respectively. However, a description of these units/means is omitted in this specification. The arrangement of the functional blocks of the apparatus is not construed to limit the invention, and the functions may be performed by one block or further split into sub-blocks.

When in the foregoing description it is stated that the apparatus (or some other means) is configured to perform some function, this is to be construed to be equivalent to a description stating that a (i.e. at least one) processor or corresponding circuitry, potentially in cooperation with computer program code stored in the memory of the respective apparatus, is configured to cause the apparatus to perform at least the thus mentioned function. Also, such function is to be construed to be equivalently implementable by specifically configured circuitry or means for performing the respective function (i.e. the expression "unit configured to" is construed to be equivalent to an expression such as "means for").

For the purpose of the present invention as described herein above, it should be noted that

- method steps likely to be implemented as software code portions and being run using a processor at an apparatus (as examples of devices, apparatuses and/or modules thereof, or as examples of entities including apparatuses and/or modules therefore), are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;

- generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the aspects/embodiments and its modification in terms of the functionality implemented;

- method steps and/or devices, units or means likely to be implemented as hardware components at the above-defined apparatuses, or any module(s) thereof, (e.g., devices carrying out the functions of the apparatuses according to the aspects/embodiments as described above) are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field- programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components;

- devices, units or means (e.g. the above-defined apparatuses, or any one of their respective units/means) can be implemented as individual devices, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, unit or means is preserved;

- an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor;

- a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.

In general, it is to be noted that respective functional blocks or elements according to above- described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.

Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to a skilled person.

Software in the sense of the present description comprises software code as such comprising code means or portions or a computer program or a computer program product for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable (storage) medium having stored thereon a respective data structure or code means/portions or embodied in a signal or in a chip, potentially during processing thereof.

It is noted that the aspects/embodiments and general and specific examples described above are provided for illustrative purposes only and are in no way intended that the present invention is restricted thereto. Rather, it is the intention that all variations and modifications which fall within the scope of the appended claims are covered.

Claims

1. A method, comprising:

receiving, at a multicast service center, data packets and an indication regarding application of security functionality from an application server,

2. The method according to claim 1 , wherein

the indication includes a service key, a temporary group identity, information on the kind of protection requested, and information whether protected data for unicast is requested.

3. The method according to claim 2, further comprising

generating, at the multicast service center, a traffic key,

encrypting the traffic key based on the service key, and

encrypting the received data packets based on the traffic key.

4. The method according to claim 3, further comprising

forwarding the encrypted traffic key to the application server.

5. The method according to any one of claims 1 to 4, wherein

the data packets and the encrypted traffic key are forwarded to the application server via a tunnel between the multicast service center and the application server.

6. A method, comprising:

receiving, at an application server, data packets from a first user equipment,

receiving, at the application server, encrypted data packets from the multicast service center, and transmitting the encrypted data packets to second user equipment via unicast.

7. The method according to claim 6, wherein

8. The method according to claim 6 or 7, further comprising

receiving, at the application server, a traffic key generated by the multicast service center.

9. The method according to any one of claims 6 to 8, further comprising

preparing multicast/broadcast traffic received from the multicast service center for usage in unicast.

10. The method according to claim 9, wherein preparing the multicast/broadcast traffic comprises extracting the encrypted data packets from a first transmission data stream destined for multicast/broadcast delivery,

encapsulating the extracted encrypted data packets into a second transmission data stream destined for unicast delivery, and

transmitting the second transmission data stream to the second user equipments via unicast.

11 . An apparatus, comprising

at least one processor, and

12. The apparatus according to claim 1 1 , wherein the indication includes a service key, a temporary group identity, information on the kind of protection requested, and information whether protected data for unicast is requested.

13. The apparatus according to claim 12, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus at least to further perform generating, at the multicast service center, a traffic key,

encrypting the traffic key based on the service key, and

encrypting the received data packets based on the traffic key.

14. The apparatus according to claim 13, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus at least to further perform forwarding the encrypted traffic key to the application server.

15. The apparatus according to any one of claims 1 1 to 14, wherein

16. An apparatus, comprising

at least one processor, and

receiving data packets from a first user equipment,

receiving encrypted data packets from the multicast service center, and

transmitting the encrypted data packets to second user equipment via unicast.

17. The apparatus according to claim 16, wherein

18. The apparatus according to claim 16 or 17, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus at least to further perform

19. The apparatus according to any one of claims 16 to 18, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus at least to further perform

20. The apparatus according to claim 19, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus at least to further perform, when preparing the multicast/broadcast traffic,

extracting the encrypted data packets from a first transmission data stream destined for multicast/broadcast delivery,

21 . An apparatus, comprising:

means for forwarding the encrypted data packets to the application server from which the data packets and the indication are received.

22. An apparatus, comprising:

means for receiving, at an application server, data packets from a first user equipment, means for forwarding the data packets and an indication regarding application of security functionality to a multicast service center,

23. A computer program product including a program for a processing device, comprising software code portions for performing the steps of any one of claims 1 to 10 when the program is run on the processing device.

24. The computer program product according to claim 23, wherein the computer program product comprises a computer-readable medium on which the software code portions are stored.

25. The computer program product according to claim 23, wherein the program is directly loadable into an internal memory of the processing device.