Authorization of transferring session between user elements

The present invention relates to wireless communication technology.

<u style="single">Cross-reference of related applications</u> This application claims the benefit of US Patent Provisional Application No. 61/315245, filed March 18, 2010, the contents of which are incorporated herein by reference.

IMS (IP (Internet Protocol) Multimedia Subsystem) is an architectural framework that delivers IP-based multimedia services. Radio transmission / reception units (WTRU) include networks based on technologies such as UTRAN (UMTS Terrestrial Radio Access Network), Long Term Evolution (LTE), WiMax (Worldwide Interoperability for Microwave Access), or Wireless Local Area Network (WLAN) technology. Can connect to IMS through a variety of access networks, not limited to these. WTRUs can access IMS through packet-switched (PS) domains. Through the use of IMS Centralized Services (ICS), WTRUs can also access IMS services through circuit-switched (CS) domains.

UE-to-UE transfer (IUT) allows communication session transfer from one WTRU to another. Transfers allow a user to handle media better when one user shares media with another user, when the user takes a session or session component and moves away from the device currently used in that session. When you want to transfer media to a device that can (ie, larger screen, clearer audio, etc.), when the device currently used in the session has a low battery or bad wireless coverage, or a remote end Can occur when the current source WTRU does not perform well due to changes in media characteristics or additional media.

Inter-operator transfers may include collaborative sessions between WTRUs. Typically, at least one controller WTRU is used for collaborative sessions. Session invitations can be routed to the controller WTRU and communication sessions can be directed to devices with controller capabilities. A device can register its capabilities and can be given a higher priority than other devices for receiving communication sessions.

Instead of transferring a session, it may be desirable to duplicate some or all of the media components of a session. For example, one user may want to share an ongoing session with another. However, it is difficult to distinguish between a media component transfer request and a media component replication request. It is also difficult to determine if a device can perform replication and how often a session can be replicated.

A method of replicating a media session within the SCC AS (Service Centralized and Continuity Application Server), the step of receiving a co-duplication session invite request from the second WTRU (wireless transmit / receive unit), and the authorization of the co-duplication session invite request. And the step of allocating media resources for the replicated media flow, the step of sending the response of the replicated media flow in the MRF (media resource function) to a second WTRU, and the replication using the MRF. A method characterized by including a step of updating the access leg on the first WTRU of the media flow and a step of updating the remote leg of the replicated media flow in the MRF.

A more detailed understanding can be obtained from the following description given as an example related to the accompanying drawings.

<figref num="1A">FIG. 5 is a system diagram illustrating an exemplary communication system capable of implementing one or more disclosed embodiments.</figref><figref num="1B">It is a system diagram which shows the example WTRU (wireless transmission / reception unit) which can be used in the communication system shown in FIG. 1A.</figref><figref num="1C">FIG. 5 is a system diagram showing an exemplary radio access network and an example core network that can be used within the communication system shown in FIG. 1A.</figref><figref num="2">It is a figure which shows the example of the duplication scenario.</figref><figref num="3">It is a figure which shows the example of pull mode session duplication.</figref><figref num="4">It is a figure which shows the example of the push mode session duplication by a network.</figref><figref num="5">It is a figure which shows the example of pull mode session duplication by a network.</figref><figref num="6">It is a figure which shows the 1st example which authorizes the duplication request.</figref><figref num="7">It is a figure which shows the 2nd example which authorizes the duplication request.</figref><figref num="8">It is a figure which shows the example of authorization of IUT after duplication.</figref><figref num="9">It is a figure which shows an example of authorization of duplication by a network which uses a push mode.</figref><figref num="10">It is a figure which shows the example of authorization of duplication by the network which uses pull mode.</figref><figref num="11">It is a figure which shows the example which uses the duplication indicator.</figref><figref num="12">It is a figure which shows the example of the duplication by the network using the duplication indicator and the push mode.</figref><figref num="13">It is a figure which shows the example of the duplication by the network using the duplication indicator and the pull mode.</figref>

FIG. 1A is a diagram of an exemplary communication system 100 capable of implementing one or more disclosed embodiments. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, broadcast, and more to a plurality of wireless users. Communication system 100 can allow multiple wireless users to access such resources through sharing of system resources, including radio bandwidth. For example, the communication system 100 includes code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), SC-FDMA (single-carrier FDMA), and the like. You can use one or more channel access methods.

As shown in FIG. 1A, the communication system 100 includes WTRU (wireless transmission / reception unit) 102a, 102b, 102c, 102d, wireless access network (RAN) 104, core network 106, public switched telephone network (PSTN) 108, and Internet 110. , And other networks 112, but it is appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRU 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU 102a, 102b, 102c, 102d can be configured to transmit and / or receive radio signals, WTRU. 102a, 102b, 102c, 102d are user equipment (UE), mobile stations, fixed or movable subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smart phones, laptops, netbooks. , Personal computers, wireless sensors, consumer electronics, etc. can be included.

Communication system 100 can also include base station 114a and base station 114b. Of base stations 114a, 114b, of WTRU 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as core network 106, internet 110, and / or network 112, respectively. It can be any type of device configured to wirelessly interface with at least one. For example, the base stations 114a and 114b can be a radio base station (BTS), a node B, an e-node B, a home node B, a home e-node B, a site controller, an access point (AP), a wireless router, and the like. Although base stations 114a, 114b are shown as single elements, respectively, it should be understood that base stations 114a, 114b can include any number of interconnected base stations and / or network elements. ..

Base station 114a can be part of RAN 104, which is a network of other base stations and / or base station controllers (BSCs), wireless network controllers (RNCs), relay nodes, etc. Elements (not shown) can also be included. Base stations 114a and / or base stations 114b can be configured to transmit and / or receive radio signals within certain geographic areas, sometimes referred to as cells (not shown). The cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a can include three transceivers, i.e. one transceiver per sector of the cell. In another embodiment, base station 114a can use MIMO (Multiple Input Multiple Output) technology and therefore can utilize multiple transceivers per sector of the cell.

Base stations 114a, 114b can communicate with one or more of the WTRU 102a, 102b, 102c, 102d via air interface 116, which can be any suitable radio communication link (eg, for example). Radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

More specifically, as noted above, Communication System 100 can be a multiple access system and uses one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. can do. For example, base stations 114a and WTRU 102a, 102b, 102c in RAN 104 can implement radio technologies such as UTRA (Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access), which is WCDMA®. Air interface 116 can be established using (Broadband CDMA). WCDMA can include communication protocols such as HSPA (High Speed Packet Access) and / or HSPA + (Evolved HSPA). HSPA can include HSDPA (High Speed Downlink Packet Access) and / or HSUPA (High Speed Uplink Packet Access).

In another embodiment, base stations 114a and WTRU 102a, 102b, 102c can implement radio technologies such as E-UTRA (Evolved UMTS Terrestrial Radio Access), and E-UTRA is LTE (Long Term Evolution). ) And / or LTE-A (LTE-Advanced) can be used to establish the air interface 116.

In other embodiments, the base stations 114a and WTRU 102a, 102b, 102c are IEEE 802.16 (ie, WiMAX (Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, IS-2000 (Interim Standard 2000). ), IS-95 (Interim Standard 95), IS-856 (Interim Standard 856), GSM® (Global System for Mobile communications), EDGE (Enhanced Data rates for GSM Evolution), GERAN (GSM EDGE), etc. Can implement wireless technology.

Base station 114b in Figure 1A can be, for example, a wireless router, home node B, home e-node B, or access point and has wireless connectivity within localized areas such as workplaces, homes, vehicles, and campuses. Any suitable RAT can be utilized to facilitate. In one embodiment, base stations 114b and WTRU102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base stations 114b and WTRU102c, 102d are IEEE to establish a wireless personal area network (WPAN). Wireless technologies such as 802.15 can be implemented. In another embodiment, base stations 114b and WTRU102c, 102d may utilize cellular-based RATs (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. it can. As shown in FIG. 1A, base station 114b can have a direct connection to the Internet 110. Therefore, the base station 114b may not be required to access the Internet 110 via the core network 106.

The RAN 104 can be assumed to be communicating with the core network 106, which provides voice services, data services, application services, and / or VoIP (voice over internet protocol) services, WTRU 102a, 102b, It can be any type of network configured to provide one or more of 102c, 102d. For example, core network 106 can provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, and / or perform high-level security features such as authentication. .. Although not shown in Figure 1A, the RAN 104 and / or the core network 106 may be in direct or indirect communication with other RANs that use the same RAT as the RAN 104 or a different RAT. I want you to understand. For example, RAN which can be assumed to be using E-UTRA wireless technology In addition to being connected to 104, the core network 106 can also be assumed to be communicating with another RAN (not shown) that uses GSM radio technology.

The core network 106 can also act as a gateway for the WTRU 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 can include a circuit-switched telephone network that provides POTS (plain old telephone service). Internet 110 is an interconnected computer network and device that uses common communication protocols such as TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and IP (Internet Protocol) of the TCP / IP Internet Protocol suite. It can include systems from all over the world. The network 112 may include a wired or wireless communication network owned and / or operated by another service provider. For example, network 112 can include another core network connected to one or more RANs that may use the same or different RATs as RAN 104.

Some or all of the WTRU 102a, 102b, 102c, 102d within the communication system 100 can include multimode capabilities, i.e., the WTRU 102a, 102b, 102c, 102d are different radio networks over different radio links. Can include multiple transceivers to communicate with. For example, the WTRU 102c in Figure 1A can be configured to communicate with base station 114a, which can use cellular-based radio technology, and base station 114b, which can use IEEE 802 radio technology.

FIG. 1B is a system diagram of an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 has a processor 118, transceiver 120, transmit / receive element 122, speaker / microphone 124, keypad 126, display / touchpad 128, non-removable memory 130, removable memory 132, power supply 134. , Global Positioning System (GPS) chipset 136, and other peripherals 138 can be included. It should be understood that WTRU 102 can include any sub-combination of the aforementioned elements while remaining consistent with the embodiment.

Processor 118 is a general purpose processor, special purpose processor, conventional processor, digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit. It can be an (ASIC), field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), state machine, and so on. Processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that allows the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120 and the transceiver 120 can be coupled to the transmit and receive element 122. Although Figure 1B shows the processor 118 and transceiver 120 as separate components, it should be understood that the processor 118 and transceiver 120 may be integrated together in one electronic package or chip.

The transmit and receive element 122 can be configured to transmit or receive a signal from the base station (eg, base station 114a) via the air interface 116. For example, in one embodiment, the transmit and receive element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit and receive element 122 can be, for example, an emitter / detector configured to transmit and / or receive an IR signal, UV signal, or visible light signal. In another embodiment, the transmit and receive element 122 can be configured to transmit and receive both RF and optical signals. It should be understood that the transmit and receive element 122 can be configured to transmit and / or receive any combination of radio signals.

Further, although the transmit and receive elements 122 are illustrated as a single element in FIG. 1B, the WTRU 102 can include any number of transmit and receive elements 122. More specifically, the WTRU 102 can use MIMO technology. Thus, in one embodiment, the WTRU 102 can include a plurality of transmit and receive elements 122 (eg, a plurality of antennas) to transmit and receive radio signals over the air interface 116.

The transceiver 120 can be configured to modulate the signal transmitted by the transmit and receive element 122 and demodulate the signal received by the transmit and receive element 122. As noted above, the WTRU 102 can have multimode capabilities. Thus, the transceiver 120 can include multiple transceivers to allow the WTRU 102 to communicate over multiple RATs, such as UTRA and IEEE 802.11.

Processor 118 of the WTRU 102 can and will be coupled to a speaker / microphone 124, keypad 126, and / or display / touchpad 128 (eg, a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). Can receive user input data. Processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. In addition, processor 118 can access and store data from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), hard disk, or any other type of memory storage device. The removable memory 132 includes a SIM (subscriber identity module) card, a memory stick, and SD (secure). digital) Can include memory cards and the like. In other embodiments, processor 118 can access information from memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in it.

Processor 118 can receive power from power supply 134 and can be configured to distribute and / or control power to other components within WTRU 102. The power supply 134 can be any suitable device that shares power with the WTRU 102. For example, the power supply 134 may be one or more batteries (eg, nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells. And so on.

The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (eg, longitude and latitude) about the current position of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 receives location information from a base station (eg, base stations 114a, 114b) via air interface 116 and / or near multiple. The position can be determined based on the timing of the signal received from the base station. It should be understood that WTRU 102 can acquire position information by any appropriate position determination method while maintaining consistency with the embodiment.

Processor 118 can also be combined with other peripherals 138, which provide additional features, functionality, and / or wired or wireless connectivity with one or more software and / or Alternatively, it can include a hardware module. For example, peripherals 138 include accelerometers, e-compasses, satellite transceivers, digital cameras (for photos or videos), USB (universal serial bus) ports, vibrating devices, television transceivers, hands-free headsets, Bluetooth®. ) Modules, frequency modulation (FM) wireless units, digital music players, media players, video game player modules, internet browsers, etc. can be included.

FIG. 1C is a system diagram of the RAN 104 and the core network 106 according to one embodiment. As noted above, the RAN 104 can use E-UTRA radio technology to communicate with the WTRU 102a, 102b, 102c via the air interface 116. The RAN 104 can also communicate with the core network 106.

Although RAN 104 can include e-nodes B 140a, 140b, 140c, it should be understood that RAN 104 can include any number of e-nodes B, consistent with embodiments. The e-node B 140a, 140b, 140c can include one or more transceivers communicating with the WTRU 102a, 102b, 102c via the air interface 116, respectively. In one embodiment, e-nodes B 140a, 140b, 140c can implement MIMO technology. Thus, for example, the e-node B 140a can use multiple antennas to transmit and receive radio signals to the WTRU 102a.

Each of enodes B 140a, 140b, 140c can be associated with a specific cell (not shown) to handle radio resource management decisions, handover decisions, uplink and / or user scheduling on the downlink, etc. Can be configured as follows. As shown in Figure 1C, e-nodes B 140a, 140b, 140c can communicate with each other via the X2 interface.

The core network 106 shown in FIG. 1C can include an MME (Wireless Communication Mobility Management Device) 142, a serving gateway 144, and a PDN (Packet Data Network) gateway 146. Although each of the above elements is illustrated as part of the core network 106, that any one of these elements may be owned and / or operated by an entity other than the core network operator. I want to be understood.

The MME 142 can be connected to each of the e-nodes B 140a , 140b and 140c in the RAN 104 via the S1 interface and can act as a control node. For example, MME 142 may be responsible for authenticating users of WTRU 102a, 102b, 102c, bearer activation / deactivation, selection of specific serving gateways during initial attachment of WTRU 102a, 102b, 102c, etc. .. The MME 142 can also provide control plane functionality for switching between the RAN 104 and other RANs (not shown) that use other radio technologies such as GSM or WCDMA.

The serving gateway 144 can be connected to each of the e-nodes B 140a, 140b, 140c in the RAN 104 via the S1 interface. The serving gateway 144 generally routes and forwards user data packets to / from WTRU 102a, 102b, 102c. Serving gateway 144 anchors the user plane during e-node B handover, triggers paging when downlink data is available for WTRU 102a, 102b, 102c, manages the context of WTRU 102a, 102b, 102c and Other functions such as storage and analogs can also be performed.

The serving gateway 144 can also be connected to the PDN gateway 146, which goes to a packet-switched network such as the Internet 110 to facilitate the connection between the WTRU 102a, 102b, 102c and the IP-enabled device. Access can be given to WTRU 102a, 102b, 102c.

The core network 106 can facilitate communication with other networks. For example, the core network 106 provides access to circuit-switched networks such as the PSTN 108 to facilitate communication between the WTRU 102a, 102b, 102c and traditional land communication devices. Can be given to. For example, the core network 106 can include, or can communicate with, an IP gateway (eg, an IMS (IP Multimedia Subsystem) server) that acts as an interface between the core network 106 and the PSTN 108. In addition, core network 106 can provide WTRU 102a, 102b, 102c with access to network 112, which can include other wired or wireless networks owned and / or operated by other service providers. ..

A collaborative session, that is, a session that is divided across multiple WTRUs and anchored within SCC AC (Service Centralized and Continuity Application Server) can be established according to the inter-WTRU transfer procedure. When establishing a collaborative session, the WTRU that initiates the IUT (Inter-User Transfer) becomes the controller WTRU. The other WTRU included in the collaborative session becomes the controlee WTRU. Subsequent IUTs initiated by controller WTRU can also be performed within that collaborative session. SCC AS can provide coordination of collaborative session procedures that can include both controller WTRU and controller WTRU. The entire multimedia session can be transferred from one WTRU to another and / or replicated through device-to-device transfer and / or replication of a collaborative session.

Device-to-device transfer and / or replication procedures can be initiated by the WTRU based on information received from the target WTRU or via user input.

Figure 2 shows a system-level example of a replication scenario. The WTRU-1 201 can have a multimedia session with an audio-1 media flow and a video-1 media flow between the WTRU-1 201 and the remote party 203. The WTRU-1 201 can send a request to the WTRU-2 202 to duplicate the Video-1 media flow as a Video-2 media flow. One collaborative session can be established for replication. After successful replication, the WTRU-1 201 can retain control of the coordinated session control, the audio-1 media flow and the video-1 media flow can be that of the WTRU-1 201, IMS (IP (Internet Protocol) Multimedia Subsystem) networks can replicate Video-1 and Video-2 within WTRU-2 202. Video-1 media flow and Video-2 media flow can transfer the same video packet from remote party 203. WTRU-1 201 and WTRU-2 202 can belong to the same IMS subscription or different IMS subscriptions. Either WTRU-1 201 or WTRU-2 202 can request that Video-1 from WTRU-1 201 be replicated to itself.

Figure 3 shows a signaling diagram of an example of pull-mode session replication. With pull session replication, the second WTRU can request replication of the session in progress between the first WTRU and the remote party. After the replication procedure is complete, the session can be independent. Media A can be established between WTRU-1 301 and remote party 303 (305). WTRU-2 302 can obtain information about existing sessions and their media flows (306). WTRU-2 302 can use the obtained session information to send a session replication request to SCC AS 304 (307). This request can include information indicating that this is a session duplication request.

SCC AS 304 can request WTRU-1 301 to authorize a replication request, or SCC AS 304 can authorize a request on behalf of WTRU-1 301 (308). If the media request is approved, WTRU-2 302 can create a new session with remote party 303 (309). The state of the original media can be duplicated when establishing a new session. For example, the same playback state and the same used media can be duplicated. The flow may fail if the remote party 303 cannot support the setup of the replicated session. A new session in which Media is a replica of Media-A can be established between WTRU-2 302 and remote party 303 (310). Media A can be established between WTRU-1 301 and remote party 303 (311).

Figure 4 shows a signaling diagram of an example of push-mode media flow replication over a network. Coordinated session control can be established between controller WTRU 401 and SCC AS 404 (407). Media flow, media-A can be established between controller WTRU 401 and remote party 403 (408). The controller WTRU 401 can send a collaborative session IUT request to replicate media-A within the controller WTRU 402 to the S-CSCF (Serving-Call State Control Function) 405 (409). In the session setup request, the network identifies that the media to be replicated is Media-A, the source of the media flow to be replicated is controller WTRU 401, and the target of the media flow to be replicated is the control. It can be identified as WTRU 402 and contain sufficient information to maintain coordinated session control of Media-A within controller WTRU 401. After that, S-CSCF The 405 can forward coordinated session IUT requests to the SCC AS 404. The SCC AS 404 can verify that the controller WTRU 401 is an IUT subscriber and that the profile of the controller WTRU 401 allows the controller WTRU 401 to replicate media to the controller WTRU 402. Can (410). The SCC AS 404 can then verify that the controller WTRU 401 is an IUT subscriber and that the profile of the controller WTRU 401 allows the controller WTRU 401 to replicate the media flow to the controller WTRU 402. Yes (411).

SCC AS 404 can allocate media resources within MRF (media resource function) 406 for replicated media-A (412). The SCC AS 404 can then send a request to establish an access leg with the controller WTRU 402 for Media-A (413). The SCC AS 404 can then update the access leg on controller WTRU 401 for replicated media flow, Media-A using MRF 406 (414). The SCC AS 404 can then update the remote leg to communicate with Media-A using MRF 406 (415). Media-A can be established between the controllers WTRU 401 and MRF 406 (416), between the controller WTRU 402 and MRF 406 (418), and between the remote parties 403 and MRF 406 (417). it can.

Further authorization steps on the SCC AS 404 and Control WTRU 402, assuming that the Controller WTRU 401 and Control WTRU 402 are also part of a different subscription, assuming that the Control WTRU 402 is also an IUT WTRU / Subscriber. May be required.

Figure 5 shows a signaling diagram of an example of pull-mode media flow replication over a network. Coordinated session control can be established between controller WTRU 501 and SCC AS 504 (507). Media flow, media-A can be established between controller WTRU 501 and remote party 503 (508). The controller WTRU 502 can send a collaborative session IUT request that replicates media-A within the controller WTRU 502 to the S-CSCF 505 (509). In the session setup request, the network identifies that the replicated media flow is Media-A, the source of the replicated media flow is controller WTRU 501, and the target of the replicated media flow is It can identify that it is a controller WTRU 502 and contain information to maintain coordinated session control of Media-A within controller WTRU 501. The S-CSCF 505 can forward collaborative session requests to the SCC AS 504 (510). SCC AS 504 then verifies that the controller WTRU 502 is an IUT subscriber and that the profile of controller WTRU 501 allows the controller WTRU 502 to replicate media flows from controller WTRU 501. Can be (511).

The SCC AS 504 can then allocate media resources for the duplicated media-A (512). The SCC AS 504 can then send the response to the S-CSCF 505 (513). The S-CSCF 505 can forward this response to the controller WTRU 502 (514). SCC AS 504 can update the access leg on controller WTRU 501 for replicated media flow, Media-A using MRF 506 (515). The SCC AS 504 can then update the remote leg to communicate with Media-A using MRF 506 (516). Media-A can be established between controllers WTRU 501 and MRF 506 (517), between controller WTRU 502 and MRF 506 (519), and between remote parties 503 and MRF 506 (518). it can.

The remote party may have the authority to deny or authorize session replication. You can configure a remote party not to share a session with another party. For example, the remote party may not share the session because the session may contain sensitive information or because the remote party cannot identify the user of the WTRU requesting replication.

The P-CSCF (Proxy-Call State Control Function) to which the remote party is connected can refuse further session replication based on the judgment made by the PCC (policy and charging control) function. For example, the PCC feature may exceed the number of concurrent sessions that a remote party can be involved in, exceed the maximum bandwidth allocated to a remote party subscription, or the policy may limit session replication or session. It can be identified that it imposes a limit on the maximum number.

If WTRU-2 has IUT replication capability, the SCC AS may be in the path. SCC AS may deny requests for replication either from WTRU-2 or towards WTRU-2 based on subscription, operator policy, or user preferences.

FIG. 6 shows a signaling diagram of the first example of authorizing a replication request. Media flow, media-A, can be established between WTRU-1 601 and remote party 603 (606). WTRU-2 602 can request information about existing media sessions from SCC AS 604 (607). WTRU-2 602 can request pull mode session replication from SCC AS 604 (608). The SCC AS 604 can then perform replication request authorization (609). The SCC AS may reject the replication request (610 (a)) or request WTRU-1 601 to authorize the replication request (610 (b)).

WTRU-1 601 can reject the replication request (611 (a)) or allow the replication request (611 (b)). If the copy request is denied, this process can be restarted from the beginning and, in some embodiments, not reverted to the previous step. The WTRU-2 602 can then create a replication session with the remote party 603, provided that the replication request is allowed (612). A P-CSCF (the first entity in IMS that WTRU-1 601 signals directly) that works for remote party 603 or remote party 603 can reject the request (613 (a)) or The remote party 603 can proceed to establish a session with WTRU-2 602 (613 (b)). Media-A replication can then occur between WTRU-2 602 and remote party 603 (614). Media-A can then be established between WTRU-1 601 and remote party 603 (615).

FIG. 7 shows a signaling diagram of a second example of authorizing a replication request. Media flow, media-A, can be established between WTRU-1 701 and remote party 703 (706). Replicated media A is established between WTRU-2 702 and remote party 703 (707). The WTRU-3 705 can request information about existing media sessions from the SCC AS 704 (708). The WTRU-3 705 can request pull mode session replication to replicate media from the WTRU-2 702 (709). The SCC AS 704 can then perform replication request authorization (710). SCC AS 704 can either reject the replication request (711 (a)) or request the WTRU-2 702 to authorize the replication request (711 (b)).

The WTRU-2 702 can reject the replication request (712 (a)) or allow the replication request (712 (b)). If the copy request is denied, this process can be restarted from the beginning and, in some embodiments, not reverted to the previous step. SCC AS 704 may request WTRU-1 701 to approve the request for replication because the original session was on WTRU-1 701, provided that the replication request is allowed (713). .. The WTRU-1 701 can reject the replication request (714 (a)) or allow the replication request (714 (b)). The WTRU-3 705 may create a replicated session with the remote party 703, provided that the replication request is allowed (715). A P-CSCF working for remote party 703 or remote party 703 can reject the request (716 (a)), or remote party 703 may proceed to establish a session with WTRU-3 705. Yes (716 (b)). Media-A, WTRU-3 It can be established between the 705 and the remote party 703 (717), between the WTRU-2 702 and the remote party 703 (718), and between the remote party 703 and the WTRU-1 701 (719).

After replication, the session between WTRU-2 and the remote party is the same as the session between WTRU-1 and the remote party, but can be independent. Therefore, WTRU-2 may be able to perform IUT of the entire session or media component to transfer the session to a different WTRU.

The WTRU-1 or remote party may not want such a transfer to occur due to the nature of the session or because it does not know to which WTRU the session is about to be transferred. Therefore, SCC AS can regulate transfers to prevent IUT to hostile devices or users. WTRU-1 and remote parties can also be given the opportunity to reject such IUT attempts. Therefore, if WTRU-2 sends a request for inter-WTRU transfer of a session or some or all media to WTRU-3, WTRU-1 can be informed of this attempt. WTRU-1 can instead store a profile in the SCC AS that allows such authorization to be performed. When a remote party gets a session update as a result of an IUT, the remote party can reject or accept such an update for the session.

FIG. 8 shows an exemplary authorization signaling diagram of the IUT after replication. Media flow, media-A, can be established between WTRU-1 801 and remote party 803 (806). Replicated media A is established between WTRU-2 802 and remote party 803 (807). The WTRU-2 802 can send a push mode IUT request to the SCC AS 804 to forward the media, or media-A, to the WTRU-3 805 (808). SCC AS 804 can perform replication request authorization (809). SCC AS 804 can reject the replication request (810 (a)) or request WTRU-1 801 to authorize the replication request (810 (b)).

WTRU-1 801 can reject the replication request (811 (a)) or allow the replication request (811 (b)). If the replication request is denied, the process is restarted from the beginning and does not return to the previous step. The WTRU-2 802 can perform the IUT procedure, provided that the replication request is allowed (812). The P-CSCF working for the remote party 803 or remote party 803 can reject the request (813 (a)), or the remote party 803 can proceed to establish a session with SCC AS 804. (813 (b)). Coordinated sessions can be established between WTRU-2 802 and WTRU-3 805 (814). Media-A can then be transferred between the remote party 803 and the WTRU-3 805 (815). Media-A can be established between WTRU-1 801 and remote party 803 (816).

Figure 9 shows a signaling diagram of an example of authorization for replication by a network using push mode. Coordinated session control can be established between controller WTRU 901 and SCC AS 905 (907). A media session, Media-A, can be established between controller WTRU 901 and remote party 903 (908). The controller WTRU 901 can send an IUT request to the S-CSCF 905 that replicates Media-A to the controller WTRU 902 (909). The S-CSCF 905 can forward an IUT request to the SCC AS 904 that replicates Media-A to the controller WTRU 902 (910). SCC AS 904 can authorize whether controller WTRU 901 can request replication based on operator policy and subscription limits (911). SCC AS 904 can allocate media resources for replicated media-A (912).

The controller WTRU 902 can accept or reject requests for duplication. The Controlli WTRU 902 can reject the request for duplication either because it is too busy to undertake further sessions or because it lacks the required capabilities. Subject to the request being accepted, SCC AS 904 may send a request to establish the Media-A access leg with the controller WTRU 902 (913). The SCC AS 904 can then update the replicated media flow using MRF 906, the access leg on Media-A's controller WTRU 901 (914). The SCC AS 904 can then update the remote leg to communicate with Media-A using MRF 906 (915). The remote party 903 may not want to duplicate a media session due to the confidential nature of the session or because it does not know the user of the control WTRU 902. Media, controller WTRU 901 and MRF It can be established between 906 (916), between Controlli WTRU 902 and MRF 906 (918), and between remote party 903 and MRF 906 (917).

After the media has been duplicated, the operator policy and / or subscription limit limits how many times the same media can be duplicated and to which WTRU it can be transferred, if possible. Can be imposed. The original session participant, controller WTRU 901, and remote party 903 can be notified of additional actions to be taken against the replicated media session.

Figure 10 shows a signaling diagram of an example of authorization for replication by a network using pull mode. Coordinated session control can be established between controller WTRU 1001 and SCC AS 1004 (1007). A media session, Media-A, can be established between controller WTRU 1001 and remote party 1003 (1008). A collaborative session request that replicates Media-A within the controller WTRU 1002 can be sent to the S-CSCF 1005 (1009). The S-CSCF 1005 can forward an IUT request that replicates Media-A to the controller WTRU 1002 to the SCC AS 1004 (1010). SCC AS 1004 can authorize whether controller WTRU 1001 can request replication based on operator policy and subscription limits (1011). The SCC AS 1004 can then allocate the replicated media-A media resources (1012). Then SCC AS 1004, MRF A response regarding media-A in 1006 can be sent to S-CSCF 1005 (1013). The S-CSCF 1006 can then forward the response for media-A within the MRF 1006 to the controller WTRU 1002 (1014).

Controller WTRU 1001 can accept or reject replication requests. The controller WTRU 1001 can reject the request for replication because it does not know the user of the controller WTRU 1002 or may not want to share sensitive information. SCC AS 1004 can update the access leg on the duplicated media flow, Media-A controller WTRU 1001 with MRF 1006, provided that the request is granted (1015). The SCC AS 1004 can then exercise a remote leg to communicate with Media-A using the MRF 1006 (1016). The remote party 1003 may not want to duplicate a media session due to the confidential nature of the session or because it does not know the user of the control WTRU 1002. Media between controllers WTRU 1001 and MRF 1006 (1017), between controller WTRU 1002 and MRF 1006 (1019), and remote parties 1003 and MRF. It can be established between (1018) with 1006.

After the media has been duplicated, the operator policy and / or subscription limit limits how many times the same media can be duplicated and to which WTRU it can be transferred, if possible. Can be imposed. The original session participant, controller WTRU 1001, and remote party 1003 can be notified of additional actions to be taken against the replicated media session.

When the SCC AS receives an IUT request from the WTRU, it differs from the SIP (Session Initiated Protocol) message to identify whether it is a media or session replica or a media or session transfer. can do. For transfers, the media can come from the controller WTRU, remote parties, or both. After the transfer, the media results from the control WTRU, the remote party, or both. In contrast, with respect to replication, media can arise from a remote party for network replication, except when the MRF replicates the media flow from the controller WTRU to the controller WTRU.

An explicit way to distinguish between transfer and replication is to include a specific header field to indicate which session is being replicated. Therefore, headers such as the "Replicate Header Field" may be standardized to include the dialog identifier (ID) of the session being replicated.

SDP (session description protocol) can use media level i lines to indicate that media is replicated. The "i =" field is intended to provide a free-form, human-readable description for the purpose of the session or media stream. This may not be appropriate for the automaton to analyze. In one embodiment, for example, "i = replicate" can be standardized. The value "i = transfer" can be used to explicitly indicate the transfer of the media component. Alternatively, a new "a" attribute can be defined to indicate "transfer" or "replicate" for each media component. For example, the new "a" attribute could be "a = replicate". This attribute can be included at the media level to identify a particular media component to be replicated, or at the session level to indicate that the entire session, including all media components, is replicated.

In addition, replication can be demonstrated by including the XML (eXtensible Markup Language) body in the replication request. This request may include information that a media component or the entire session will be replicated. The XML body can also contain information about which media components are replicated. For example, the information that can be included in the XML body is that the media and / or session is replicated and can include the originator of the media and / or session, the identity of the requester of the replication, and the replication is network or remote party. It can be determined by which one is desired to be performed, whether a particular media flow is replicated, or whether the entire session is replicated. The session ID of the duplicated session or the media flow within that session can also be included in the XML body.

FIG. 11 shows a signaling diagram of the use of the replication indicator. Media flow, media-A, can be established between WTRU-1 1101 and remote party 1103 (1105). WTRU-2 1102 can request information about existing sessions (1106). WTRU-2 1102 can send a pull-mode session replication request to SCC AS 1104 (1107). For example, this request can be made to a replicate header field with a dialog-ID for an existing session between WTRU-1 1101 and remote party 1103, a media-level "i =" or "a =" field with a replicate value, Or it can be an invite that can contain either a media component or an XML body that indicates whether the entire session is replicated. A combination of one or both of these indicators can be included in the SIP request for replication.

SCC AS 1104 can perform replication request authorization (1108). The SCC AS 1104 can send a request for authorization of the request for replication to WTRU-1 1101 (1109). For example, this request can be an UPDATE request. WTRU-1 can allow replication requests (1110). SCC AS 1104 can create replicated sessions (1111). The replication indicator included in the replication request can also be included in the SIP message (1110 and 1111). Remote party 1103 can proceed to establish a session (1112). Duplicate media-A can be established between WTRU-2 1102 and remote party 1103 (1113). Media-A can be established between WTRU-1 1101 and remote party 1103 (1114).

Figure 12 shows a signaling diagram of replication over a network using the replication indicator and push mode. Coordinated session control can be established between the controllers WTRU 1201 and SCC AS 1204 (1207). Media flow, or media-A, can be established between controller WTRU 1201 and remote party 1203 (1208). Controller WTRU 1201 can send an IUT request to S-CSCF 1205 to replicate media-A to controller WTRU 1202 (1209).

This replication request is likely to be a REFER request. Within the Refer-To header, you can include a Replicated header field that contains the dialog-ID of the session being replicated. If certain media components are replicated, they can be presented in the same way as a normal IUT transfer request. Otherwise, one of the following indicators for replication, namely the "i =" or "a =" field attached to each media description contained in the Refer-To header field, or which session ( You can use a dialog-ID) or an XML body that indicates which media component will be replicated.

S-CSCF 1205 can forward IUT requests to SCC AS 1204 to replicate media-A to control WTRU 1202 (1210). SCC AS 1204 can perform replication request authorization (1211). SCC AS 1204 can then allocate media resources for replicated media-A (1212). The SCC AS 1204 can then send a request to establish an access leg on Media-A's control WTRU 1202 (1213). The SCC AS 1204 can then update the duplicated media flow using MRF 1206, the access leg on the media-A controller WTRU 1201 (1214). The SCC AS 1204 can then update the remote leg to communicate with Media-A using MRF 1206 (1215).

Duplicate views can also be included in requests to establish an access leg, access leg updates, and remote leg updates. When the Replicate header field is used, in a re-INVITE or UPDATE message, the header appears as a regular header field and contains the dialog-ID of the session being replicated. SDP indicators can be included in offers and / or answers. The XML body can be a regular SIP message body. Media can then be established between controllers WTRU 1201 and MRF 1206 (1216), between controller WTRU 1202 and MRF 1206 (1218), and between remote parties 1203 and MRF 1206 (1217). it can.

Figure 13 shows a signaling diagram of replication over a network using the replication indicator and pull mode. Coordinated session control can be established between controller WTRU 1301 and SCC AS 1304 (1307). Media flow, media-A can be established between controller WTRU 1301 and remote party 1303 (1308). The controller WTRU 1302 can send a collaborative session request to the S-CSCF 1305 that replicates media-A within the controller WTRU 1302 (1309).

This replication request is likely to be an INVITE request. You can include a Replicated header field that contains the dialog-ID of the session to be replicated. If certain media components are replicated, they can be included in the offer. Instead, one of the following indicators for replication, namely the "i =" or "a =" field attached to each media description contained in the SDP, or which session (dialog-ID) Alternatively, you can use the XML body, which indicates which media component will be replicated.

The S-CSCF 1305 can forward a collaborative session request that replicates Media-A within the controller WTRU 1302 to SCC AS 1304 (1310). SCC AS 1304 can perform replication request authorization (1311). SCC AS 1304 can then allocate media resources for replicated media-A (1312). SCC AS 1304 can send a response about media-A in MRF 1306 to S-CSCF 1305 (1313). The S-CSCF 1305 can forward the response for media-A in the MRF 1306 to the controller WTRU 1302 (1314). SCC AS 1304 can update the replicated media flow using MRF 1306, the access leg on Media-A's controller WTRU 1301 (1315). Then SCC AS 1304, MRF Media with 1306-The remote leg can be updated to communicate with A (1316). Media can then be established between controllers WTRU 1301 and MRF 1306 (1317), between controller WTRU 1302 and MRF 1306 (1319), and between remote parties 1303 and MRF 1306 (1318). it can.

Those skilled in the art will appreciate that features and elements are described above in particular combinations, but each feature or element can be used alone or in any combination with other features and elements. Let's do it. In addition, the methods described herein can be performed with computer programs, software, or firmware embedded in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks and magnetic media such as removable disks, optical magnetic media, and CD-ROM disks. And include, but is not limited to, optical media such as digital multipurpose discs (DVDs). Software-related processors can be used to implement radio frequency transceivers used within WTRUs, UEs, terminals, base stations, RNCs, or any host computer.

<u style="single">Embodiment</u> 1. A method of duplicating a media session within SCC AS (Service Centralized and Continuity Application Server). Step of receiving a coordinated replication session invite request from the second WTRU (wireless transmit / receive unit) A method characterized by including.

2. Steps to execute authorization of co-replication session invite request The method according to the first embodiment, which further comprises.

3. Steps to allocate media resources for duplicated media flows The method according to the first and second embodiments, which further comprises.

4. Steps to send the response of the replicated media flow in the MRF (media resource function) to the second WTRU The method according to the first to third embodiments, which further comprises.

5. Steps to update the access leg on the first WTRU of the replicated media flow using MRF The method according to the first to fourth embodiments, which further comprises.

6. Steps to update the remote leg of the replicated media flow in the MRF The method according to the first to fifth embodiments, which further comprises.

7. The method according to embodiment 1-6, wherein the replication session invite request includes a replicate header field.

8. The method according to embodiment 7, wherein the replicate header field is a media level "i = replicate" field.

9. The method according to embodiment 7, wherein the replicate header field is a media level "a = replicate" field.

10. The method according to embodiment 7, wherein the replicate header field is an XML body.

11. The method of embodiment 10, wherein the XML body indicates which media component or entire session is replicated.

12. A method of replicating a media session within SCC AS (Service Centralized and Continuity Application Server). Step of receiving a request for information about an existing media flow from a second WTRU (wireless transmit / receive unit) A method characterized by including.

13. Steps to receive replication session invite request from second WTRU 12. The method according to embodiment 12, further comprising:

14. Steps to perform session invite replication request authorization 12 to 13, wherein the method further comprises.

15. Step to send a request to authorize a session invite replication request to the first WTRU 12 to 14, wherein the method further comprises.

16. Steps to Receive Allowed Replication Request from First WTRU The method according to embodiment 12 to 15, further comprising.

17. Steps to create a duplicated media flow The method according to embodiment 12 to 16, further comprising.

18. The method according to embodiment 12-17, wherein the replication session invite request includes a replicate header field.

19. The method according to embodiment 18, wherein the replicate header field is a media level "i = replicate" field.

20. The method according to embodiment 18, wherein the replicate header field is a media level "a = replicate" field.

21. The method according to embodiment 18, wherein the replicate header field is an XML body.

22. The method of embodiment 21, wherein the XML body indicates which media component or entire session is replicated.

23. A method of duplicating a media session within a WTRU (wireless transmit / receive unit). Steps to send a request for information about an existing media flow to a Service Centralized and Continuity Access Server (SCC AS) A method characterized by including.

24. Steps to receive information about existing media flows from SCC AS 23. The method of embodiment 23, further comprising:

25. Steps to send a replication session invite request to SCC AS 23 to 24. The method according to embodiment 23 to 24, which further comprises.

26. Steps to Receive Allowed Replication Request from SCC AS 23 to 25, wherein the method further comprises.

27. Steps to create a replicated media flow with a remote party 23 to 26, wherein the method further comprises.

28. The method of embodiments 23-27, wherein the replication session invite request comprises a replicate header field.

29. The method according to embodiment 28, wherein the replicate header field is a media level "i = replicate" field.

30. The method according to embodiment 28, wherein the replicate header field is a media level "a = replicate" field.

31. The method according to embodiment 28, wherein the replicate header field is an XML body.

32. The method of embodiment 31, wherein the XML body indicates which media component or entire session is replicated.