HK1177998A - Methods for policy management - Google Patents

Description

Policy management method

Cross Reference to Related Applications

Priority claims to U.S. provisional application No.61/320,665 filed on 2.4/2010, U.S. provisional application No.61/320,910 filed on 5.4/2010, and U.S. provisional application No.61/362,597 filed on 8.7/2010 are hereby incorporated by reference in their entireties.

Background

A wireless transmit/receive unit (WTRU) and/or a multi-connectivity network may be capable of performing functions and/or communications with and/or on behalf of one or more entities or interested parties (watchers). For example, mobile devices are capable of providing multi-connection services, such as maintaining continuous connectivity to the internet while continuing to provide good quality voice services. Such multi-connectivity services may be provided by or on behalf of different interested parties (e.g., different network operators). Each interested party wishes to perform these functions or communications according to the interested party's policy or policies. The policies of different stakeholders may be conflicting or complementary (complementary).

Disclosure of Invention

Systems, methods, and apparatus for managing and/or coordinating policy enforcement on a communication device and/or in a communication network are disclosed. According to one embodiment, a user device is described that may provide services on behalf of one or more interested parties. The user device may communicate with one or more interested parties, which may manage the services provided on the user device. The user equipment may include at least a processor, memory, and a policy coordination function. One or more stakeholder-specific policies of the one or more stakeholders may be securely stored on the memory. Each stakeholder-specific policy may be a different stakeholder-specific policy, and each stakeholder may be a different stakeholder. The policy coordination function may coordinate security management and/or enforcement of one or more stakeholder-specific policies of the one or more stakeholders, for example, by operating in a secure environment on the processor.

According to another embodiment, a system is described as: the system is configured to coordinate service control policies and access control policies for one or more networks having a plurality of access points. Each access point may be managed by one or more access control entities, and each access control entity may be managed by one or more service control entities. The system may include a policy storage function and a Network Policy Coordination Function (NPCF). The service control policies and the access control policies may be stored in a policy storage function. The enforcement of the service control policies and the access control policies may be coordinated by the NPCF. The NPCF may coordinate enforcement of access control policies for one or more access control entities. The NPCF may coordinate enforcement of service control policies for one or more service control entities.

Other features and aspects of the methods, systems, and apparatus will be more clearly understood from the following detailed description and the accompanying drawings.

Drawings

A more detailed understanding can be obtained from the following description, which is to be read in connection with the accompanying drawings, in which:

FIG. 1A is a system diagram of an example of a communication system in which one or more disclosed embodiments may be implemented;

FIG. 1B is a system diagram of an example of a wireless transmit/receive unit (WTRU) that may be used in the communication system shown in FIG. 1A;

fig. 1C is a system diagram of an example radio access network and an example core network that may be used in the communication system shown in fig. 1A;

FIG. 2 is a diagram representing an example of multiple aggregation scenarios;

FIG. 3 is a network architecture diagram showing high-level attributes of layer interactions;

FIG. 4 illustrates an example of a policy coordination entity for communication in a multi-connection network;

FIG. 5 is a functional architecture diagram illustrating a network policy entity;

FIG. 6 illustrates another system block diagram of an exemplary wireless communication system in which one or more disclosed embodiments may be implemented;

figure 7 is a functional block diagram of a wireless transmit/receive unit (WTRU) and a node-B of the wireless communication system of figure 6;

fig. 8 shows a flowchart of an exemplary security procedure in an IEEE 802.19 system;

FIG. 9 illustrates a chain of trust for initial access; and

fig. 10 illustrates an example process of initial attachment and/or normal operation.

Detailed Description

As referred to hereinafter, the term "wireless transmit/receive unit (WTRU)" may include, but is not limited to, a User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a computer, or any other type of device capable of operating in a wireless environment. When referred to hereafter, the term "base station" can include, but is not limited to, a node B, a site controller, an Access Point (AP), or any other type of interfacing device capable of operating in a wireless environment. When referred to hereafter, the term "node B" may include, but is not limited to, a home node B (hnb), an enodeb (enb), or a home enodeb (henb). Also, any reference to the term "network" may refer to a Radio Network Controller (RNC), a controlling RNC (crnc), a drift RNC, or any other communication network described herein as an example.

Systems, methods, and apparatus for policy control management are described herein. Policy control management may be performed by a policy control entity, which may be included in the WTRU and/or a network entity, for example. The policy control entity may coordinate policies related to one or more interested parties associated with the WTRU and/or the network. According to one example, policy control may be performed for multi-connection communications in multiple Radio Access Technologies (RATs), such as in a Next Generation Network (NGN) architecture.

According to one embodiment, a user device is described that may provide services on behalf of one or more interested parties. The user device may communicate with one or more interested parties, and the interested parties may manage the services provided on the user device. The user equipment may include at least one processor, memory, and/or policy coordination functionality. One or more stakeholder-specific policies of the one or more stakeholders may be securely stored on a memory of the user device. Each stakeholder-specific policy may be a different stakeholder-specific policy, and each stakeholder may be a different stakeholder. The policy coordination function may coordinate secure enforcement of one or more stakeholder-specific policies to one or more stakeholders, for example, by operating in a secure environment on the processor.

According to another embodiment, a system is described as: the system is configured to coordinate service control policies and access control policies for one or more networks having a plurality of access points. Each access point may be managed by one or more access control entities, and each access control entity may be managed by one or more service control entities. The system may include a policy storage function and a Network Policy Coordination Function (NPCF). The service control policies and the access control policies may be stored in a policy storage function. The enforcement of the service control policies and the access control policies may be coordinated by the NPCF. The NPCF may coordinate enforcement of access control policies at one or more access control entities. The NPCF may coordinate enforcement of service control policies at one or more service control entities.

FIG. 1A is an illustration of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, and the like, to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), orthogonal FDMA (ofdma), single carrier FDMA (SC-FDMA), and the like.

As shown in fig. 1A, the communication system 100 may include: wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102 d; a Radio Access Network (RAN) 104; a core network 106; a Public Switched Telephone Network (PSTN) 108; the internet 110 and other networks 112, but it is understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

Communication system 100 may also include base station 114a and base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more networks, such as the core network 106, the internet 110, and/or the network 112. The base stations 114a, 114B may be, for example, Base Transceiver Stations (BTSs), node B, e node bs, home enodeb, site controllers, Access Points (APs), wireless routers, and the like. Although each base station 114a, 114b is illustrated as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

The base station 114a may be part of the RAN 104, and the RAN 104 may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology, and thus may use multiple transceivers for each sector of the cell.

The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which air interface 116 may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, Infrared (IR), Ultraviolet (UV), visible light, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as described above, communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDAM, SC-FDMA, and the like. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may establish the air interface 116 using wideband cdma (wcdma). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (HSPA +). HSPA may include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).

In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-advanced (LTE-a).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000EV-DO, interim standard 2000 (IS-2000), interim standard 95 (IS-95), interim standard 856 (IS-856), Global System for Mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN).

The base station 114B in fig. 1A may be, for example, a wireless router, a home nodeb, a home enodeb, or an access point, and may use any suitable RAT to facilitate wireless connectivity in a local area, such as a business, home, vehicle, school, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE802.11 to establish a Wireless Local Area Network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish the pico cell or the femto cell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-a, etc.). As shown in fig. 1A, the base station 114b may have a direct connection to the internet 110. Thus, the base station 114b may not need to access the internet 110 through the core network 106.

The RAN 104 may communicate with a core network 106, which core network 106 may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. For example, the core network 106 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and/or perform high-level security functions such as user authentication. Although not shown in fig. 1A, it is to be appreciated that the RAN 104 and/or the core network 106 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to interfacing with the RAN 104, which may use E-UTRA radio technology, the core network 106 may also communicate with another RAN (not shown) that employs GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include systems and devices of interconnected global computer networks that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP/IP internet protocol suite. The network 112 may include wired or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another core network connected with one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU102 c shown in fig. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114b, which may employ an IEEE802 radio technology.

Figure 1B is a system diagram of an example WTRU 102. As shown in fig. 1B, the WTRU102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 106, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It is to be appreciated that the WTRU102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120 and transceiver 120 may be coupled to transmit/receive element 122. Although fig. 1B illustrates processor 118 and transceiver 120 as separate components, it is understood that processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

Transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114 a) over air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be, for example, an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and optical signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

Additionally, although transmit/receive element 122 is illustrated as a single element in fig. 1B, WTRU102 may include any number of transmit/receive elements 122. More specifically, the WTRU102 may employ MIMO technology. Thus, in one embodiment, the WTRU102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and demodulate signals received by transmit/receive element 122. As described above, the WTRU102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that enable the WTRU102 to communicate over multiple RATs, such as UTRA and IEEE 802.11.

The processor 118 of the WTRU102 may be coupled to and may receive user input data from the following components: a speaker/microphone 124, a keyboard 126, and/or a display/touch panel 128 (e.g., a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Additionally, the processor 118 may access information from and store data to any type of suitable memory, such as the non-removable memory 106 and/or the removable memory 132. The non-removable memory 106 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data to, memory that is not physically located on the WTRU102, such as on a server or home computer (not shown).

The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and the like.

The processor 118 may also be coupled with a GPS chipset 136, which the GPS chipset 136 may be configured to provide location information (e.g., longitude and latitude) related to the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 116 and/or determine its location based on the timing (timing) of signals received from two or more neighboring base stations. It is to be appreciated that the WTRU102 may acquire location information via any suitable location determination method while remaining consistent with an embodiment.

The processor 118 may be further coupled with other peripherals 138, which peripherals 138 may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos or video), a Universal Serial Bus (USB) interface, a vibration device, a television transceiver, a hands-free headset, BluetoothA module, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, etc.

Fig. 1C is a system diagram of RAN 104 and core network 106 according to one embodiment. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using UTRA radio technology. The RAN 104 may also communicate with a core network 106. As shown in fig. 1C, the RAN 104 may include node-bs 140a, 140B, 140C, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102B, 102C over the air interface 116. Each of the node bs 140a, 140B, 140c may be associated with a particular cell (not shown) within the RAN 104. The RAN 104 may also include RNCs 142a, 142 b. It should be appreciated that RAN 104 may include any number of node bs and RNCs while remaining consistent with an embodiment.

As shown in fig. 1C, node bs 140a, 140B may communicate with RNC 142 a. In addition, node B140 c may communicate with RNC 142B. The node bs 140a, 140B, 140c may communicate with respective RNCs 142a, 142B via an Iub interface. The RNCs 142a, 142b may communicate with each other via an Iur interface. Each RNC 142a, 142B may be configured to control the respective node B140 a, 140B, 140c to which it is connected. Further, each of the RNCs 142a, 142b may be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

The core network 106 shown in fig. 1C may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and/or a Gateway GPRS Support Node (GGSN) 150. While the foregoing components are all described as part of the core network 106, it should be understood that any of these components may be owned and/or operated by an entity other than the core network operator.

RNC 142a in RAN 104 may be connected to MSC146 in core network 106 via an IuCS interface. MSC146 may be connected to MGW 144. The MSC146 and MGW 144 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network (e.g., the PSTN 108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices.

The RNC 142a in the RAN 104 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be coupled to a GGSN 150. The SGSN 148 and GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network (e.g., the internet 110) to enable communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

As described above, the core network 106 may also be connected to the network 112, which network 112 may include other wired or wireless networks owned and/or operated by other service providers.

The communication system or portions thereof may be used when policy management functions are performed on the WTRU and/or the network entity as described above. In one example, policy management functions may be performed for multi-connection operations on the WTRU and/or the multi-connection network.

As described above, multi-connection operations are available within one or more communication networks. For example, multi-connectivity operations between cellular and/or non-cellular Radio Access Technologies (RATs) may be implemented within a mobile operator's communication network. According to one example, the international telecommunications union standards organization for Next Generation Networks (NGN)/future networks (ITU-T SG131Q 9) is developing specifications (requirements, architectures and/or techniques) for enabling multi-connectivity operations between cellular and/or non-cellular RATs within a mobile operator's communication network. Different levels of multi-connection aggregation may also be performed within the mobile network.

Fig. 2 is a diagram depicting multiple aggregation scenarios on a mobile network. This figure implicitly describes the high-level protocol architecture of the mobile network (which may represent, for example, the next-generation network implementation of the OSI 7-layer protocol architecture and/or the 4-layer TCP/IP architecture of the internet). For example, one or more of the scenarios illustrated in FIG. 2 may be implemented when performing policy management functions within and/or associated with one or more networks.

Referring to the scenario shown in fig. 2, scenario E represents the operation of two different applications (application 254 and application 256) over two different Radio Access Technologies (RATs) (access control 262 and access control 264). Networks operating in a scenario such as scenario E may not aggregate. For example, the WTRU 270 may communicate through the access controls 262 and 264 via the access points 266 and 268, respectively. Access control 262 and access control 264 may communicate with application 254 and application 256 via service control 258 and service control 260, respectively.

Case D may hand over the aggregation to application 238, which application 238 may be located outside the mobile network. The application 238 may have a certain amount of interaction with the network. For example, the WTRU 252 may communicate through the access control 244 and the access control 248 via the access point 248 and the access point 250, respectively. Access control 244 and access control 246 may communicate with application 238 via service control 240 and service control 242, respectively.

Case C represents one example of join aggregation in a network. As shown in case C, the WTRU 236 may communicate through the access controls 228 and 230 via the access point 232 and the access point 234, respectively. Access control 228 and access control 230 may communicate with application 224 via service control 226. As shown in case C, each connection may retain a dedicated access control mechanism and may be aggregated in service control 226. Since service control 226 can handle the service requirements of application 224, case C can operate at approximately the "service flow" level (e.g., IP data flow). Case C may handle multiple underlying Radio Access Technologies (RATs) that may, for example, retain their own access control functionality. Case C may allow service control 226 to aggregate these techniques for at least the following functions: aggregation of underlying access technologies and/or policy functions, e.g., QoS functions that it delivers to provide better aggregate quality of service (QoS), to apply and/or split various application data traffic into policy-specific sub-flows (e.g., QoS-specific sub-flows), which can then be matched to the access technology best suited to the policy (e.g., QoS) requested by each sub-flow. One example of this is to split the hypertext transfer protocol (HTTP) access into a data transfer sub-stream, a video sub-stream and an audio sub-stream and/or to associate each sub-stream with the access device that is best suited to handle it.

Case B represents one example of using a single access technology (e.g., access control 216) between multiple access points, such as in a multi-antenna system such as coordinated multi-point transmission (CoMP). The definition of a single technology is to be understood broadly as "the same family of technologies". The WTRU 222 may communicate through the access control 216 via the access point 218 and the access point 220 as shown in case B. Access control 216 may communicate with application 212 via service control 214. Case B may be used for operation of the same technology family across multiple spectrums (e.g., cellular access technology in a licensed cellular environment and its derivation for weaker licensed spectrum (e.g., TV bands)).

Case a represents one example of operating multiple access points in a network. For example, the WTRU 210 may communicate with the access control 206 via the access point 208. Access control 206 may communicate with application 202 via service control 204.

According to one exemplary architecture, a single policy control entity may be located between the service control layer and the access control layer. However, this architecture is deficient. Architecturally, the policy function may not be a layer located between the service control and access control layers (e.g., no data or information is passed through the policy). The controller may inform the service control layer and/or the access control layer how to operate on the data. The attributes of the decisions made by service control (e.g., QoS matching) and access control (e.g., access technology mapping) are different. Having a single joint decision entity control both aspects simultaneously may result in unnecessary complexity and may be unnecessary in some systems, for example, in systems that support a multi-connection scenario. A method may be implemented that is capable of supporting dedicated policy services for service control and access control and/or providing relaxed coordination between service control and access control. This approach can simplify the design of defining policies and testing the resulting system. A set of policy rules, such as QoS policies, cost functions and/or access rights, may define a large number of possible policy manners (policies) that may operate simultaneously in a complementary and/or contradictory manner.

These policies may not be dependent on the protocol architecture and/or may not be appropriate in some cases. For example, aggregation policies designed for application policies cannot be used on the access control entity, as these application policy rules may not be available. Since it is an "aggregation policy," such policy may be used in case C in fig. 2, since aggregation may be implemented by service control 226 in this case.

It is described herein how a policy entity adapts to its architecture. For example, when implementing a system that includes a policy entity as described herein, a set of policy rules may be defined and/or associated with a policy (e.g., a QoS rule).

FIG. 3 illustrates the various layers of the architecture shown in FIG. 2, as well as the high-level properties of the layer interactions. For example, fig. 3 shows an application layer 302, a service control layer 306, an access control layer 310, and an access point layer 314. The application layer 302 may communicate with the service control layer 306 and be located inside and/or outside the network. The application layer 302 may communicate with a service control layer 306, for example, via an application QoS 304. The application layer 302 may communicate with the network by sending and/or receiving data payloads using the network.

Service control layer 306 may communicate with application layer 302 and/or access control layer 310. The service control layer 306 may interact with the application layer 302 to learn its communication policies (e.g., QoS and/or other policy rules). The service control layer 306 may interact with the access control 310 to ensure that communication rules (e.g., QoS and/or other policy rules) are satisfied.

Access control layer 310 may communicate with access point layer 314 and/or service control layer 306. Access control layer 310 may be responsible for configuring and/or managing various access methods (e.g., RATs) to ensure that policy rules (e.g., QoS and/or other policy rules) requested by service control layer 306 are satisfied. Access control layer 310 may communicate with service control layer 306, for example, via service QoS 308. Access control layer 310 may communicate with access point layer 314, for example, via access configuration 312.

The access point layer 314 may include entities capable of communicating with the WTRU 316 and/or the access control layer 310. Entities in the access point layer 314 may communicate with the WTRU 316 over a physical medium (e.g., a base station, Wi-Fi AP, etc.). Which may implement RAT configuration policies enacted by access control layer 310.

As described above, a multi-connection network with multiple access points may communicate with a device, such as a WTRU. In communicating between the multi-connection network and the device, one or more policies may be enforced at the device and/or the multi-connection network. When multiple policies exist, there may be conflicts between the various policies on the devices and/or networks. For example, one or more different policies may correspond to different stakeholders. Interested parties may include, for example, one or more network and/or application service providers, device manufacturers, device users, and/or subscribers. A policy coordination entity may be implemented on the device and/or network to resolve the conflict.

Fig. 4 illustrates an exemplary system that includes entities that can be employed to coordinate policies related to network communications in a multi-connection network. For example, FIG. 4 shows a device Policy Coordination Function (PCF) 414 for use in coordinating multiple policies on device 400. PCF414 may be included within device 400. Device 400 may be a communication device that communicates with a network, such as multi-connection network 434. Fig. 4 also shows a Network Policy Coordination Function (NPCF) 432 for use in coordinating various policies on device 400 and/or multi-connection network 434. NPCF 432 may be included in a multi-connection network 434.

For PCF414, apparatus 400 includes PCF414 for coordinating relevant policies when performing communications. PCF414 may perform functions to coordinate policies of different interested parties of device 400. For example, each stakeholder may be associated with a different application, smart card and/or UICC that is installed in and/or associated with the device 400. The policy may be coordinated on behalf of one or more interrelated parties. PCF414 may be involved in a variety of functions to operate device 400 efficiently. One or more parameters may be included in PCF414 for policy coordination, such as security policy processing, communication QoS processing, multiple communication link processing, or other policy parameters.

Device 400 may provide a trusted and secure operating environment for securely performing policy installation, configuration, updates, coordination, and the like. For example, device 400 may include a trusted environment (TrE) 402. The TrE 402 may refer to a logical entity that may provide a trusted context for operating sensitive functions and storing sensitive data. The data generated by performing functions within TrE 402 is unknown to unauthorized external entities. For example, TrE 402 may be configured to prevent unauthorized disclosure of data to external entities. TrE 402 may perform sensitive functions such as for device integrity checking and/or device validation (e.g., storing a key, providing a cryptographic algorithm using the key, and enforcing a security policy). The TrE 402 may be anchored to a persistent hardware root of trust that is not tampered with. TrE 402 may be slaved to device 400, for example. TrE 402 may comprise, for example, a SIM card, which may be used, for example, in GSM devices. The implementation of TrE 402 may depend on the application and/or the level of security required.

TrE 402 is a secure environment in which PCF414 may be executed. PCF414 of device 400 may enforce policies from different interested parties. PCF414 may also resolve conflicts between policies from multiple interested parties. The PCF414 component may reside in firmware, hardware, and/or software. Authorization to modify advanced PCF414 functionality may belong to a root authority. Delegation (deletion) of the authority may be achieved through a chain of trust secured by a trusted environment (TrE) 402. The principals may be assigned priorities in a particular PCF414 resolution function in mutually exclusive and/or mutually authorized manners (e.g., equal but not the same), such that each non-root principal may have priority for some results and not others.

PCF414 may initiate a process and/or may respond to dynamic conditions. PCF414 may receive status and/or measurements in real-time such that a change in input may result in a change in one or a set of actions. Such a change in one or a set of actions may occur immediately upon a change in the input or, for example, after a controlled time delay.

PCF414 may act as a proxy for NPCF 432. For example, PCF414 on device 400 may enforce a policy that is "peered" to the policy enforced on NPCF 432. These peer-to-peer policies may be sub-policies generated from the master policy enforced by the NPCF 432. NPCF 432 may handle operations that require a large amount of computation and/or may have administrator privileges to optimize PCF414 functionality of device 400. NPCF 432 may provide services on behalf of an interested party and/or control aspects of PCF 414. In some cases, PCF414 may be better suited to detect changing conditions, e.g., due to its location in the network, and/or to enforce network-wide policies accordingly. The NPCF 432 may operate autonomously based on the input it receives, or it may operate semi-autonomously between some instructions and/or decisions at the network side and some decisions made locally. Alternatively, NPCF 432 may operate according to instructions and/or decisions entirely from the network.

In performing security policy processing, PCF414 may present instructions on how to continue operation in the event of a device integrity check failure. Policy-based enforcement may include, but is not limited to, the following mechanisms: a bound device validation for client authentication based on a pre-shared key, a bound device validation for certificate-based device authentication, and/or a device integrity validation for other device functions. The security policy may indicate one or more security parameters. For example, the security policy may indicate sets of algorithms to be used, a strength (e.g., length) of a key to be used, a number of security protocols to be used, a security protocol to be used, a retention policy (e.g., duration, entity to verify validity of a key and/or time of validity of a key, exceptions), depreciation, deletion, and/or updating of encryption keys. For example, a security policy may be indicated for the interested party, and/or a service or application for the interested party. Different security policies may be indicated for different stakeholders, and/or different services or applications for different stakeholders. According to an example, where QoS is defined from the perspective of the security strength provided for each communication of multiple connections, security specific QoS policies may be used.

PCF414 may consider rules proposed by multiple interested parties to use its traffic. For example, PCF414 may use its coordination capability to resolve conflicts between the stakeholder policies. The user may have a user policy (SP) 408 that includes enforcement rules. For example, SP 408 may request a minimum security strength (e.g., encryption strength) for a commercial telephone call request and a preference for the cheapest telephone service available. PCF414 may initiate negotiation of security associations for the least expensive traffic, such as traffic connection a (SA _ a) 416. For example, the device 400 may attempt to establish a connection with the network 434 at access point a 424 via connection a 420. If the security level requested at SP 408 does not enable the connection, this information is fed back to PCF 414. PCF414 may incorporate this state and/or initiate a second secure call using another operator at a higher cost, such as the security association of service connection B (SA _ B) 418. Device 400 may then establish a connection with multi-connection network 434 at access point B426 via connection B422. As shown, connection B422 may be established between device 400 and multi-connection network 434 at a security level requested by SP 408.

Access point a 424 and access point B426 may communicate with a multi-connection service control function 430. The multi-connection service control function 430 may include a user authentication function 428 for authenticating user information. NPCF 432 may coordinate policies associated with multi-connection service control function 430.

According to another example, a user may wish to transfer a data file from an enterprise network to a wireless device. A user may request a multi-connection communication to use multiple services simultaneously to achieve a transmission rate. PCF414 may maintain a minimum security level for data communicated between multiple connections using comparable security key strengths according to various stakeholder (e.g., enterprise) policies. In this case, although there are multiple channels, if the required transmission rate is not achieved, the user may wish to record the situation, which may be signed by PCF414, by a trusted entity within TrE 402, and/or TrE 402 itself. In another example, the user may deny the fast rate achieved and the service provider may need a copy, which may be signed, for example, by PCF414 or other possible signing entity. As such, PCF414 needs to have signing capability to prevent unfulfilled service. TrE 402 may prevent the visiting PCF414 from signing the key in the event that the PCF414 integrity check fails. Alternatively, another trusted entity within TrE 402 may sign data generated by PCF 414. Upon failure of the PCF414 integrity check, TrE 402 may prevent access to the signing key maintained by another trusted entity that may sign data generated by PCF 414.

PCF414 may also coordinate policies related to key generation, derivation, and/or bootstrapping (bootstrap) for different interested parties to the device. For example, referring to FIG. 4, the high-level key may be generated from a shared key between the user-interested party and the primary carrier A. A further primary (child-level) shared key that may be used between device 400 and operator B may be generated from a key generated between the user and operator a in accordance with SP 408, operator a policy (OP _ a) 410, and/or operator B policy (OP _ B) 412. A bootstrapping mechanism may be employed to generate these keys.

According to another embodiment, PCF414 of device 400 may not be implemented within integrated TrE 402 of device 400, but rather may be implemented in an entity or module that is plugged into or connected to device 400. The entity or module may be connected to the device 400 and/or separated from the device 400. An example of such an entity is an advanced version of a smart card or UICC.

The integrity of certain components in the device 400 may be protected by a Device Validation Function (DVF) 404. The DVF404 may be located in TrE 402 and/or may perform a device integrity check to verify whether the integrity of the components of device 400 are protected. For example, DVF404 may verify the integrity of the components of device 400. The DVF404 may perform a device integrity check, for example, using the device validation certificate 406. The network and/or the device itself may use the integrity information for device validation. For example, once the integrity of the components of the device 400 is verified, the DVF404 may sign the integrity data and/or any other relevant supplemental data using the TrE 402's private key before forwarding the integrity data to other entities for validation.

The DVF404 may provide assurance that the interested party with the appropriate authority may modify PCF414 functionality under the control of that authority. The assurance provided by the DVF404 may include a device validation certificate 406. Advanced PCF414 functionality may be responsible for managing the PCF authority. The administrative PCF authority may be, for example, a user, an operator, an application service provider, and/or a device manufacturer. The management PCF may be configured by the manufacturer or may be configured later by the operator, application service provider, or user. TrE 402 may prevent unauthorized updates and/or modifications to PCF414 functionality and/or protect stakeholder policies on the device, including, for example, isolating policy functionality from each other.

TrE 402 may use DVF404 to protect policies on the device. For example, TrE 402 may use DVF404 to perform a "gate" process that may gate access to one or more applications, functions, and/or data (e.g., device validation credentials 406) stored in TrE 402. The gating process may be performed according to the state of the device integrity validation result. The gating process may be "cascade (cascade)". For example, DVF404 may gate access to one function or application, while the function or application may gate access to another function, application, or data. The DVF404 may gate a plurality of processes or data, some or all of which may have causal or corresponding relationships.

Fig. 5 illustrates a policy coordination function that may be performed by the NPCF. Fig. 5 represents a system/protocol architecture showing existing policy entities. The functional architecture shown in fig. 5 represents the scope of the core network to represent the various roles assumed by the network entities. In any given system, there may be some or all of the entities shown. For example, the presence or absence of one or more of the illustrated entities depends on which of the scenarios illustrated in FIG. 2 can be performed.

The Network Policy Coordination Function (NPCF) 506 may be a functional entity in the core multi-connectivity network 501. The NPCF 506 may have a multi-connection control function. The NPCF 506 may receive connection information from a multi-connection registration entity and/or request operator policies from an operator policy storage entity on a per WTRU basis. As shown in fig. 5, the NPCF 506 may communicate with an application policy entity 502, such as a multi-connection application policy entity. The application policy entity 502 may be included in the application layer 302 or associated therewith via an application policy interface 504. When there is an IP flow for the WTRU 316, the NPCF 506 may implement a policy to route the IP flow to the most appropriate network of the multi-connectivity.

The NPCF 506 may coordinate the operation of various policy entities in the core multi-connectivity network 501. When multiple policies exist, the NPCF 506 may resolve conflicts between the various policies. The NPCF 506 may be available for a longer period of time, i.e. preventing simultaneous use of multiple specific policies, while shorter-term policy operations may be scheduled by the respective policy entities.

The NPCF 506 may implement a service transfer policy function. The NPCF 506 may include functionality that can be performed in conjunction on one or more layers. Thus, the NPCF 506 may include a multi-connection registration function and/or a multi-connection control function, as shown in fig. 2.

The NPCF 506 may interface with the WTRU 316. This interface is represented in figure 5 by the dashed line 514 between the NPCF 506 and the WTRU 316. The WTRU 316 may implement a policy of "peer to peer" with a policy in the network. For example, these peer policies may be sub-policies generated from a master policy within quality of service (QoS) policy entity 508, access policy entity 510, and/or NPCF 506 itself. The peer-to-peer policy may include, for example, a QoS function, a billing function, data access rights, or other policy functions. The WTRU 316 may be informed of the sub-policies and may then follow the sub-policies. The master policy may include a plurality of WTRU 316 sub-policies that may vary depending on the WTRU 316 conditions, core multi-connectivity network 501 conditions, and/or radio interface conditions.

The functional architecture of fig. 5 may be used for the architecture of case D shown in fig. 2. The application 302 may make a multi-connection decision and has an application policy entity 502. The application layer 302 and the application policy entity 502 may be outside the core multi-connectivity network 501, as indicated by the dashed line 516. The core multi-connectivity network 501 may have an interface to the application policy entity 502. Thus, the application policy interface 504 may provide an interface between the NPCF 506 and the application policy entity 502 in the core multi-connectivity network 501, where the interface is assigned between the core multi-connectivity network 501 and the application layer 302.

The application policy interface 504 may provide the application policy entity 502 and the core multi-connectivity network 501 with a way to exchange information about the attributes of the policies for aggregation and/or a way to prevent policy conflicts. For example, if the application 302 uses a policy that requires a particular data sub-flow to be placed in a particular connection, the NPCF 506 may pass the policy via the application policy interface 504 to ensure that another multi-connection operation (e.g., an operation to acquire another access point) does not move the data to a different connection.

As shown in fig. 5, QoS policy entity 508 and/or access policy entity 510 may be located in policy store function 512. The policy store function 512 may perform more than a storage function. The policy store 512 may perform policy decisions and/or comparisons between a number of policies, such as QoS policies, to avoid conflicts therebetween.

Service control layer 306 may satisfy the policy requirements of application 302 by corresponding the policy requirements to the available access policies. Such policies may include, for example, QoS policies. The QoS policy entity 508 may be included in the service control layer 306. For example, in case C shown in fig. 2, a multi-connection decision may be made by the service control layer 306, which may be influenced by the QoS requirements of the application. The QoS policy entity 508 is exemplary and may represent any policy entity that may be used by the service control layer 306.

As shown in fig. 5, QoS policy entity 508 may implement QoS policies. Further, the QoS policy entity 508 may enforce service migration policies, wherein the multi-connection scenario C as shown in fig. 2 includes a mixed usage scenario of multi-connection initial and/or final destinations for service migration. The access change and/or update may involve multiple connections between the access control entity and the service control entity.

As shown in fig. 2, in case B, multiple connections may be managed by a multi-connection access control function 216 that may manage connections over a set of access points (e.g., access point 218 and access point 220) that may use the same set of access technologies. As shown in fig. 5, access policy entity 510 may provide for the use of multiple access points.

Access policy entity 510 may implement an access network selection policy. Access policy entity 510 may perform service migration policies, wherein, as shown in fig. 2, multi-connection scenario B may comprise a multi-connection initial and/or final target hybrid usage scenario for service migration. The access change may involve multiple connections between the access point entity and the access control entity.

Several policy request types are described below. The five models shown in fig. 2, cases A, B, C, D and E, may involve different policy functions depending on the radio access technology, access control, service control and/or application requirements to which they relate.

The different policy requests are described in a case-by-case manner below.

For example, as shown in fig. 2, a network supporting scenario B may include an access policy entity 510 as shown in fig. 5. Access policy entity 510 may support policies for satisfying policy requests (e.g., QoS requests) for access technologies by aggregating multiple available access points. The access policy may control how the access method is constructed. For example, in a cellular network, the access policy may include a QoS class, and in a Wi-Fi network, the access policy may include a traffic priority. The access policy may also include the spectrum to be used, the access point to be used, the number of channels to be aggregated and/or whether end-to-end connectivity is to be used (e.g., to access the internet by connecting to another device via bluetooth technology).

According to another example, as shown in fig. 2, a network supporting scenario C may include a QoS policy entity 508 as shown in fig. 5. As shown in fig. 5, QoS policy entity 508 may support policies that can satisfy the application QoS by appropriately using the QoS provided by the various available access technologies. QoS policies may address higher layer issues. For example, the QoS policy may indicate one or more access networks to be used, how to establish the connection (e.g., which protocol and/or streaming method to use), and/or a connection priority. From a QoS perspective, QoS policies may also indicate the importance of delay, traffic, authenticity, cost, and the like.

According to another example, as shown in FIG. 2, a network supporting case D may include an application policy interface 504 as shown in FIG. 5. As shown in fig. 5, application policy interface 504 may provide an interface to application policy entity 502, which may be, for example, a multi-connection policy entity. The application policy interface 504 may provide details to the application layer 302 to make the same or similar QoS level decisions, for example, in the configuration of case D, as are made in the network of case C, for example.

Some policies may be common to one or more of the 5 cases shown in fig. 2. For example, the network may be able to deliver policies to the WTRU 316 through the service control layer 306. A multi-connection network (e.g., core multi-connection network 501) may include NPCF 506 to coordinate multiple policy entities in the network.

Although the PCF and NPCF are described herein as two separate entities, as shown, for example, in fig. 4 and 5, policy coordination may be performed on, or shared by, the device PCF and NPCF. Thus, any of the functions described herein with respect to being performed by the device PCF may be performed by the NPCF, any of the functions described herein with respect to being performed by the NPCF may be performed by the device PCF, and/or any of the policy coordination functions described herein may be performed jointly by the device PCF and the NPCF.

In light of the above description, a set of policy management requests, such as QoS management requests, is described below.

In a multi-connection network, the WTRU and the network may be aware of the interactions and/or associated QoS resulting from the multitude of simultaneous accesses provided to the application. The combined or generated QoS may define a joint QoS in a particular service.

The following description includes some multi-connection QoS requests.

For example, as shown in fig. 2, in cases A, B and C, the service control layer may provide the application with a final QoS that is at least the same level as the QoS provided by the single access technology itself.

According to another example, as shown in fig. 2, in cases a and B, the access control layer may pass access technology QoS to the service control, which is at least the same as the QoS provided by any single access link itself.

According to another example, as shown in fig. 2, in case a, access point 208 may communicate QoS to access control 206 that is at least the same as the QoS provided by any individual access link under its control itself.

Fig. 6 illustrates an exemplary wireless communication system 600 that can be employed to perform policy coordination as described herein. The wireless communication system 600 may include a plurality of WTRUs 610, a node B620, a Controlling Radio Network Controller (CRNC) 630, a Serving Radio Network Controller (SRNC) 640, and a core network 650. Node B620 and CRNC 630 may be collectively referred to as UTRAN.

As shown in fig. 6, the WTRU 610 communicates with the node B620, and the node B620 communicates with the CRNC 630 and the SRNC 640. Although three WTRUs 610, one node B620, one CRNC 630, and one SRNC 640 are illustrated in fig. 6, any combination of wireless and/or wired devices may be included in the wireless communication system 600.

Figure 7 is a functional block diagram 700 of a WTRU 710 and a node-B720 of the wireless communication system 600 of figure 6. As shown in fig. 7, a WTRU 710 communicates with a node B720, both of which are configured for QoS and policy management for multi-connection communications, such as a multi-RAT NGN architecture.

In addition to the components present in the WTRU, the WTRU 710 includes a processor 715, a receiver 716, a transmitter 717, a memory 718, and an antenna 719. The memory 718 may store software including an operating system, applications, and the like. The processor 715 may perform QoS and policy management for multi-connection communications, such as a multi-RAT NGN architecture, alone or in combination with software. The receiver 716 and transmitter 717 are in communication with the processor 715. The antenna 719 is in communication with both the receiver 716 and the transmitter 717 to facilitate the transmission and reception of wireless data.

In addition to the components found in node B, node B720 includes a processor 725, a receiver 726, a transmitter 727, a memory 728, and an antenna 729. The processor 725 may perform QoS and policy management for multi-connection communications, such as a multi-RAT NGN architecture. The receiver 726 and the transmitter 727 are in communication with the processor 725. The antenna 729 is in communication with both the receiver 726 and the transmitter 727 to facilitate the transmission and/or reception of wireless data.

Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, and any other type of Integrated Circuit (IC) and/or state machine.

A radio frequency transceiver may be implemented using a processor in association with software for a Wireless Transmit Receive Unit (WTRU), a user equipment (WTRU), a terminal, a base station, a Radio Network Controller (RNC), or any host computer. The WTRU may be used in combination with modules, such as a camera, a video camera module, a video phone, a microphone, a vibrating device, a speaker, a microphone, a television transceiver, a hands-free phone, a keyboard, and Bluetooth, in hardware and/or softwareA module, a Frequency Modulation (FM) radio unit, a Liquid Crystal Display (LCD) display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) module.

According to one embodiment, the system, method and apparatus for policy coordination described herein may be used in a system using TV white space (TVWS). For example, the systems, methods, and apparatus described herein may be used to support coordination and/or execution of security procedures in a system that coexists between a TV band device (TVBD) network operating independently and different TV band devices. For example, the IEEE 802.19 standard specifies a radio technology independent method for coexistence between different or independently operating TVBD networks and different TVBDs. A member newly joining the system may discover the 802.19 system and/or send a join request. Thereafter, an authentication procedure may be used for access negotiation. The system may provide a committed (commit) system policy. The newly joined member needs to commit at least a portion of the system policies, which may be provided, for example, in a list. The system policy may be updated. The newly joined member may be decommissioned for at least a portion of the system policy or the updated system policy. For the authentication process, the new member may use the TrE to generate a proof or measurement of platform integrity for trust status local integrity checking and send the measurement or proof data for trust validation.

According to one example, the radio technology independent approach may be specific to coexistence between different or independently operating TVBD networks and different TVBDs. Such as the IEEE 802.19 standard or other similar standards, may specify such a radio technology independent approach. The 802.19 standard may enable the IEEE802 wireless standards family to efficiently use a TV idle band (TVWS) by providing different or independently operating TVBD networks and a standard coexistence method between different TVBDs. The 802.19 standard can solve the coexistence problem of IEEE802 networks and devices, and can also be used for non-IEEE 802 networks and TVBDs.

The core network 106 as shown in fig. 1A and 1C may include network entities supporting IEEE 802.19, including, but not limited to, a Coexistence Discovery and Information Server (CDIS), a coexistence manager, a TVWS database, and the like. The CDIS is an entity that can collect information related to TVWS coexistence, and can provide information related to coexistence, and can also support discovery of a coexistence manager. The coexistence manager may be an entity that makes coexistence decisions and/or generates and provides coexistence requests and commands and control information. The TVWS DB may provide a list of channels occupied by primary users.

Embodiments for security procedures (e.g., in IEEE 802.19 systems) are disclosed below. According to one embodiment, the WTRU and/or the network (e.g., the TV band device and/or the TV band device network) and the 802.19 system may perform discovery, access control, policy negotiation, and/or policy enforcement procedures. The procedures performed in operation may include policy updates and/or changes, as well as other coexistence mechanisms (e.g., channel selection, power control, time, etc.). The embodiments described herein may use the IEEE 802.19 system as an example, but the embodiments may be used in any other system to support coexistence between different or independently operating TV band device (TVBD) networks and different TVBDs.

The 802.19 system is not a group (club) that each must join or each is allowed to join (although some will be invited). There are many community rules, but they may be optional. There may be some entities nearby that are not members of the community. To join the community, new members may perform discovery and/or access control procedures. The new member may obtain a list of rules (coexistence policy) and/or declare which rule or rules it follows (i.e., negotiate coexistence policy). The new member may follow the policy promised by the new member.

The new member is free to declare the policy that it is willing or unwilling to follow. This may decide how to treat the new member (e.g., the more flexible it is, the more other entities will work with it). Once a policy commitment is made, the new member needs to keep the policy commitment consistent. The community rules may change. The set of policies used may depend on what network/device is active. Thus, entering and exiting the network and the device may affect the policy group. The network and devices may be in a nomadic (normal) state. The movement from system to system can be very simple, but does not maintain continuity of the connection (i.e., no handover).

Fig. 8 shows a flowchart of an example security procedure in an IEEE 802.19 system. The new member 802 performs a discovery protocol 806 with the 802.19 system 804. The new member accesses 802.19 system 804 by sending a join request 808 to 802.19 system 804. The 802.19 system 804 includes other 802.19 capable network devices that have decided to perform co-existence collaboration. Authentication and/or access negotiation 810 may be performed between the new member 802 and the 802.19 system 804.

The 802.19 system 804 provides a list of system policies (coexistence policies) to the new member and either enforces policy commitments 814 or decongests (i.e., negotiates coexistence policies) by the new member. Not all network devices may or may wish to perform all operations. A "proof" of willingness to follow the policy may be sent to the 802.19 system 804. After the system policy commitment 814, normal operations 816 may take place between the new member 802 and the 802.19 system 804. The new member 802 may request "coexistence assistance" or may receive and execute a coexistence request. The new member 802 may leave the system by sending a system leave notification 818 to the 802.19 system 804. All exchanges between the new member 802 and the 802.19 system 804 use standard integrity and confidentiality protection and trade-offs (revoages) with the mechanisms provided by the transport used.

For the authentication process performed in the access negotiation 810, a centralized architecture or a distributed architecture may be performed. In a centralized architecture, for example, a standard approach (e.g., 802.1X) may be used for authentication. A Coexistence Discovery and Information Server (CDIS) may be an entity for providing an authentication server.

In a distributed architecture, the following facts can be identified: each "master" device may authenticate itself to the TVWS Database (DB). The TVBD or TVBD network may manage unregistered operation in the broadcast TV spectrum at spectrum locations not used by the registration service. The TVWS DB may provide a channel list occupied by the primary user. The TVWS DB may be used to provide proof of successful authentication of the new member to the TVWSDB. This approach can also be used for a centralized architecture that can prevent having an authentication server in the CDIS. When performing the authentication procedure herein, a TrE may be used.

The TrE may provide a measure of confidence that the functionality in the new member is performing in an intended manner. The TrE may perform an internal self-check on the trust status of the new member (i.e., a hardware, software, and data self-check based on integrity measurements of software components in the new member). The signature token of the TrE from the (local) integrity check result may be included in the message sent from the new member to the 802.19 system. The 802.19 system may validate the token based on the identity of the TrE in the token (and the new member) and with reference to a Trusted Third Party (TTP) authenticator (verifier). The TTP authenticator may provide the new member's security architecture, profile, and/or capability information based on its identification.

The integrity of the TrE in the new member may be verified by a hardware anchored root of trust (RoT). RoT and TrE may be trusted by their public keys and the ability to track TTP for security architecture, profile, and/or capability information. The TrE may be loaded and executed in the new member. The TrE may prepare a load order list of new member modules and/or component groups to be validated and loaded. The TrE may create and/or sign a token for distribution to the 802.19 system for attestation of its trusted state. The token may be signed by the TrE's private key. The trusted attributes and tokens of the TrE in the device may be confirmed by reference to the TTP. The 802.19 system may determine access authorization, validate the new member, and/or sign the token with its own certificate based on the integrity verification information. The 802.19 system may forward the token to the new member after performing the interactive authentication. After authentication, the TrE within the new member is free to distribute 802.19 system signed tokens to other 802.19 system entities to ensure their trustworthy state to these entities.

In a distributed setting, a challenge that may exist in a challenge in trust-based authentication is a centralized server that has no means for authentication and for the 802.19 system to learn the identity of new members. Given the existence of a trusted system and the secure authentication and/or registration of managed (regulatory) TVWS databases, these challenges can be addressed by using available resources.

A trust-based authentication process in a distributed setting is now disclosed. The new member may perform an internal self-check and/or generate a measurement or proof of platform integrity. The TVWS DB is accessible to new members. The access may be secure. The new member may use a secure trusted process to generate a token indicating that the managed database was successfully registered using a particular database ID. For example, the token may be a certificate, such as an electronic or lightweight (lightweight) certificate. For example, the token may be transmitted and/or tracked back to the trusted third party.

The new member may perform an 802.19 authentication process. The new member may request access and/or participation in the 802.19 system. The new member may generate a verifiable token of its platform integrity. The new member may identify itself to the 802.19 system using the same ID used to register with the managed DB and sign with a token that the DB registration was successful.

The 802.19 system can rate trust in the new member as follows: the system may verify the platform integrity of the new member. Platform integrity may ensure that the new member management DB ID is truly generated. The database ID may be associated with a Public Key Infrastructure (PKI) key pair to allow the token to be signed using the TrE private key. Platform integrity may ensure that the token on successful registration of the DB is truly generated. If all steps pass, the 801.19 system can trust that the new member did indeed successfully register with the (known) managed DB and can do so as the basis for trust and authentication. The process may not require the managed DB to provide any services other than the services it needs to provide.

Fig. 9 shows a chain of trust for initial access. As shown in fig. 9, the 802.19 system can verify root of trust (RoT) 902. The 802.19 system may then verify 904 the new member's baseline platform integrity. This may, for example, incorporate policies and/or 802.19 functionality. The 802.19 system can then check 906 whether the registered database identification is authentic. This step may be performed, for example, for authenticating the new member. The 802.19 system may check the registered database identification stored in the database of the 802.19 system. If the registered database identification is not problematic, the new member may register with the 802.19 system at 908. The 802.19 system may generate a token for use by the new member in communicating in the 802.19 system. The new member may initiate an access request at 910. For example, the new member may roam in the 802.19 system and/or communicate with other 802.19 devices using the generated token. In one embodiment, the 802.19 device relies on a token generated by the 802.19 system for authentication and does not independently authenticate new members.

Device tampering may occur (i.e., if the device commits to the policy but is not intended to enforce the policy, or if the device commits to the policy and is intended to enforce the policy but cannot enforce because it was tampered with). The risk of tampering with the device may be addressed by a security mechanism, such as a TrE.

Information may be provided that may indicate that the device has not been tampered with. Which may be performed once as part of the access and/or registration procedure. A token may be generated and passed to other 802.19 entities. The TrE-based attestation of authenticity may be used for each policy commitment (and/or decommissioning). The TrE-based attestation of authenticity may use TrE functionality intermittently and/or frequently. By proof of platform integrity (token generation and/or passing), compliance with promised policies can be demonstrated.

FIG. 10 illustrates an example process of initial attachment (attachment). As shown in FIG. 10, the new member 1102 may perform a secure boot by measuring and/or checking the integrity of system components. The new member may send a report 104 (generate token) to the 802.19 system 1108 regarding its own detection measurements or data and security profile/capability information. 802.19 system 1108 may analyze the information in the report to assess the trustworthiness. 802.19 system 1108 may respond by allowing access or may prohibit access if the device is deemed to be untrusted based on the information provided by the report. The access information may be sent to the new member 1102 through an access control decision 1106.

The new member 1102 may roam into the area of the TVBD network and perform policy negotiation. The new member 1102 may broadcast a policy commitment. The new member 1102 may perform a coexistence mechanism.

When policy changes, policy negotiation, and/or authentication, the new member 1102 may want the 802.19 system 1108 to send a report on its own detection (token) and/or security profile information, and may monitor policy update messages, and/or perform policy renegotiation and/or broadcast updated policy commitments. The new member 1102 may perform a coexistence mechanism.

As described herein, an 802.19 system can send system policy updates to new members, and the new members respond with system policy commitments. Each network and/or device is free to choose the policies it may or may wish to follow. Once a network and/or device declares a policy that it may or wishes to comply with, the network and/or device promises compliance with it. After policy commitment, a coexistence mechanism may be executed. The new member may declare a policy decommission commitment.

Although the systems, methods, and apparatus described herein are described in the context of a 3GPP UMTS wireless communication system, they may be used with any wireless technology. For example, embodiments described herein may be used for wireless technologies that use a control channel monitoring set (e.g., LTE-A, and/or WiMax). For example, for the PDCCH monitoring set, the scheme may be extended to LTE.

Although features and elements are described above in particular combinations, it will be understood by those of ordinary skill in the art that each feature or element can be used alone or in combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated into a computer readable medium for execution by a general purpose computer or a processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and computer readable storage media. Examples of the computer readable storage medium include, but are not limited to, Read Only Memory (ROM), Random Access Memory (RAM), registers, buffer memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor in association with software is used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims (21)

1. A user device capable of providing a service on behalf of one or more interested parties, and wherein the provision of said service can be managed by said one or more interested parties, and wherein the user device is in communication with said one or more interested parties, the user device comprising:

at least one processor;

a memory in which one or more stakeholder-specific policies of the one or more stakeholders are securely stored, wherein each stakeholder-specific policy is a different stakeholder-specific policy, and wherein each stakeholder is a different stakeholder; and

a Policy Coordination Function (PCF) configured to perform the following on the processor: coordinating secure enforcement of one or more stakeholder-specific policies of the one or more stakeholders.

2. The user equipment of claim 1, wherein the PCF is configured to perform operations in a secure environment within the user equipment.

3. The user device of claim 2, wherein the secure environment is a trusted environment (TrE) or a smart card.

4. The user device of claim 2, wherein the processor is further configured to execute a gating process in the secure environment to gate access to applications, functions, or data stored in the secure environment.

5. The user device of claim 2, wherein the secure environment prevents unauthorized updates to the one or more stakeholder-specific policies.

6. The user equipment of claim 1, wherein the one or more stakeholder-specific policies may include at least one of a security policy, a communication quality of a service policy, a policy associated with a plurality of communication links, or a cost function.

7. The user equipment of claim 1, wherein the PCF is a proxy for a Network Policy Coordination Function (NPCF) located in a network.

8. The user equipment of claim 1, wherein the PCF considers each stakeholder-specific policy for using the service.

9. The user equipment of claim 1, wherein the PCF coordinates secure enforcement of one or more stakeholder-specific policies of the one or more stakeholders based on user policies.

10. The user equipment of claim 9, wherein the user policy relates to a security strength associated with network communications.

11. The user equipment of claim 9, wherein the user policy relates to user preferences associated with costs of available services on a network.

12. The user device of claim 1, wherein the one or more stakeholder-specific policies are configured to be modified by a root authority, wherein the root authority is a stakeholder of the one or more stakeholders.

13. The user equipment of claim 12, wherein the root authority has authority to modify the PCF.

14. The user equipment of claim 1, wherein the PCF is under control of a governing PCF authority.

15. The user equipment of claim 14, wherein the administrative PCF authority is at least one of a user, an operator, or a device manufacturer.

16. The user device of claim 1, wherein the one or more stakeholder-specific policies are received from an external source.

17. The user equipment of claim 1, wherein the external source is a network entity.

18. The user equipment of claim 1, wherein each of the one or more stakeholder-specific policies relates to a different service provided by a respective stakeholder of the one or more stakeholders.

19. A system configured to coordinate service control policies and access control policies, wherein each access point of a plurality of access points is managed by one or more access control entities, and wherein each access control entity is managed by one or more service control entities, the system comprising:

a policy storage function storing the service control policy and the access control policy; and

a Network Policy Coordination Function (NPCF) configured to coordinate enforcement of the service control policies and the access control policies, wherein the NPCF is configured to coordinate enforcement of the service control policies with respect to the one or more service control entities, and wherein the NPCF is configured to coordinate enforcement of the access control policies with respect to the one or more access control entities.

20. The system of claim 19, wherein the service control policy and the access control policy are master policies representing sub-policies configured to be executed on a wireless transmit/receive unit.

21. The system of claim 19, wherein the NPCF is configured to coordinate enforcement of the service control policies and the access control policies on a TV band device system.