KR100898869B1 - Session modification procedure for a multicast push-to(pt) service - Google Patents

Abstract

A session modification procedure for a multicast push-to (PT) service and a terminal supporting the same are provided. In the session modification procedure according to an embodiment of the present invention, when it is detected that a terminal undergoing a PT group session through a multicast channel moves from a multicast service area to a non-multicast service area, the session modification procedure is performed. Create a request message requesting the switch and send it to the PT server. This request message may use the SIP UPDATE method or the SIP re-INVITE method. When receiving a response message, eg, SIP 200 OK, for the request from the PT server, the terminal disconnects the multicast channel and receives and processes the media data through the switched PT one-to-one session.

Description

Session modification procedure for a multicast Push-To (PT) service}

The present invention relates to a Push-To (PT) service, and more particularly, to a Session Modification or Session Switch procedure for a multicast PT service.

The PT service is one of session-based communication services in which one terminal, which has a voice or a transmission right, transmits data to one or more remaining terminals among a plurality of terminals that establish a session. The PT service may include a push-to-talk (PTT) service for transmitting voice data and providing a call service according to the type of data to be transmitted, a push-to-video (PTV) service for transmitting image or video data, And it can be divided into PTD (Push-To Data) service for transmitting various data including text. This PT service can provide two-way communication quickly by simple terminal operation without the process of dialing or waiting for a telephone connection, and it is not only one-to-point communication but also one-to-multipoint. It can also support communication.

One-to-many communication typically includes both multicast transmissions and broadcast transmissions, but broadcast transmissions are a special form of multicast transmissions. Therefore, even if the term 'multicast' or 'broadcast' is simply used herein, it may be interpreted to refer to both 'multicast' and 'broadcast' except when it is not applicable in nature.

The multicast PT service is provided by a source terminal for the target terminals when a plurality of destination terminals (eg, terminals subscribed to a specific PT group) are located in a specific area. One of PT services for transmitting data through a multicast channel or broadcast channel. In the multicast PT service, a downlink stream is generated for a plurality of target terminals through a common multicast channel or broadcast channel instead of an individually allocated dedicated channel. By collectively transmitting, it is possible to improve the use efficiency of radio resources. On the other hand, the multicast PT service may be somewhat weak in security, and in order to transmit media data in a multicast manner, a separate functional entity for this purpose must be provided in the network server.

Such a multicast PT service generally has some service coverage. That is, in the multicast PT service, not all target terminals participating in the PT group session can receive the downlink stream through the multicast channel, and the downlink stream is transmitted through the multicast channel only when located in a predetermined area. I can receive it. This is due to the policy of the multicast PT service for providing an efficient service only to terminals within a certain area participating in the PT group, and the size of the service coverage may vary depending on the characteristics of the service or the type of the PT group. Hereinafter, an area included in the multicast PT service coverage is referred to as a 'multicast service area', and an outside area thereof is referred to as a non-multicast service area.

It should be noted that the distinction between the multicast service area and the non-multicast service area is based on whether a downlink stream can be received through a multicast channel, and is not based only on geographical boundaries. In addition to the geographical conditions, other conditions (eg, the channel state of the multicast channel or the presence of obstacles) may also be a criterion for distinguishing the multicast service region from the non-multicast service region.

As such, the target terminal participating in the PT group session can receive media data and the like through the multicast channel only when located in the multicast service area, and through the multicast channel in the non-multicast service area. Can't receive. However, in consideration of the mobility of the terminal or the flexible channel environment, the terminal in the multicast service area may move to the non-multicast service area, or conversely, the terminal in the non-multicast service area may enter the multicast service area. have. In the former case, the terminal can no longer receive the downlink stream transmitted over the multicast channel, and in the latter case the terminal can only receive the downlink stream over the multicast channel.

As such, due to the characteristics of the multicast PT service, even though the terminal participates in the PT group session, some terminals may or may not receive the downlink stream through the multicast channel depending on their location. However, the terminal participating in the PT group session should continue to receive data provided by the source terminal, regardless of whether the location is a multicast service area or a non-multicast service area. Therefore, in the multicast PT service, when a mobile station moves between the multicast service area and the non-multicast service area, a procedure for continuously receiving a downlink stream is required, but the current multicast The PT service procedure does not specify this in detail.

One problem to be solved by the present invention is a procedure for a case where a terminal receiving data or the like through a multicast channel in a multicast service area in a multicast PT service moves to a non-multicast service area and a terminal supporting the same. To provide.

Another problem to be solved by the present invention is to provide a procedure for a case where a terminal located in a non-multicast service region in a multicast PT service moves to a multicast service region, and a terminal for the same.

Another problem to be solved by the present invention, when a terminal moves from a multicast service area to a non-multicast service area or a multicast service area to a multicast service area in a multicast PT service, The present invention provides a procedure and a terminal for supporting the downlink stream which are received before moving even through different channels without disconnection after moving.

In the session modification procedure according to an embodiment of the present invention for solving the above problems, a service area is changed between a multicast push-to service area and a non-multicast PT service area. Detecting a change, establishing a session to be used in the changed service area by communicating with the PT server, and when detecting that the change is made from the multicast PT service area to the non-multicast PT service area, the multicast channel. Disconnecting for; And receiving media data via the established session.

A terminal according to an embodiment of the present invention for solving the above problems is a processor designed to generate and process a message, and a transceiver that is functionally connected to each of the processor and is designed to transmit and receive the message for the processor, respectively And detecting a movement from the multicast service area to the non-multicast service area during the progress of a Push-To (PT) group session through a multicast channel, the PT to be used in the non-multicast service area. Generating a request message including a Session Description Protocol (SDP) offer for a one-to-one session and requesting a switch to the PT one-to-one session to a PT server, and sending the request from the PT server Upon receiving a response message to the message, the multicast channel Disconnect and process media data via the PT one-to-one session.

A terminal according to another embodiment of the present invention for solving the above problems is a processor designed to generate and process a message, and a transceiver that is functionally connected to each of the processor and is designed to transmit and receive the message for the processor respectively. As a terminal comprising a, if it detects the movement from the non-multicast service area to the multicast service area during the Push-To (PT) one-to-one session, for the PT group session to be used in the multicast service area Generating and sending a request message including a Session Description Protocol (SDP) offer or requesting to switch to the PT group session, and upon receiving a response message to the request message, the PT Media data can be delivered over a multicast channel for a group session. And processes.

According to the above-mentioned problem solving means, when a terminal establishing a PT group session moves from a multicast service area to a non-multicast service area, the terminal performs session switching to a PT one-to-one session through communication with a PT server. Thus, the downlink stream can be continuously received using its own dedicated channel. When the terminal establishing the PT one-to-one session is moved from the non-multicast service area to the multicast service area, a procedure for switching to a PT group session is performed to provide information on the multicast channel and the multicast channel to the PT server. By acquiring SDP information and the like necessary for receiving the downlink stream through the downlink stream, the downlink stream can be received through the multicast channel. In the latter case, the PT server no longer needs to transmit media data or the like individually through the dedicated channel for the terminal.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. Each Session Initiation Protocol (SIP) message and transport protocol illustrated in the embodiments described below is in accordance with the contents described in the standard documents of POC 1.0 and 2.0 of the Internet Engineering Task Force (ITEF) and Open Mobile Alliance (OMA). In this specification, a detailed description thereof will be omitted.

1 is a block diagram showing an example of a network configuration for a general PT service. As can be seen with reference to Figure 1, there are many components in the network for PT services, in this specification, the creation of a PT group for the general PT service and the session invitation to the members of the generated PT group, and Only network components necessary to describe a session modification procedure for a multicast PT service to be described below will be briefly described, and descriptions of other components will be omitted. The detailed functions or operations of components not described herein or components described briefly are described in the POC 1.0 and 2.0 standard documents of the Open Mobile Alliance (OMA) (eg, "Push to talk over Cellular (PoC)-Architecture"). (Approved Version 1.0.1-28 Nov 2006), etc.).

Referring to FIG. 1, a typical PT service network includes a terminal (Terminal 10), an aggregation proxy (40), a PT database server (PT XDMS, 50), and a PT server (PT Server, 60). do. The terminal 10 is a user device using PT service generation and PT service through a PT session (PT one-to-one session and / or PT group session). The terminal 10 includes an XDM client 11 requesting the creation of a PT group and a PT client 12 that generates a PT session and participates in an existing PT session and terminates the PT session. The PT server 60 performs a function of maintaining and managing a PT session for the PT service, and controls a voice or data transmission authority for the PT service, and the PT database server 50 is a PT group and a PT. In addition to storing information about each user of the group, the aggregation proxy 40 also connects to the PT database server 50 to generate the PT group document requested by the terminal 10.

The general PT service network further includes an access network 20 and a SIP (Session Initiation Protocol) / IP (Internet Protocol) core. The access network 20 is for performing a connection function of packet-based communication between the terminal 10 and the SIP / IP core 30, but is not limited thereto. The SIP / IP core 30 routes the SIP message for the PT service between the terminal 10 and the PT server 60 or between different PT servers 60. However, in the following description and description of the access network 20 or SIP / IP core 30 will be omitted in order to clarify the technical spirit of the present invention.

Next, the configuration of the system for the multicast PT service to which the embodiment of the present invention can be applied and the function of each of the components will be described.

FIG. 2 is a block diagram showing an example of a system for a multicast PT service to which an embodiment of the present invention can be applied, and assumes a network configuration for the general PT service shown in FIG. 1. In FIG. 2, illustration of components not directly related to an embodiment of the present invention is omitted. Referring to FIG. 2, the multicast PT service system includes a multicast PT group 100, a PT server 200, and a source terminal 400.

The target terminals 110, 120, 130 and the source terminal 400 included in the multicast PT group 100 are examples of the terminal 10 of FIG. 1, respectively, and may be terminals that all join the same PT group. . The multicast PT group 100 is a set of terminals participating in a PT group session and also supporting a multicast PT service, and a set of terminals capable of receiving a downlink stream transmitted through a multicast channel within service coverage. to be. However, even if included in the multicast PT group 100, if it is located in the non-multicast service area, the downlink stream cannot be received through the multicast channel. The source terminal 400 is a terminal that provides media data and the like for other terminals joining the same PT group, for example, target terminals 110, 120, and 130 included in the multicast PT group 100.

The target terminals 110, 120, and 130 of the multicast PT group 100 may each receive a downlink stream through a PT one-to-one session or through a multicast channel. More specifically, among the target terminals 110, 120, and 130, the terminal (eg, the first terminal indicated by reference numeral 110 ′) located in the non-multicast service area may access the downlink stream only through its own dedicated channel. Can be received. On the other hand, terminals located in the multicast service area among the target terminals 110, 120, and 130 may receive a downlink stream through a dedicated channel for each or a common multicast channel. However, depending on the policy of the service provider, when the terminal is located in the multicast service area, downlink may be restricted from using a dedicated channel or a higher priority may be given to using the multicast channel. Only exemplary.

Among the target terminals 110, 120, and 130 joining the multicast PT group 100, all or some of the terminals, for example, the first terminal 110, are initially located in the multicast service area and then moved to the non-multicast service area. It may move (110 → 110 ') or, conversely, it may be located in the non-multicast service area and then enter the multicast service area (110' → 110). Therefore, the first terminal 110 ′ located in the non-multicast service area cannot receive the downlink stream through the multicast channel, but can receive the downlink stream only through the dedicated channel. On the other hand, the first terminal 110 located in the multicast service area can receive the downlink stream through the multicast channel, and can typically receive the downlink stream through its own dedicated channel.

In addition, according to an embodiment of the present invention, the target terminals 110, 120, and 130 may be located in the multicast service area or in the non-multicast service area by using a periodically received system information message. I can figure out if it is located. When the target terminals 110, 120, and 130 use the increase or decrease of the signal size of the system information message, the target terminals 110, 120, and 130 are inside the multicast service area and then move out of the multicast service area or move from the non-multicast service area to the multicast service area. Can detect or know. According to the embodiment of the present invention, the use of the system information message is merely exemplary, and there is no particular limitation on a method of detecting the location or detecting the location movement of the terminal in relation to the multicast PT service.

The target terminals 110, 120, 130 and the source terminal 400 joining the multicast PT group 100 each connect to a mobile communication network to communicate with a functional entity on the network such as another terminal or PT server 200. As a user device for doing so, there is no particular limitation on the name. For example, the terminals 110, 120, 130, and 400 may include a wireless transmit / receive unit (WTRU), a user equipment (UE), a mobile station (MS), a mobile terminal (Mobile). It may also be called another name, such as a terminal, a station, or a mobile subscriber unit.

Each of the terminals 110, 120, 130, and 400 includes at least a transceiver and a processor. The transceiver is an entity for allowing the terminals 110, 120, 130, and 400 to transmit and receive various signals and data through a wireless network such as a mobile communication network. The processor controls the operation of the terminal and generates or decrypts a message to be transmitted and received through the transceiver and performs processing accordingly. The processor of the terminals 110, 120, 130, and 400 according to an embodiment of the present invention includes a controller and a PT client. The controller is an entity for controlling the operation of functional entities (eg, PT clients, user interfaces (UIs), transceivers, etc.) inside the terminal.

The PT client (reference numeral '12' in FIG. 1) may interact with other components of the PT service system, such as the PT server 200, so that other functional entities on the PT service system (e.g., It is a functional entity that establishes a PT session with the PT server 200 or the source terminal 400, performs various procedures for managing and modifying the established PT session, and joins and leaves a PT group session. To this end, the PT client is responsible for generating a variety of requests and responses according to a predetermined communication protocol, such as Session Initiation Protocol (SIP), SIP / IP core (reference numeral '30' in Figure 1) You can use the relevant functions provided by).

The PT client receives, stores and manages security and logic related functions of the client side related to the multicast PT service, such as a security key for the multicast PT service. In addition, the PT client decrypts the encrypted data or the encrypted security key received through the multicast channel using the stored or received security key.

PT server 200 (reference numeral '60' of FIG. 1) configures PT service system to provide PT service for terminals 110, 120, 130, and 400, and to realize PT service provider policy. It is one of network servers that perform communication between functional entities and management and control functions of PT service subscribers. In order to perform this function, PT server 200 communicates with other functional entities on the network (e.g., a PT database server (reference numeral '50' in FIG. 1) for storing PT service subscriber information or other data). It communicates with terminals 110, 120, 130, and 400 via a SIP / IP core (reference number '30' of Fig. 1) and / or access network (reference number '20' of Fig. 1). 200 performs general signaling control for establishing, managing, terminating, and / or updating a PT group session with terminals 110, 120, and 130 joined to the multicast PT group 100. In addition, the PT server 200 receives data from the source terminal 400, and transmits the data individually through a PT one-to-one session for each target terminal 110, 120, or 130 or delivers the data to the BDS 212 to multicast. It can also be transmitted through a channel.

The PT server 200 may be classified into a PT participant function (Participating Function, PF, 210) and a PT control function (CF, 220) according to its logical function. The PT participation function 210 sets up, manages, and controls sessions and media according to service capabilities, user preferences, service provider policies, etc., and also processes messages for the terminals 110, 120, 130, and 400. do. For example, the PT participation function 210 registers a PT client for users, performs processing for initiating, modifying and terminating a PT session with a PT client that registers or requests registration, and the service provider in the PT session. You can apply your policies or your preferences. The PT control function 220 provides centralized session processing, media distribution, voice control, policy and participant information for participation in a group session. This division of the PT participation function 210 and the PT control function 220 is merely a logical division, and may be physically integrated into one or implemented separately.

In addition, the PT server 200 is a functional entity or system for transmitting a downlink stream through a multicast channel or a broadcast channel for target terminals 110, 120, and 130 joined to the multicast PT group 100. Phosphorus BDS 212. BDS 212 is a functional entity or system for a multicast PT service having the ability to transmit the same IP flow to multiple terminals simultaneously. The BDS 212 is a network for the Third Generation Partnership Project (3GPP) Multimedia Broadcast / Multicast Service (MBMS), 3GPP2 BCMCS (Broadcast Multicasting Service), DVB (Digital Video Broadcasting) -H, and IPDC (IP Data Cast). It can be a server, these are just examples.

As such, the BDS 212 allocates a multicast / broadcast channel for the target terminals 110, 120, 130 joining the multicast PT group 100, and also receives data received from the source terminal 400. Encrypts and transmits through multicast / broadcast channel. The BDS 212 may be one logical functional entity included in the PT participation function 210, as shown in FIG. 2, but this is merely illustrative and may be included in another functional entity of the PT server 200. . The BDS 212 and the PT server 200 may be physically integrated into one or implemented separately from each other.

This BDS 212 may be an independent functional entity for transmitting downlink streams over a multicast channel or a subset of the functions of other network servers that perform only some of the functions required in embodiments of the present invention. For example, the BDS 212 is a broadcast-multicast service center (BM-SC) for providing an MBMS bearer service or a session modification according to an embodiment of the present invention described below among the lower functions of the BM-SC. It may be a functional entity that performs only some sub functions requested by the BDS 212 in a procedure or the like.

FIG. 3 is a block diagram illustrating another example of a system for a multicast PT service to which an embodiment of the present invention can be applied, and also assumes a network configuration for the general PT service shown in FIG. 1. In FIG. 3, illustration of components not directly related to the embodiment of the present invention is omitted. Referring to FIG. 3, the multicast PT service system includes a multicast PT group 100, a PT server 200, a BDS 300, and a source terminal 400. The multicast PT service system is different from the multicast PT service system of FIG. 2 in that the BDS 300 is one of network servers independent of the PT server 200. Hereinafter, the BDS 300 which is a difference between the service system of FIG. 2 and the service system of FIG. 3 will be briefly described.

The BDS 300 is one of network servers for transmitting downlink streams through a multicast channel or a broadcast channel for the target terminals 110, 120, and 130 joining the multicast PT group 100. The BDS 300 is a network for a third generation partnership project (3GPP) multimedia broadcast / multicast service (MBMS), a 3GPP2 broadcast multicasting service (BCMCS), digital video broadcasting (DVB) -H, and an IP data cast (IPDC). It can be a server, these are just examples. The BDS 300 communicates with the PT server 200, allocates a multicast / broadcast channel for the target terminals 110, 120, and 130 joining the multicast PT group 100, and also the PT server. If there is a request from the 200, the data received from the source terminal 400 is encrypted and transmitted through the multicast / broadcast channel.

According to one aspect of this embodiment, such a BDS 300 is an independent network server for providing multimedia data for subscribing terminals of the corresponding broadcast / multicast service, or the implementation of the present invention such as transmission of encrypted data. It may also be a subset of the functions of a network server that performs only some of the functions requested in the example. For example, the BDS 300 is a broadcast-multicast service center (BM-SC) for providing an MBMS bearer service or data transmission according to an embodiment of the present invention described below among the lower functions of the BM-SC. It may be a functional entity that performs only some sub-functions requested by the BDS 300 in a procedure or the like.

When the BDS 300 is an independent network server distinct from the PT server 200, there is a predetermined logical / physical interface between the PT server 200 and the BDS 300, and a request / response message through the interface. And transmission of data and the like may be performed by a predetermined transmission protocol (eg, Session Initiation Protocol (SIP) or Real-time Transport Protocol (RTP), Message Session Relay Protocol (MSRP), It may be made according to a real-time transport control protocol (RTCP). In the embodiment of the present invention, there is no limitation on the type of transmission protocol that can be used for communication between the PT server 200 and the BDS 300.

FIG. 4 is a block diagram showing another example of a system for a multicast PT service to which an embodiment of the present invention can be applied, and also assumes a network configuration for the general PT service shown in FIG. 1. Also, in FIG. 4, illustration of components not directly related to the embodiment of the present invention is omitted. Referring to FIG. 4, the multicast PT service system according to the present embodiment is similar to the service system of FIG. 3 in that the BDS 300 is an independent network server separate from the PT server 200. It differs from the configuration of the multicast PT service system shown in FIG. 3 in that it further includes a server (BCAST Server, 250). Here, in order to avoid unnecessary duplication, only the broadcast server 250, which is a newly added component in the present embodiment, will be described. The description of the remaining components may be equally applied to the above description with reference to FIG. 2 or FIG. 3.

According to the present embodiment, the broadcast server 250 is a functional entity that supports communication between the BDS 300 and the PT server 200. For example, broadcast server 250 may be located at a higher layer of BDS 300 and may be PT server 200 regardless of the type of network dependent BDS 300 (eg, MBMS, BCMCS, DVB, or IPDC). Communication between the BDS and the BDS 300. In this case, the broad BDS 300 may be one that includes a broadcast server 250. Such broadcast server 250 may be a broadcast server of OMA (BCAST Server), which is merely exemplary.

In the multicast PT service system of FIG. 4, the PT participation function 210 sends a message (eg, a session invitation message) or the like directly to the BDS 300 without the mediation of the broadcast server 250. On the other hand, when the BDS 300 transmits a message to the PT control function 220 for communication with the PT server 200, the broadcast server 250 transmits a message from the BDS 300 to the PT control function 220. Relays In this case, the PT control function 220 transmits the received message to the terminal, for example, the source terminal 400.

There is no particular limitation on the manner of implementing the broadcast server 250. For example, the broadcast server 250 may be physically implemented integrally with the PT server 200 or the BDS 300 to exist as one and only logically divided or physically from the PT server 200 or the BDS 300. It may be implemented separately and separately. In Figure 4, to show that the broadcast server 250 may be physically implemented integrally with the PT server 200 is shown tied together in a dotted line. However, this is merely exemplary, and the broadcast server 250 may be implemented integrally with the BDS 300.

Next, a session modification procedure according to an embodiment of the present invention in the aforementioned multicast PT service system will be described in detail. However, in the following embodiment, only the case of the multicast PT service system of FIG. 2 will be described, and the description of the case of the multicast PT service system of FIGS. 3 and 4 will be omitted. However, in the multicast PT service system of FIGS. 3 and 4, the PT group session using the multicast channel participates in addition to the PT server 200, and the BDS 300 also participates in the signaling. 200 and BDS 300, and further, in the multicast PT service system of FIG. 4, that communication between PT server 200 and BDS 300 is via broadcast server 250. Considering this, it will be apparent to those skilled in the art that the following embodiments may be equally applied to the multicast PT service system of FIG. 3 or 4.

First embodiment

The first embodiment of the present invention is a case in which a terminal belonging to a multicast PT group (reference numeral 100 of FIG. 2) (for example, the first terminal 110) moves from a multicast service region to a non-multicast service region. Session Modification in case Moving from Multicast Area to non Multicast Area during the PT Group Session procedure. That is, the present embodiment relates to a session modification procedure when a terminal receiving a downlink stream through a multicast channel in a multicast service area moves to a non-multicast service area. When the terminal moves from the multicast service area to the non-multicast service area, the terminal can no longer receive the downlink stream through the multicast channel, but instead can continue to receive the downlink stream through the PT one-to-one session. have.

In an embodiment to be described later, a terminal detecting that it is moving from a multicast service area to a non-multicast service area transmits a message requesting an update of a session to a PT server. However, the present embodiment is not limited only to this case, and according to the embodiment, the session modification procedure may be initiated by the PT server. In this case, the terminal may inform the PT server only of the fact that it moves to the non-multicast service area, and the PT server having learned this may transmit a message requesting the update of the session to the terminal.

Referring to FIG. 5, a PT group session is in progress between a terminal A and a PT server 200 using a multicast channel. The terminal 110 is one of the target terminals belonging to the multicast PT group (reference number 100 of FIG. 2) of FIG. 2, and the source terminal (reference number 300 of FIG. 2) supports a PT group session in which multicast transmission is supported. The media data is received through the multicast channel. The PT server 200 includes a BDS 212 for transmitting media data through a multicast channel. The PT server 200 transmits media data through a multicast channel. In this case, the PT server 200 may individually transmit media data and the like to the terminals through a dedicated channel if necessary.

The BDS 212 encrypts a media and a media burst control message provided by the source terminal with a predetermined encryption key and transmits the same through a multicast channel. In this case, the encrypted media data may be transmitted using a transport protocol suitable for transmission of a media stream such as a real-time transport protocol (RTP), a message session relay protocol (MSRP), or the like. have. A key for encrypting media data is referred to as a traffic key. For example, the key may be an MBMS traffic key (MTK). The traffic key may be transmitted through a multicast channel together with the encrypted media data by being encrypted with a service key or a group key. An example of a service key is an MSK (MBMS Service Key).

Since the terminal 110 is located in the current multicast service area, the terminal 110 may receive encrypted media data transmitted by the PT server 200 through the multicast channel. A service key necessary for reception of media data through a multicast channel and session description protocol (SDP) information such as various information and parameters may be obtained through a process of establishing a PT group session. The terminal 110 may first decrypt the encrypted traffic key using the service key obtained in the process of establishing the PT group session, and then restore the encrypted media data using the decrypted traffic key. Just exemplary.

In FIG. 5, the procedure for setting the PT group session configured by the terminal 110 is not particularly limited. See, for example, the standard documents of POC 1.0 and 2.0 of the Open Mobile Alliance (OMA) (eg, subclause 5.26.1 "Establishment of a PoC Group Session" of the OMA OMA-TS-PoC_System_Description-V2_1-20080605-D document). According to the procedure, the procedure of establishing a PT group session for target terminals included in the multicast PT group may be performed.

Subsequently, during the progress of the PT group session using the multicast channel, the terminal 110 detects that it is moving from the multicast service area to the non-multicast service area (S110). The terminal 110 may detect such movement by using system information that is periodically received. For example, in the case of a multicast PT service through a 3GPP mobile communication network, the terminal 110 may configure the MCMS (MBMS Control Channel) configuration information and the secondary Common Control Physical Channel (PCCH) in the system information of an adjacent cell in a direction in which it moves. System Information When no information is included in the MBMS, the terminal 110 may determine that it is moving to a non-multicast service area.

When the terminal 110 moves from the multicast service area to the non-multicast service area, the terminal 110 can no longer receive the downlink stream through the multicast channel. However, the terminal 110 participating in the PT group session should be able to continue to receive media data provided from the source terminal even if it is in the non-multicast service area. Since the terminal 110 moving to the non-multicast service area can no longer receive the downlink stream through the multicast channel and can receive the media data only through its own dedicated channel, the terminal 110 includes a PT group. The procedure (S120) for updating or converting the session to a PT one-to-one session is performed.

First, the terminal 110 detecting the movement to the non-multicast service area generates a request message for requesting the conversion of the PT group session into a PT one-to-one session and transmits the request message to the SIP / IP core (S121). Converting a PT group session to a PT one-to-one session involves establishing a session to use after moving to the non-multicast service area, ie updating an existing session with a new session, or terminating an existing session and establishing a new session. It can be said that the process. Therefore, for example, a message such as a SIP UPDATE method or a SIP re-INVITE method may be used as the request message, and the SIP UPDATE method may be used only when the PT server indicates that the PT server supports the request. Can be used. However, the present embodiment is not limited thereto, and other types of messages that perform the same function may also be used as the request message of this step S121.

The request message includes information typically required for the update of a session or the establishment of a PT one-to-one session, including SDP information as a session description protocol (SDP) offer. For example, the request message may include PT session identity information, terminal 110 address (eg, Terminal A Address and / or PT Address of the User of the Terminal A at the PT Client) information, and the terminal. Media parameters for uplink transmission selected by 110 (eg, Media Parameters for Media to the PT Server (Participating) selected by Terminal A) information, information related to floor control for uplink transmission (eg, Media-floor Control Entities for Media to the PT Server (Participating)), and Support Multicast PT Service Indication information.

The request message may further include information indicating a reason why the terminal 110 requests a session switch or session update, that is, reason indication information. In the present embodiment, since the terminal 110 requests the session switch or the session update because it moves from the multicast service area to the non-multicast service area, the reason indication information is sufficient to indicate this purpose and is expressed. There is no limit to how. For example, the reason indication information may be moving to non multicast service area indication information.

Subsequently, the SIP / IP core receiving the request message, for example, the SIP UPDATE method or the SIP re-INVITE method, routes the received request message to the PT server 200 (S122). The request message routed to the PT server 200 may include the same information as the information included in the request message received by the SIP / IP core from the terminal 110.

According to an embodiment, the PT server 200 that has received the request message in this step S122 determines that the terminal 110 moves to the non-multicast service area, thereby reducing the number of terminals in the multicast service area. If so, it may be determined whether to continue the transmission of the downlink stream on the multicast channel. In this case, it may be determined whether to continue the transmission based on a total number of terminals located in the multicast service area or a criterion such as a policy of a service provider. In some cases (for example, when the number of terminals located in the multicast service area becomes smaller than a predetermined reference value due to the movement of the terminal 110), the PT server 200 may use the downlink stream through the multicast channel. May also stop the transmission of. However, in the exemplary embodiment of the present invention, only the session modification procedure that is performed regardless of the determination and the ancillary procedure according to the determination in the PT server 200 will be described.

Subsequently, the PT server 200 transmits a response message to the received request message to the SIP / IP core (S123). If the request message is a SIP UPDATE method or a SIP re-INVITE method is used, the response message may be a SIP 200 OK method. However, the present embodiment is not limited thereto, and the type of the request message and the response message may vary depending on the transport protocol applied.

According to an embodiment of the present invention, the response message includes information typically included in a session update procedure or a new session establishment procedure. For example, the response message may include PT Session Identity information, address of the terminal 110 (eg, Terminal A Address and / or PT Address of the User of the Terminal A at the PT Client), PT Media parameters for downlink / uplink media selected by the server (e.g., Media Parameters for Media from / to the PT Server selected by PT Server) information, information related to floor control in the downlink / uplink (e.g., Media -floor Control Entities for Media from / to the PT Server) information, and Supported Multicast PT Service Indication information.

Subsequently, the SIP / IP core transmits the received response message, for example, the SIP 200 OK method, to the terminal 110 (S124). The response message transmitted to the terminal 110 may include the same information as the information included in the response message received in step S123. As such, after the exchange of the request message and the response message between the terminal 110 and the PT server 200 in step S120, a PT one-to-one session (PT Point-to) between the terminal 110 and the PT server 200. Point Session).

5, the terminal 110 disconnects the multicast channel (S130). This step is performed by the terminal 110 individually. It is not necessary for the terminal 110 to transmit a predetermined signal to the access network in order to perform the present step. The terminal 110 disconnected from the multicast channel can no longer receive the downlink stream through the multicast channel. Therefore, in order to continuously receive the media data provided by the source terminal, the terminal 110 must connect to its own dedicated channel using the information included in the response message received in step S124.

When the terminal 110 completely enters the non-multicast service area and reception through the multicast channel is no longer possible, step S130 may be performed. However, embodiments of the present invention are not limited thereto. For example, even if the terminal 110 is still located in the multicast service area, the terminal 110 may arbitrarily disconnect the multicast channel.

The terminal 110 disconnects the multicast channel after performing the response message in step S124, but embodiments of the present invention are not limited thereto. For example, the terminal 110 may arbitrarily disconnect the multicast channel immediately after transmitting the session invitation message in step S121. However, in this case, the terminal 110 may not temporarily receive media data until the terminal 110 completes step S120 to acquire information on its own dedicated channel and connects to the dedicated channel.

When receiving the response message in step S124, the terminal 110 connects to its own channel based on the session description protocol (SDP) included in the received response message, thereby establishing a PT one-to-one session in the non-multicast service area. The downlink stream can be received. Media Burst and Talk Burst Control and / or Media Burst Control through the established PT one-to-one session are performed according to a normal PT service procedure, and there is no limitation in this embodiment. . For example, in accordance with the procedure described in the POC 1.0 and 2.0 standard documents of the Open Mobile Alliance (OMA) (eg, subclause 5.12 "PoC Media Flows" of the OMA OMA-TS-PoC_System_Description-V2_1-20080605-D document). In addition, communication may be performed between the terminal 110 and the PT server 200.

Accordingly, the PT server 200 transmits the downlink stream using the PT one-to-one session for the terminal 110 subscribed to the multicast PT service but located in the non-multicast service area. And, even if the terminal 110 moves to the non-multicast service area, it can continue to receive the downlink stream using its own dedicated channel. In FIG. 5, this process is indicated as an On-going PT Point-to-Point Session using Dedicated Session.

In this case, the PT server 200 may continue to transmit the downlink stream on the multicast channel for other terminals in the multicast service area, or in some cases no more transmission on the multicast channel. It may not. In the former case, the PT server 200 performs multicast transmission using the BDS 212, for example, standard documents of POC 1.0 and 2.0 of the Open Mobile Alliance (OMA) (eg, OMA OMA-TS-PoC_System_Description). Multicast transmissions can be performed according to the procedure described in subclause 5.26.4 "Multicast Media Transmission in a PT Group Session" in document V2_1-20080605-D.

As described above, according to the session modification procedure according to the first embodiment of the present invention, when a terminal establishing a PT group session moves from a multicast service area to a non-multicast service area, the terminal communicates with a PT server. By switching the session to a PT one-to-one session via communication, it is possible to continue receiving the downlink stream using its own dedicated channel.

Second embodiment

A second embodiment of the present invention is a session when a terminal (eg, the first terminal 110) belonging to a multicast PT group (reference numeral 100 of FIG. 2) moves from a multicast service region to a non-multicast service region. Session Modification in case moving from Multicast Area to non Multicast Area during the PT Group Session. That is, the present embodiment relates to a session modification procedure when a terminal receiving a downlink stream through its own dedicated channel in a non-multicast service region moves to a multicast service region. When the terminal moves from the non-multicast service area to the multicast service area, the terminal can continue to receive the downlink stream even through the multicast channel.

In an embodiment to be described later, a terminal detecting that it is moving from a non-multicast service area to a multicast service area transmits a message requesting an update of a session to a PT server. However, the present embodiment is not limited only to this case, and according to the embodiment, the session modification procedure may be initiated by the PT server. In this case, the PT server is aware of this by using information such as signal strength received from the terminal, or by receiving a message from the PT server containing information indicating that the service is moved from the non-multicast service area to the multicast service area. The PT server may transmit a message requesting the update of the session to the terminal.

The second embodiment of the present invention differs only in the direction of movement of the terminal from the above-described first embodiment in that the terminal 110 moves from the non-multicast service area to the multicast service area. Therefore, the following briefly focuses on the differences from the first embodiment described above.

Referring to FIG. 6, a PT one-to-one session is in progress between a terminal 110 and a PT server 200 located in a non-multicast service area using a dedicated channel. That is, communication between the terminal 110 and the PT server 200 is in progress through a PT one-to-one session, and the terminal 110 cannot receive the downlink stream through the multicast channel, but the source through its dedicated channel. Receive media data provided by the terminal.

During the course of the PT one-to-one session using its dedicated channel, the terminal 110 detects that it is moving from the non-multicast service area to the multicast service area (S210). The terminal 110 may detect such movement by using system information that is periodically received. For example, in the case of a multicast PT service through a 3GPP mobile communication network, the terminal 210 displays the MCMS (MBMS Control Channel) configuration information and the secondary Common Control Physical Channel (PCCHH) in system information of an adjacent cell in a direction in which it moves. System Information When at least one information of the MBMS is included, the terminal 110 may determine that it is entering the multicast service area.

When the terminal 110 moves from the non-multicast service area to the multicast service area, the terminal 110 can now receive the downlink stream through the multicast channel. In this case, receiving the media data or the like through the multicast channel instead of the dedicated channel of the terminal 110 may be mandatory or optional depending on the operator policy or the multicast PT service protocol. It may be. There is no restriction on this in the embodiment of the present invention, hereinafter, the terminal 110 moving to the multicast service area proceeds with the procedure (S220) for updating or switching the PT one-to-one session to the PT group session. do.

First, upon detecting movement to the multicast service area, the terminal 110 transmits a request message for requesting the conversion of the PT one-to-one session to the PT group session to the SIP / IP core (S221). The request message is a message for setting a session to use after moving to a multicast service area. As the request message, for example, a message such as a SIP UPDATE method or a SIP re-INVITE method may be used. The request message includes information typically required for updating a session or establishing a PT one-to-one session. The request message may further include reason indication information which is information indicating a reason why the terminal 110 requests a session switch or session update. For example, the reason indication information may be moving to multicast service area indication information.

Subsequently, the SIP / IP core receiving the request message, for example, the SIP UPDATE method or the SIP re-INVITE method, routes the received request message to the PT server 200 (S222). The PT server 200 processes the received request message, and then transmits a response message to the SIP / IP core (S223). If the request message uses a SIP UPDATE method or a SIP re-INVITE method, the response message may be a SIP 200 OK method. The response message includes information typically included in a session update procedure or a new session establishment procedure. Subsequently, the SIP / IP core transmits the received response message, for example, the SIP 200 OK method, to the terminal 110 (S224). As such, after the exchange of the request message and the response message between the terminal 110 and the PT server 200 in step S120, a PT group session between the terminal 110 and the PT server 200. Is set.

6, the terminal 110 connects to the multicast channel using channel information on the multicast channel included in the response message (S230). The terminal 110 connected to the multicast channel can now receive the downlink stream through the multicast channel. In this case, the terminal 110 may enter the multicast service area and perform step S230 when reception through the multicast channel is no longer possible, but embodiments of the present invention are limited thereto. It is not. For example, even if the terminal 110 is still located in the non-multicast service area, the terminal 110 may arbitrarily attempt to connect to the multicast channel.

As described above, according to the session modification procedure according to the second embodiment of the present invention, when a terminal establishing a PT one-to-one session moves from a non-multicast service area to a multicast service area, the terminal is a PT group session. The downlink stream can be received through the multicast channel by acquiring information on the multicast channel and the SDP information necessary for receiving the downlink stream through the multicast channel through the switching procedure of the AP server. In this case, the PT server no longer needs to transmit media data or the like individually through a dedicated channel for the terminal.

The embodiments of the present invention described in detail above are merely illustrative of the technical idea of the present invention, and should not be construed as limiting the technical idea of the present invention by the embodiments. The protection scope of the present invention is specified by the claims of the present invention described later.

1 is a block diagram showing an example of a network configuration for a general PT service.

2 is a block diagram illustrating an example of a system to which a session modification procedure for a multicast PT service according to an embodiment of the present invention can be applied.

3 is a block diagram illustrating another example of a system to which a session modification procedure for a multicast PT service according to an embodiment of the present invention can be applied.

4 is a block diagram showing another example of a system to which a session modification procedure for a multicast PT service according to an embodiment of the present invention can be applied.

5 is a message flow diagram illustrating a session modification procedure for a multicast PT service according to a first embodiment of the present invention.

6 is a message flow diagram illustrating a session modification procedure for a multicast PT service according to a second embodiment of the present invention.

Claims (8)

In the session modification procedure for the multicast PT (Push-To) service performed by the terminal, While a PT group session is running through a multicast channel, the system information of the cell does not include any information from the MBMS Control Channel (MCCH) Configuration and the Secondary Common Control Physical Cahnnel (CCPCH) System Information Multimedia Broadcast / Multicast Service (MBMS). Thus detecting that the service area is changed from the multicast PT service area to the non-multicast PT service area; Communicating with a PT server to establish a PT one-to-one session for use in the non-multicast PT service area; Disconnecting the multicast channel; And And receiving media data via the established PT one-to-one session. The method of claim 1, wherein the setting step, Generate and send a request message requesting the switch to the PT one-to-one session to the PT server; And And receiving a response message to the request message from the PT server. The session initiation protocol (SIP) method including a session description protocol (SDP) offer for the PT one-to-one session set as the request message and the response message. Session modification procedure for the multicast PT service, characterized in that using. The method of claim 3, The request message is a SIP re-INVITE method or a SIP UPDATE method, the response message is a session modification procedure for a multicast PT service, characterized in that the SIP 200 OK method. delete delete In the terminal for modifying the session to a PT one-to-one session during the PT group session, A processor designed to generate and process a message; And A terminal, each functionally connected to the processor, comprising a transceiver designed to transmit and receive the message for the processor, respectively. If the system information of the cell during the PT group session through the multicast channel does not include any one of MCCH Configuration and Secondary CCPCH system information MBMS, and detects the movement from the multicast service area to the non-multicast service area. A session description protocol (SDP) offer for the PT one-to-one session to be used in the non-multicast service area, and also generates a request message requesting to switch to the PT one-to-one session to a PT server. Transfer, and Receiving a response message to the request message from the PT server, disconnecting the multicast channel and receiving and processing media data through the PT one-to-one session. delete

Images