The present disclosure is directed to broadcast services and, more particularly, to multimedia broadcast services.
A Multimedia Broadcast/Multicast Service (MBMS) system is a system that allows delivery of multimedia to mobile stations (also referred to as wireless terminals, user equipment, UEs, etc.) over multicast/broadcast radio channels. The term eMBMS is used in 3GPP (3rd Generation Partnership Project) standards to mean MBMS over Long Term Evolution (LTE) specific radio access networks. In the present disclosure, the term MBMS may also include eMBMS.
The 3GPP specification TS 33.246, “Security of Multimedia Broadcast/Multicast Service (MBMS),” V10.0.0, December 2010, states that the security of MBMS provides different challenges compared to the security of services delivered using point-to-point services. Countering broadcast related threats may require frequent updates of decryption keys in a manner that may not be predicted by subscribers while making efficient use of the radio network. The 3GPP specification TS 33.246, “Security of Multimedia Broadcast/Multicast Service (MBMS),” V10.0.0, December 2010, is incorporated herein in its entirety by reference. According to known MBMS security provisions, it may be difficult to support uninterrupted provision of an MBMS service to a mobile device moving between different radio access networks.
It may therefore be an object to address at least some of the above mentioned disadvantages and/or to improve network performance.
According to some embodiments, a method of creating a delivery session for multiple broadcast multicast service centers may include providing a first create delivery session message for a first broadcast multicast service center. A service key identification and a key domain identification may be received from the first broadcast multicast service center, and a second create delivery session message may be provided for a second broadcast multicast service center. The second create delivery session message may include the service key identification and the key domain identification from the first broadcast multicast service center, and the second create delivery session message may include a duplicate indication.
By providing a service key identification and/or a key domain identification from one broadcast multicast service center to another broadcast multicast service center, an same MBMS service may be supported by the different broadcast multicast service centers through different radio access networks in different geographic areas. Accordingly, a wireless terminal may receive uninterrupted access/use to/of the MBMS service while moving between the service through the different radio access networks in the different geographic areas.
Providing the second create delivery session message may include providing the second create delivery session message for the second broadcast multicast service center responsive to receiving the service key identification and the key Domain identification from the first broadcast multicast service center.
The first broadcast multicast service center may be remote from the second broadcast multicast service center. Providing the first create delivery session message may include transmitting the first create delivery session message from a broadcast provisioning system to the first broadcast multicast service center remote from the broadcast provisioning system. Providing the second create delivery session message may include transmitting the second create delivery session message from a broadcast provisioning system to the second broadcast multicast service center remote from the broadcast provisioning system.
A third create delivery session message may be provided for a third broadcast multicast service center. The third create delivery session message may include a duplicate indication, and the third create deliver session message may include the service key identification and the key domain identification from the first broadcast multicast service center. The third broadcast multicast service center may be remote from the first and second broadcast multicast service centers.
The first create delivery session message may include a new service indication, and the second create delivery session message may include a duplicate indication.
The service key identification and the key Domain identification may be received from the second broadcast multicast service center.
The service key identification may be a Multimedia-Broadcast/Multicast-Service (MBMS) service key identification.
A first traffic key identification message may be provided to the first broadcast multicast service center, with the first traffic key identification message including the service key identification, the key domain identification, a traffic key identification, and a refresh time associated with the traffic key identification. A second traffic key identification message may be provided to the second broadcast multicast service center (BMSC2), with the second traffic key identification message including the service key identification, the key domain identification, the traffic key identification, and the refresh time associated with the traffic key identification.
The first create delivery session message may include a delivery session identification and a service identification, with the second create delivery session message including the delivery session identification and the service identification. The first traffic key identification message may include the delivery session identification and the service identification, and the second traffic key identification message may include the delivery session identification and the service identification.
The service key identification may be a first service key identification, the first create delivery session message may include a delivery session identification and a service identification, and the second create delivery session message may include the delivery session identification and the service identification. In addition, a first update delivery session message may be provided for the first broadcast multicast service center, with the first update delivery session message including the delivery session identification and the service identification. The key domain identification and a second service key identification may be received from the first broadcast multicast service center, with the first and second service key identifications being different. A second update delivery session message may be provided for a second broadcast multicast service center, with the second create delivery session message including the second service key identification and the key domain identification from the first broadcast multicast service center.
Receiving the service key identification and the key domain identification may further include receiving the service key identification, the key domain identification, and a service key from the first broadcast multicast service center, and the second create delivery session message may further include the service key from the first broadcast multicast service center.
According to some other embodiments, a broadcast provisioning system may include a provisioning interface providing communications with first and second broadcast multicast service centers, and a processor circuit coupled to the provisioning interface. The processor circuit may be configured to provide a first create delivery session message for the first broadcast multicast service center through the provisioning interface, with the first create delivery session message includes a new service indication. The processor circuit may be further configured to receive a service key identification and a key Domain identification from the first broadcast multicast service center through the provisioning interface. The processor may also be configured to provide a second create delivery session message for the second broadcast multicast service center through the provisioning interface, with the second create delivery session message including the service key identification and the key domain identification from the first broadcast multicast service center.
According to still other embodiments, a method of providing a broadcast service at a broadcast multicast service center may include receiving a create delivery session message from a broadcast provisioning system. Responsive to receiving the create delivery session message, a security service may be created at the broadcast multicast service center including a key domain identification and a service key identification. The service key identification and the key domain identification for the security service may be provided to the broadcast provisioning system.
Receiving the create delivery session message may include receiving the create delivery session message including a new service indication, and creating the security service may include creating the key domain identification and the service key identification at the broadcast multicast service center.
Receiving the create delivery session message may include receiving the create delivery session message including a duplicate indication and including the key domain indication and the service key identification. Creating the security service may include creating the security service using the key domain identification and the service key identification received from the broadcast provisioning system.
A traffic key identification message may be received from the broadcast provisioning system, with the traffic key identification message including the service key identification, the key domain identification, a traffic key identification, and a refresh time associated with the traffic key identification.
The create delivery session message may include a delivery session identification and a service identification, and the traffic key identification message may include the delivery session identification and the service identification.
A traffic key may be generated at the broadcast multicast service center using the service key identification, the key domain identification, and the traffic key identification.
The traffic key may include a Multimedia-Broadcast/Multicast-Service (MBMS) traffic key, with the service key identification including an MBMS service key identification, and with the traffic key identification including an MBMS traffic key identification.
Creating may further include creating a service key identified by the key domain identification and the service key identification. In addition, the service key may be transmitted to a user equipment node, the traffic key may be transmitted to the user equipment node protected with the service key, and multimedia content data may be transmitted to the user equipment node protected with the traffic key.
The service key identification may be a first service key identification, and the create delivery session message may include a delivery session identification and a service identification. In addition, an update delivery session message may be received from the broadcast provisioning system, with the first update delivery session message including the delivery session identification and the service identification. Responsive to receiving the update delivery session message, the security service may be received at the broadcast multicast service center to use the key domain identification and a second service key identification, with the first and second service key identifications being different. The key domain identification and the second service key identification for the security service may be provided to the broadcast provisioning system.
Creating the security service may include creating security service including the service key identification, the key domain identification, and a service key, and wherein providing the service key identification and the key domain identification further comprises providing the service key identification, the key domain identification, and the service key to the broadcast provisioning system.
According to yet other embodiments, a broadcast multicast service center may include a provisioning interface providing communications with a broadcast provisioning system, and a processor circuit coupled to the provisioning interface. The processor circuit may be configured to receive a create delivery session message from the broadcast provisioning system through the provisioning interface, to create a security service including a key domain identification and a service key identification responsive to receiving the create delivery session message, and to provide the service key identification and the key domain identification for the security service through the provisioning interface to the broadcast provisioning system.
The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiment(s) of inventive concepts disclosed herein. In the drawings:
Present inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Present inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment.
For purposes of illustration and explanation only, these and other embodiments of present inventive concepts are described herein in the context of operating in/with a Radio Access Network (also referred to as a Radio Network or RAN) that communicates over radio communication channels with wireless terminals (also referred to, for example, as User Equipment nodes, User Equipment, UEs, etc.). It will be understood, however, that present inventive concepts are not limited to such embodiments and may be embodied generally in any type of communication network. As used herein, a wireless terminal (also referred to as a user equipment node, user equipment, UE, etc.) can include any device that receives data from a communication network, and may include, but is not limited to, a mobile telephone (“cellular” telephone), laptop/portable computer, pocket computer, hand-held computer, and/or desktop computer.
In some embodiments of a RAN, several base stations can be connected (e.g., by landlines or radio channels) to a radio network controller (RNC). The radio network controller, also sometimes termed a base station controller (BSC), supervises and coordinates various activities of the plural base stations connected thereto. The radio network controller is typically connected to one or more core networks.
The Universal Mobile Telecommunications System (UMTS) is a third generation mobile communication system, which evolved from the Global System for Mobile Communications (GSM), and is intended to provide improved mobile communication services based on Wideband Code Division Multiple Access (WCDMA) technology. UTRAN, short for UMTS Terrestrial Radio Access Network, is a collective term for the Node B's and Radio Network Controllers which make up the UMTS radio access network. Thus, UTRAN is essentially a radio access network using wideband code division multiple access for UEs.
The Third Generation Partnership Project (3GPP) has undertaken to further evolve the UTRAN and GSM based radio access network technologies. In this regard, specifications for the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) are ongoing within 3GPP. The Evolved Universal Terrestrial Radio Access Network (E-UTRAN) comprises the Long Term Evolution (LTE) and System Architecture Evolution (SAE).
Note that although terminology from 3GPP (3rd Generation Partnership Project) LTE (Long Term Evolution) is used in this disclosure to exemplify embodiments of inventive concepts, this should not be seen as limiting the scope of inventive concepts to only these systems. Other wireless systems, including WCDMA (Wideband Code Division Multiple Access), WiMax (Worldwide Interoperability for Microwave Access), UMB (Ultra Mobile Broadband), HSDPA (High-Speed Downlink Packet Access), GSM (Global System for Mobile Communications), etc., may also benefit from exploiting embodiments of present inventive concepts disclosed herein.
Also note that terminology such as base station (also referred to as eNodeB or Evolved Node B) and wireless terminal (also referred to as UE or User Equipment) should be considered non-limiting and does not imply a certain hierarchical relation between the two. In general a base station (e.g., an “eNodeB”) and a wireless terminal (e.g., a “UE”) may be considered as examples of respective different communications devices that communicate with each other over a wireless radio channel. While embodiments discussed herein may focus on wireless transmissions in a downlink from an eNodeB to a UE, embodiments of inventive concepts may also be applied, for example, in the uplink.
MBMS introduces the concept of point-to-multipoint service into a 3GPP broadcast and multicast system. An element of an MBMS User Service is to be able to securely transmit data to a given set of users. To achieve this, methods of authentication, key distribution, and data protection may be provided for a MBMS User Service, as specified in 3GPP specifications. In particular, 3GPP MBMS currently specifies that to protect an MBMS User Service, service and transport keys are delivered from the Broadcast Multicast Service Center (BMSC, also referred to as BM-SC) to the UE.
The BMSC controls the use of the MBMS Service Keys (MSKs) to secure the different transport sessions. The MSKs are used to protect delivery of MBMS Transport Keys (MTKs), which are used to secure the transport session content and delivered in-band using the content transport.
MBMS systems of
To illustrate this point, the MBMS of
According to some embodiments of present inventive concepts, a BMSC Provisioning Interface and a Broadcast Provisioning System may be provided as shown in
As shown in
MSK Handling in Multi-BMSC Deployment.
As shown in
An MBMS service key (MSK) is uniquely identifiable by its key domain identification and MBMS service key identification (MSK-ID). The key domain identification may be 3 bytes long and may include a mobile country code (MCC) and a mobile network code (MNC). The MSK-ID may be 4 bytes long with byte 0 and byte 1 containing the key group part, and byte 2 and byte 3 containing the key number part. The key number part is used to distinguish MSKs that have the same key domain ID and key group part. The key group part is used to group keys together to allow redundant MSKs to be deleted.
An MBMS traffic key (MTK) is uniquely identifiable by its key domain identification, MSK-ID, and MTK-ID. The MTK-ID may be a 2 byte long sequence number that is used to distinguish MTKs that have the same key domain ID and MSK-ID. An MTK-ID that will be used in a next MTK update may need to be greater than the previously used MTK-ID.
The service identification (serviceID) element identifies the service uniquely. The session identification (sessionID) attribute identifies the delivery session. The encryption designation indicates whether (or not) the service identified by the serviceID and the delivery session within the service identified by the delivery session ID is to be protected with encryption.
The service key MSK identified by Key Domain ID (key_Domain_ID) and MSK ID (MSK-ID) is created by the selected BMSC (see,
In each of operations 5-4, 5-7, and 5-10 of
The new service indication indicates that the receiving BMSC (e.g., BMSC1) should create a new security service including a new service key MSK, a new service key identification MSK-ID, and a new key domain identification. A duplicate service indication indicates that the receiving BMSC (e.g., BMSC2, BMSC3, and BMSC4) should create a security service using the service key, the service key identification, and the key domain identification provided in the create delivery message.
In each of operations 5-6, 5-9, and 5-12 of
According to some embodiments, all BMSCs (e.g., BMSC1, BMSC2, BMSC3, and BMSC4) may use the same method to create their security service and MSK given the Key Domain ID and MSK ID. According to some embodiments, the primary BMSC (e.g., BMSC1) may create the security service including the service key MSK, service key identification MSK-ID, and key domain identification, and the secondary BMSCs (e.g., BMSC2, BMSC3, and BMSC4) may create the same security service using the service key MSK, the Key Domain ID, and the MSK ID created/provided by the primary BMSC. Similar operations may be performed to update the service key and service key identification for the MBMS service. As shown in
As shown in
The updated service key MSK-2 for the security service is identified by the original key domain ID (key_Domain_ID) that is reused from the initial creation of the security service (at operation 5-1) and the updated MSK ID (MSK-ID-2) that is updated/created by the selected BMSC (see,
In each of operations 10-4, 10-7, and 10-10 of
In each of operations 10-6, 10-9, and 10-12 of
According to some embodiments, all BMSCs (e.g., BMSC1, BMSC2, BMSC3, and BMSC4) may use the same method to update their security service and service key MSK-2 given the original Key Domain ID and the updated service key identification MSK-ID-2. According to some embodiments, the primary BMSC (e.g., BMSC1) may update the security service including the updated service key MSK-2, the updated service key identification MSK-ID-2, and the original key domain identification, and the secondary BMSCs (e.g., BMSC2, BMSC3, and BMSC4) may create the same security service using the updated service key MSK-2, the original Key Domain ID, and the updated service key identification MSK-ID-2 created/provided by the primary BMSC.
MTK Handling.
3GPP standards state that every traffic key (e.g., every MBMS traffic key MTK) may be uniquely identifiable by its Key Domain ID (key_Domain_ID), MSK ID (MSK-ID), and MTK ID (MTK-ID). By the mechanism outlined above with respect to
This second mechanism may be realized by the Broadcast Provisioning System using the Provisioning Interface to specify a MTK-ID and refresh time (also referred to as validity time information and/or key synchronization information, see,
Each BMSCs may thus be responsible to create its own MTK-ID (traffic key identification) and hence its own MTK (traffic key).
According to some embodiments, all BMSCs may use a same method to create their MTK given the Key Domain ID and MSK ID and MTK ID.
Some embodiments of present inventive concepts may also allow a MTK refresh time interval to be specified. This information may allow all BMSCs which are UTC (Universal Time Coordinated) time synchronized to compute when to update their MTKs (traffic keys).
Measures according to some embodiments of present inventive concepts may enable the MBMS security handling for multiple BMSC deployments when using 3GPP MBMS security.
Some embodiments of present inventive concepts may provide a central coordination of MSK (service key) and MTK (traffic key) which may be useful for practical multi-BMSC MBMS security enabled services.
As shown in
The broadcast provisioning system BPS may thus include provisioning interface 905 providing communications with a plurality of broadcast multicast service centers (e.g., BMSC1, BMSC2, BMSC3, and BMSC4), and processor circuit 903 coupled to the provisioning interface 905. The processor circuit 903 may be configured to provide (e.g., transmit) a first create delivery session message for a first broadcast multicast service center BMSC1 (also referred to as a primary BSMC) through the provisioning interface 905 at operation 5-1, with the first create delivery session message including a new service indication. More particularly, the first create delivery session message may include a delivery session identification (deliverySessionID), a service identification (ServiceID), an encryption indication (encrypt=yes), and the new service indication (NewService).
As discussed above, BMSC1 may create the security service including the key domain identification key_Domain_ID, the service key identification MSK-ID (e.g., a MBMS service key identification), and the service key MSK at operation 5-2, and transmit the response including the key domain identification, the service key identification MSK-ID, and the service key MSK at operation 5-3. Accordingly, processor circuit 903 may receive the service key identification and the key Domain identification from the first broadcast multicast service center BMSC1 through the provisioning interface (905 at operation 5-3. Upon receipt of the response through provisioning interface 905 at operation 503, processor circuit 903 may propagate the security service information to one or more other BMSCs supporting the same MBMS. For example, processor circuit 903 may provide (e.g., transmit) a second create delivery session message for the second broadcast multicast service center BMSC2 (also referred to as a secondary BMSC) through the provisioning interface 905 at operation 5-4, with the second create delivery session message including a duplicate indication. More particularly, the second create delivery session message may include the delivery session identification (deliverySessionID), the service identification (ServiceID), the encryption indication (encrypt=yes), duplicate service indication (duplicate), the key domain identification, the service key identification, and the service key. The second create delivery session message that is transmitted to BMSC2 may thus include the key domain identification, the service key identification MSK, and the service key MSK that were generated/created by BMSC1.
The same service key MSK, the same service key identification MSK-ID, and key domain identification may thus be used at a primary BMSC (e.g., BMSC1) that initially created the security service, and at a plurality of secondary BMSCs (e.g., BMSC2, BMSC3, and BMSC4) using the same security service for the same MBMS service. For example, processor circuit 903 may provide (e.g., transmit) third and fourth create delivery session messages for the third and fourth broadcast multicast service centers BMSC3 and BMSC4 through the provisioning interface 905 at operations 5-7 and 5-10, with the third and fourth create delivery session messages including the duplicate indication. The third and fourth create delivery session messages may thus include the same information as the second create delivery session message.
The broadcast provisioning system BPS may thus coordinate use of the same service key, the same service key identification, and the same key domain identification for the same MBMS service that is provided from different BMSCs coupled to respective different radio access networks in different geographic locations. According to some embodiments, each of the broadcast multicast service centers of
As discussed above, each of the BMSCs may create a security service (e.g., at operations 5-2, 5-5, 5-8, and 5-11) using a same key domain identification, a same service key identification, and a same service key to support provision of a same MBMS service from each of the MBSCs. Responsive to successful creation of the security service at a BMSC, the BMSC may transmit a response message to the BPS (e.g., at operations 5-3, 5-6, 5-9, and 5-12) to confirm/acknowledge successful creation of the security service. Accordingly, a response message may be received through provisioning interface 905 at processor circuit 903 after each create security service message, and each response message may include the key domain identification and the service key identification.
Once the security service has been created at each of the BMSCs, a same traffic key for the security service may be provided at each of the BMSCs as discussed above with respect to
As discussed above with respect to
For example, processor circuit 903 may provide (e.g., transmit) a first update delivery session message through the provisioning interface to the first broadcast multicast service center (BMSC1) at operation 10-1, with the first update delivery session message including the delivery session identification, the service identification, the encryption indication, and an update service indication. BMSC1 may update the security service to include the original key domain identification key_Domain_ID, a second service key identification MSK-ID-2 (e.g., a second MBMS service key identification), and a second service key MSK-2 (e.g., a second MBMS service key) at operation 10-2, and transmit a response including the key domain identification, the second service key identification MSK-ID-2, and the second service key MSK-2 at operation 10-3. Accordingly, processor circuit 903 may receive the second service key MSK-2, the second service key identification MSK-ID-2, and the original key Domain identification from the first broadcast multicast service center BMSC1 through the provisioning interface 905 at operation 10-3. Upon receipt of the response through provisioning interface 905 at operation 10-3, processor circuit 903 may propagate the updated security service information to the one or more other BMSCs supporting the same MBMS.
For example, processor circuit 903 may provide (e.g., transmit) update delivery session messages through the provisioning interface to each of the secondary broadcast multicast service centers (e.g., BMSC2, BMSC3, and BMSC4) at operations 10-4, 10-7, and 10-10. Each update delivery session message to a secondary BMSC may include the delivery session identification, the service identification, the encryption indication, a duplicate indication, the key domain identification, the second service key identification MSK-ID-2, and the second service key MSK-2. More particularly, each update delivery session message to a secondary BMSC may include the second service key identification MSK-ID2 and the second service key MSK-2 generated/created by the primary BMSC. The BMSCs may then update the security service at operations 10-5, 10-8, and 10-11, and transmit respective responses at operations 10-6, 10-9, and 10-12.
As discussed above, a service key identification may include two parts, a key_group part and a key_number part. Once a security service has been created as discussed above with respect to
Each broadcast multicast service center BMSC may include a provisioning interface 911 providing communications with the broadcast provisioning system (BPS), and a processor circuit 913 coupled to the provisioning interface 911. When the BMSC is selected as the primary BMSC (e.g., BMSC1), the processor circuit 913 may be configured to receive the initial create delivery session message (createDeliverySession) from the broadcast provisioning system BPS through the provisioning interface 911 at operation 5-1. As discussed above, the initial create delivery session message may include the delivery session identification, the service identification, the encryption indication, and the new service indication.
At operation 5-2, processor circuit 913 may be configured to create the security service including the key domain identification key_Domain_ID, the service key identification MSK-ID, and the service key MSK responsive to receiving the initial create delivery session message. At operation 5-3, processor circuit 913 may provide (e.g., transmit) a response message including the service key identification, the key domain identification, and the service key for the security service through the provisioning interface 911 to the broadcast provisioning system BPS.
When the BMSC is a secondary BMSC (e.g., BMSC2, BMSC3, or BMSC 4), the processor circuit 913 may be configured to receive the secondary create delivery session message (createDeliverySession) from the broadcast provisioning system BPS through the provisioning interface 911 at operation 5-4, 5-7, or 5-10. As discussed above, the secondary create delivery session message may include the delivery session identification, the service identification, the encryption indication, the duplicate indication, the key domain identification, the service key identification, and the service key.
At operation 5-5, 5-8, or 5-11, processor circuit 913 may be configured to create the security service including the key domain identification key_Domain_ID, the service key identification MSK-ID, and the service key MSK responsive to receiving the secondary create delivery session message. At operation 5-6, 5-9, or 5-12, processor circuit 913 may provide (e.g., transmit) a response message including the service key identification and the key domain identification for the security service through the provisioning interface 911 to the broadcast provisioning system BPS. As discussed above, the response of operations 5-6, 5-9, and 5-12 may also include the service key.
Once primary and secondary BMSCs have created the security service including the service key, the key domain identification, and the service key identification, the broadcast provisioning system BPS may provide the traffic key identification and the refresh time, and according to some embodiments, the BPS may provide the traffic key at operations 6-1, 6-3, 6-5, and 6-7. Accordingly, each BMSC may receive a traffic key identification message (MTK_Identification message) from the broadcast provisioning system BPS (e.g., at operation 6-1, 6-3, 6-5, or 6-7), with the traffic key identification message including the delivery session identification, the service identification, the encryption indication, the service key identification, the key domain identification, a traffic key identification, and a refresh time associated with the traffic key identification. According to some embodiments, each BMSC may generate/create a same traffic key using the service key identification, the key domain identification, and the traffic key identification.
Once each BMSC has generated/received a service key, a key domain identification, a service key identification, traffic key, and a traffic key identification, the security service may be updated as discussed above with respect to
Processor circuit 913 of a secondary BMSC (e.g., BMSC2, BMSC3, or BMSC4) may receive a secondary update delivery session message from the BPS through provisioning interface 911 with the secondary update delivery session message including the delivery session identification, the service identification, the encryption indication, a duplicate indication, the key domain identification, the second service key identification, and the second service key at operation 10-4, 10-7, or 10-10. Responsive to receiving the update delivery session message, processor circuit 913 may update the security service to use the key domain identification, the second service key identification, and the second service key at operation 10-5, 10-8, or 10-11, with the first and second service key identifications being different and the first and second service keys being different. Processor circuit 913 of a secondary BMSC may provide (e.g., transmit) a response message including the key domain identification, and the second service key identification for the security service through provisioning interface 911 to the BPS at operation 10-6, 10-9, or 10-12.
A BMSC (either a primary or secondary BMSC) may thus create a security service using a service key, a service key ID, a key domain ID, a traffic key, and a traffic key ID, and the security service may be used to provide multimedia content for a MBMS service form a content service provider CSP through a radio access network to one or more wireless terminals as illustrated in
As discussed above with respect to
In the above-description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which inventive concepts belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense expressly so defined herein.
When an element is referred to as being “connected”, “coupled”, “responsive”, or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being “directly connected”, “directly coupled”, “directly responsive”, or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, “coupled”, “connected”, “responsive”, or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term “and/or” includes any and all combinations of one or more of the associated listed items.
As used herein, the terms “comprise”, “comprising”, “comprises”, “include”, “including”, “includes”, “have”, “has”, “having”, or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation “e.g.”, which derives from the Latin phrase “exempli gratia,” may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation “i.e.”, which derives from the Latin phrase “id est,” may be used to specify a particular item from a more general recitation.
It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements/operations, these elements/operations should not be limited by these terms. These terms are only used to distinguish one element/operation from another element/operation. Thus a first element/operation in some embodiments could be termed a second element/operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.
Example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).
These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks.
A tangible, non-transitory computer-readable medium may include an electronic, magnetic, optical, electromagnetic, or semiconductor data storage system, apparatus, or device. More specific examples of the computer-readable medium would include the following: a portable computer diskette, a random access memory (RAM) circuit, a read-only memory (ROM) circuit, an erasable programmable read-only memory (EPROM or Flash memory) circuit, a portable compact disc read-only memory (CD-ROM), and a portable digital video disc read-only memory (DVD/BlueRay).
The computer program instructions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as “circuitry,” “a module” or variants thereof.
It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.
Many different embodiments have been disclosed herein, in connection with the above description and the drawings. It will be understood that it would be unduly repetitious and obfuscating to literally describe and illustrate every combination and subcombination of these embodiments. Accordingly, the present specification, including the drawings, shall be construed to constitute a complete written description of various example combinations and subcombinations of embodiments and of the manner and process of making and using them, and shall support claims to any such combination or subcombination.
Many variations and modifications can be made to the embodiments without substantially departing from the principles of present inventive concepts. All such variations and modifications are intended to be included herein within the scope of present inventive concepts. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/SE2013/050802 | 6/27/2013 | WO | 00 |
Number | Date | Country | |
---|---|---|---|
61670755 | Jul 2012 | US |