Method and apparatuses for roaming service in a mobile broadcasting system
18 claims: 5 independent, 13 dependent
- 1モバイル放送システムにおけるローミングサービス方法であって、 端末がローミング地域へ移動するときに、前記端末によって該当訪問先サービス提供者(Visited Service Provider)からサービスガイドを受信する段階と、 前記端末によって、前記受信されたサービスガイドに基づいて、サービス別許容可能な購買アイテムを要求する要求メッセージをホームサービス提供者(Home Service Provider)に伝送する段階と、 前記要求メッセージを受信すると、ホームサービス提供者によって、前記要求メッセージに基づいて前記端末が位置している訪問先サービス提供者とローミング権限及び前記サービス別許容範囲(allowable scope)を折衝する段階と、 前記要求メッセージに対する応答として、前記ホームサービス提供者によって、前記訪問先サービス提供者と折衝されたサービス別許容範囲を前記端末に伝送する段階と、 を有し、 前記サービス別許容範囲は、前記端末に許容される購買アイテムに関するサービスの受信権限と、前記サービスの受信可能性と、課金情報のうち少なくとも一つを含み、 前記折衝する段階は、前記ホームサービス提供者が前記要 求 メッセージに基づいて前記訪問先サービス提供者にローミング要請メッセージを伝送する段階と、前記ホームサービス提供者が前記ローミング要請メッセージに基づいて前記訪問先サービス提供者からローミング応答メッセージを受信する段階と、をさらに含み、 前記ローミング要請メッセージは、前記購買アイテムと、ローミングを要請した端末が前記訪問先サービス提供者からサービスを受信することができるクラスを決定するための端末加入種類情報を含み、前記クラスは前記ホームサービス提供者と前記訪問先サービス提供者との間に折衝されたものであり、前記ローミング応答メッセージは前記サービス別許容範囲を含むことを特徴とするローミングサービス方法。
- 2前記端末によって、前記サービス別許容範囲に対する同意及び反対を前記訪問先サービス提供者に伝送する段階と、 前記訪問先サービス提供者によって、前記端末が同意すると、前記同意したサービスを受信するための暗号化キーを伝送する段階と、 をさらに有することを特徴とする請求項1に記載のローミングサービス方法。
- 3前記端末によって、前記サービス別許容範囲に対する同意及び反対のうち少なくとも一つを前記ホームサービス提供者に伝送する段階と、 前記ホームサービス提供者によって、前記訪問先サービス提供者に前記端末が同意したサービスを受信するための暗号化キーに対する要求を送信し、前記受信された暗号化キーを前記端末に伝送する段階と、 を有することを特徴とする請求項1に記載のローミングサービス方法。
- 4前記暗号化キーは、ロングタームキー(Long-Term Key)であることを特徴とする請求項2又は3に記載のローミングサービス方法。
- 5前記ホームサービス提供者によって、前記端末にローミングサービスに関する課金情報を伝送する段階をさらに有することを特徴とする請求項1に記載のローミングサービス方法。
- 6モバイル放送システムにおけるローミングサービス方法であって、 端末がローミング地域へ移動するときに、前記端末によって、該当訪問先サービス提供者(Visited Service Provider)からサービスガイドを受信する段階と、 前記端末によって、前記受信されたサービスガイドに基づいてサービス別許容可能な購買アイテムを要求する要求メッセージを訪問先サービス提供者に伝送する段階と、 前記要求メッセージを受信すると、前記訪問先サービス提供者によって、前記要求メッセージに基づき、前記端末が加入した地域のホームサービス提供者(Home Service Provider)から前記端末のローミングサービスの権限を判定する段階と、 前記訪問先サービス提供者によって、前記端末のローミング権限及びローミングサービス別許容範囲を確認し、前記要求メッセージに対する応答として、前記確認されたローミングサービス別許容範囲を前記端末に伝送する段階と、 を有し、 前記サービス別許容範囲は、前記端末に許容される購買アイテムに関するサービスの受信権限と、前記サービスの受信可能性と、課金情報のうち少なくとも一つを含み、 前記判定する段階は、前記訪問先サービス提供者が前記要 求 メッセージに基づいて前記ホームサービス提供者にローミング要請メッセージを伝送する段階と、前記訪問先サービス提供者が前記ローミング要請メッセージに基づいて前記ホームサービス提供者からローミング応答メッセージを受信する段階と、をさらに含み、 前記ローミング要請メッセージは、前記サービス別許容範囲と、ローミングを要請した端末が前記訪問先サービス提供者からサービスを受信することができるクラスを決定するための端末加入種類情報と、を含み、前記クラスは前記ホームサービス提供者と前記訪問先サービス提供者との間に折衝されたことを特徴とするローミングサービス方法。
- 7前記端末によって、前記サービス別許容範囲に対する同意及び反対のうち少なくとも一つを前記訪問先サービス提供者に伝送する段階と、 前記端末が同意すると、前記訪問先サービス提供者によって前記同意されたサービスを受信するための暗号化キーを伝送する段階と、 をさらに有することを特徴とする請求項6に記載のローミングサービス方法。
- 8前記暗号化キーは、ロングタームキーであることを特徴とする請求項7に記載のローミングサービス方法。
- 9前記訪問先サービス提供者によって、前記端末にローミングサービスに関する課金情報を伝送する段階をさらに有することを特徴とする請求項6に記載のローミングサービス方法。
- 10所定の端末から要求メッセージを受信すると、前記要求メッセージに基づいて、前記端末が位置した訪問先サービス提供者(Visited Service Provider)とローミング権限及びローミングサービス別可用範囲を折衝するホームサービス提供者(Home Service Provider)と、 前記要求メッセージに対する応答として、前記折衝されたローミングサービス別許容範囲を前記端末に伝送する訪問先サービス提供者と、 前記ローミングサービス別許容範囲を確認し、前記ホームサービス提供者及び前記訪問先サービス提供者のうちの少なくとも一つから暗号化キーを受信する端末と、 を含み、 前記ローミングサービス別許容範囲は、前記端末に許容される購買アイテムに関するサービスの受信権限と、前記サービスの受信可能性と、課金情報のうち少なくとも一つを含み、 前記ホームサービス提供者は前記要 求 メッセージに基づいて前記訪問先サービス提供者にローミング要請メッセージを伝送し、前記ホームサービス提供者は、前記ローミング要請メッセージに基づいて前記訪問先サービス提供者からローミング応答メッセージを受信し、 前記ローミング要請メッセージは、前記購買アイテムと、ローミングを要請した端末が前記訪問先サービス提供者からサービスを受信することができるクラスを決定するための端末加入種類情報を含み、前記クラスは前記ホームサービス提供者と前記訪問先サービス提供者との間に折衝されたものであり、前記ローミング応答メッセージは前記サービス別許容範囲を含むことを特徴とするモバイル放送システム。
- 11前記ホームサービス提供者が、前記端末にローミングサービスに関する課金情報をさらに伝送することを特徴とする請求項10に記載のモバイル放送システム。
- 12前記暗号化キーはロングタームキー(Long-Term Key)であることを特徴とする請求項11記載のモバイル放送システム。
- 13所定の端末から要求メッセージを受信すると、前記要求メッセージに基づき、前記端末が加入した地域のホームサービス提供者(Home Service Provider)にローミングサービスの権限及びローミングサービス別許容範囲を確認し、前記要求メッセージに対する応答として、前記確認されたローミングサービス別許容範囲を前記端末に伝送する訪問先サービス提供者(Visited Service Provider)と、 前記訪問先サービス提供者から前記端末のローミングサービスに対する要求を受信すると、前記端末のローミングサービスの権限を判定し、その結果を前記訪問先サービス提供者に伝送するホームサービス提供者と、 前記受信されたローミングサービス別許容範囲を確認し、前記ホームサービス提供者及び前記訪問先サービス提供者のうち少なくとも一つから暗号化キーを受信する端末と、 を含み、 前記ローミングサービス別許容範囲は、前記端末に許容される購買アイテムに関するサービス受信権限と、前記サービスの受信可能性と、課金情報のうち少なくとも一つを含み、 前記訪問先サービス提供者が前記要 求 メッセージに基づいて前記ホームサービス提供者にローミング要請メッセージを伝送し、前記訪問先サービス提供者が、前記ローミング要請メッセージに基づいて前記ホームサービス提供者からローミング応答メッセージを受信し、 前記ローミング要請メッセージは、前記サービス別許容範囲と、ローミングを要請した端末が前記訪問先サービス提供者からサービスを受信することができるクラスを決定するための端末加入種類情報と、を含み、前記クラスは前記ホームサービス提供者と前記訪問先サービス提供者との間に折衝されたことを特徴とするモバイル放送システム。
- 14前記訪問先サービス提供者が、前記端末にローミングサービスに関する課金情報をさらに伝送することを特徴とする請求項13に記載のモバイル放送システム。
- 15前記暗号化キーはロングタームキーであることを特徴とする請求項13に記載のモバイル放送システム。
- 16モバイル放送システムにおける端末であって、 端末がローミング地域へ移動するとき、該当訪問先サービス提供者(Visited Service Provider)から受信されたサービスガイドに基づいてサービス別許可可能な購買アイテムを要求する要求メッセージを生成し、前記要求に対する応答メッセージを解読する制御部と、 前記生成された要求メッセージをホームサービス提供者(Home Service Provider)及び前記訪問先サービス提供者に伝送し、前記要求メッセージに対する応答として、前記ホームサービス提供者及び前記訪問先サービス提供者のうち少なくとも一つからサービス別許容範囲を含む前記応答メッセージを受信して前記制御部に伝送する送受信部と、 を含み、 前記サービス別許容範囲は、前記端末に許容される購買アイテムに関するサービス受信権限と、前記サービスの受信可能性と、課金情報のうち少なくとも一つを含み、 前記ホームサービス提供者はローミングを要請した端末が前記訪問先サービス提供者からサービスを受信することができるクラスを決定するための端末加入種類情報を前記訪問先サービス提供者に伝送し、前記クラスは前記ホームサービス提供者と前記訪問先サービス提供者との間に折衝されたことを特徴とする端末。
- 17前記応答メッセージは、前記端末にローミングサービスに関する課金情報をさらに含むことを特徴とする請求項16に記載の端末。
- 18前記暗号化キーはロングタームキーであることを特徴とする請求項16に記載の端末。
Independent claims18
188 paragraphs, as filed
The present invention relates to a mobile broadcasting system, and more particularly to a roaming service method in a mobile broadcasting system and the system thereof.
The mobile communications market has continuously demanded the production of new services through the recombining or integration of existing technologies. Currently, with the development of communication and broadcasting technology, conventional broadcasting systems or mobile communication systems have reached the stage of providing broadcasting services through mobile phones and mobile terminals (or mobile terminals) such as PDAs (Personal Digital Assistants). .. These potential and practical market demands and burgeoning demands on multimedia services, operator strategies to provide new services such as broadcast services in addition to existing voice services, and consumer demand. Due to the interests of IT (Information Technology) companies that are strengthening their mobile communication business on demand, the fusion of mobile communication services and IP (Internet Protocol) has become the mainstream of the development of next-generation mobile communication technology. ..
The OMA (Open Mobile Alliance) is a group that studies standards for interworking between individual mobile solutions, and plays a role in setting various application standards for mobile communication games, Internet services, and so on. Within this OMA Working Group, OMA BAC BCAST (Open Mobile Alliance Browser and Content Mobile Broadcast Sub Working Group) is researching technologies for providing broadcasting services using mobile terminals. The mobile broadcasting system discussed in OMA will be briefly described below.
In a mobile broadcasting system, a mobile terminal for receiving a broadcasting service should receive service guide information including explanatory information for the service itself, billing information for the service, and information on how to receive the service. The mobile terminal receives the corresponding service using the service guide information.
Hereinafter, the prior art and the present invention will be described with specific examples based on the OMA BCAST technology, which is one of the mobile broadcasting technologies. Figure 1 shows the logical configuration of the application layer and its lower transport layer for mobile broadcasting services established by the BCAST Working Group of OMA.
First, the logical entity shown in FIG. 1 will be described in detail. Content Creation (CC) 101 provides content for the BCAST service, which content can include regular broadcast service files such as movies, audio, and video data. The content supplier 101 also generates a service guide and sets the attributes for the content, which are used to determine the transport bearer to which the service is transmitted. Provided to BSA) 102. The BCAST service application 102 receives the BCAST service data provided by the content provider 101 and processes it into a suitable form for providing media encoding, content protection, and interactive services. In addition, the BCAST service application 102 assigns attributes to the content provided by the content supplier 101 to the BCAST Service Distribution / Adaptation Department (BCAST). Provided to Service Distribution / Adaptation: BSDA) 103 and BCAST Subscription Management (BSM) 104.
BCAST service distribution / adaptation unit 103 uses BCAST service data provided by BCAST service application 102 to perform operations such as file and streaming transmission, service collection, service protection, service guide generation and transmission, and service notification. To carry out. In addition, the BCAST service distribution / adaptation unit 103 adjusts the service to conform to the Broadcast Distribution System (BDS) 112.
The BCAST Subscription Management Department 104 defines services such as subscription and fee-related functions for BCAST service users, defines the information used for the BCAST service, and provides terminals that receive the BCAST service by hardware or software. to manage. The terminal 105 receives program support information such as content and service guides and content protection, and provides broadcasting services to users. The BDS Service Distribution (BDS-SD) 111 transmits the mobile broadcasting service to a plurality of terminals through mutual communication with the broadcast distribution system 112 and the bidirectional transmission network (IN) 113.
The broadcast distribution system 112 transmits the mobile broadcast service via the broadcast channel. For example, mobile broadcasting services are 3GPP (3)<sup>rd</sup> Generation Project Partnership (MBMS) MBMS (Multimedia Broadcast Multicast Service), 3GPP2 BCMCS (Broadcast Multicast Service), DVB (Digital Video Broadcasting) DVB-H (DVB-Handheld) or IP (Internet Protocol) -based broadcasting / communication network Can include. The bidirectional transmission network 113 provides bidirectional channels. For example, the bidirectional transmission network 113 can be a cellular network.
Next, a reference point, which is a connection passage between logical entities, will be described. A reference point has multiple interfaces depending on the purpose, and such interfaces are used for communication between two or more logical entities for a specific purpose. Message formats and protocols are applied for this.
BCAST-1 121 is a transmission path for content and content attributes, and BCAST-2 122 is a BCAST service whose content is protected (Content-protected) or whose content is not protected (Content-unprotected), and the attributes of the above BCAST service. , And the transmission path of the content attribute.
BCAST-3 123 is a transmission path for BCAST service attributes, content attributes, user preference and subscription information, user requests, and responses to the above requests. BCAST-4 124 is a transmission path for Notification Messages, attributes used in service guides, and keys used for Content Protection and Service Protection.
BCAST-5 125 is used for protected BCAST services, unprotected BCAST services, content protected BCAST services, content unprotected BCAST services, BCAST service attributes, content attributes, notifications, service guides, BCAST service protection. DRM (Digital Right Management) RO (Right Object) and key value security element (security material), and the transmission path of all data and signals transmitted via the broadcast channel.
BCAST-6 126 is used for protected BCAST services, unprotected BCAST services, content protected BCAST services, content unprotected BCAST services, BCAST service attributes, content attributes, notifications, service guides, BCAST service protection. Security factors such as DRM RO and key values, and the transmission path for all data and signals transmitted over bidirectional transmission channels.
BCAST-7 127 provides a bidirectional transmission channel for control information related to the reception of security elements such as DRM RO and key values used for service provisioning, subscription information, device management, and BCAST service protection. It is a transmission path of user priority information transmitted via.
BCAST-8 128 is a transmission path through which user data is transmitted bidirectionally to the BCAST service. BDS-1 129 is a transmission path for protected BCAST services, unprotected BCAST services, BCAST service attributes, content attributes, notifications, service guides, and DRM RO and key value security elements used to protect BCAST services. ..
BDS-2 130 is a transmission path for DRM RO and key value security elements used for service provisioning, subscription information, device management, and BCAST service protection. X-1 131 is a reference point between the BDS service distribution unit 111 and the broadcast distribution system 112. X-2 132 is a reference point between the BDS service distribution unit 111 and the bidirectional transmission network 113. X-3 133 is a reference point between the broadcast distribution system 112 and the terminal 105. X-4 134 is a reference point between the BDS service distribution unit 111 and the terminal 105 through the broadcast channel. X-5 135 is a reference point between the BDS service distribution unit 111 and the terminal 105 through the bidirectional transmission channel. X-6 136 is a reference point between the bidirectional transmission network 113 and the terminal 105.
FIG. 2 shows the configuration of a service guide for receiving a broadcast service in a general mobile broadcasting system. This is the structure proposed by OMA BAC B CAST to provide broadcasting services to mobile terminals. One service guide is composed of a plurality of fragments having their respective purposes, and these fragments are divided into four groups according to their uses, as shown in FIG.
FIG. 2 shows an example of a service guide composed of an administrative group 200, a provisioning group 210, a core group 220, and an access group 230. In Figure 2, the solid line connecting to each fragment means a cross-reference between the fragments.
The management group 200 is a group that provides the basic information required by the mobile terminal in order to receive the service guide, and includes a service guide context fragment 201 and a service guide delivery descriptor fragment 202. including.
The service guide context fragment 201 provides a service guide identifier (ID), service provider identification information for generating and transmitting a service guide, and information about the service guide in general. The service guide transmission predicate fragment 202 provides the mobile terminal with channels, schedule information, and update information capable of receiving a plurality of service guide fragments, so that the mobile terminal can provide only the necessary service guides at an appropriate time. Can be received by.
Supply group 210 is a group that provides charge information for receiving services and includes purchase item fragment 211, purchase data fragment 212, and purchase channel fragment 213. Purchasing Item Fragment 211 provides pricing information about a service or service bundle, Purchasing Data Fragment 212 represents actual cost information about a Purchasing Item, and Purchasing Channel Fragment 213 is a system and fee payment that allows a service user to actually purchase a service. Provide information about the method.
The core group 220 is a group that provides information about the service itself and includes a service fragment 221, a schedule fragment 222, and a content fragment 223. The service fragment 221 provides a description of the service itself received by the user and information indicating the content that the service can configure. Schedule fragment 222 provides information about when the service is available and available. Content fragment 223 provides information about a plurality of contents that make up the service.
Access group 230 includes access fragment 231 and session description fragment 232. The access group 230 provides service access information indicating how to receive the service provided through the core group 220, and specific information about the session to which the content constituting the service is transmitted, so that the mobile terminal can provide the service. , Make the service accessible.
The access fragment 231 provides the mobile terminal with a plurality of access methods for one service, thereby providing a method for accessing various additional services based on one service. Session description fragment 232 provides session information for services defined in one access fragment. The service guide information can also include, as shown in FIG. 2, a preview data fragment 224 that provides previews and icons for services and content in addition to the four fragments.
Figure 3 shows the visited network (Visited Network: hereafter, not the service area of the Home Network (hereinafter referred to as Home N / W) 310 to which the mobile broadcasting terminal subscribes in OMA BCAST. The roaming procedure when you wish to receive broadcasting services in 320 service areas (referred to as visited N / W) is shown below. Before explaining each step of the roaming procedure, each entity of FIG. 3 will be described first.
The BCAST service applications (BCAST Service Application: hereinafter referred to as BSA) 311 and 321 existing in the home N / W 310 and the visited N / W 320 have the same functions as the BCAST service application 102 in FIG. Separately shown to differentiate the BSA of the home N / W310 and the visited N / W320 when roaming. Similarly, the BCAST Subscription Management Units (BCAST Subscription Management: hereinafter referred to as BSM) 312 and 322 have the same functions as the BCAST Subscription Management Unit 104 in FIG. The BCAST Service Distribution Adaptation (hereinafter referred to as BSDA) 313 and 323 have the same functions as the BCAST Service Distribution / Adaptation 103 in FIG. 1, and the BDS Service Distribution: BDS-SD), BCAST Distribution System (BCAST Distribution) Group entities 314 and 324, which are composed of System: BDS and interaction network (IN), respectively, have the same functions as BDS-SD111, BDS112, and IN113 in FIG. The terminal 330 has the same functions as the terminal 105 of FIG. Next, each step of the roaming procedure will be described.
In step 301, the user moves to the visited N / W 320 after requesting the BCAST roaming service at his home N / W 310. The procedure for roaming from the home N / W 310 to the visited N / W 320 must be performed in lower layers 313 and 323, which are outside the BCAST area. In step 302, the terminal 330 automatically receives a service guide from the roaming destination N / W 320 without connecting to the home N / W 310. Upon receiving the service guide in step 303, terminal 330 receives the RO (Rights) for the particular BCAST service desired by the user. Send a request for (Object) to BSM322 of the visited N / W320. In step 304, the BSM322 of the visited N / W320 obtains authorization for user roaming on the BSM312 of the home N / W310. In step 305, the rights object requested by terminal 330 in step 303 is transmitted to terminal 330 through BSM321 of the visited N / W 320. After receiving the rights object in step 305, terminal 330 receives the BCAST service in step 306 through BSDA323 of the visited N / W320. Finally, in step 307, the visited N / W320 generates the charge information and transmits it to the home N / W310, but since it is out of the BCAST standard, the explanation is not described.
As explained in Figure 3, BCAST now shows the procedure for roaming. In order to actually enable roaming, a message for communication between each entity and its message format are required, but they are not presented. In mobile broadcasting services where various service providers can exist, the message flow between BCAST service entities must be clearly presented in order for the user terminal to roam freely and receive the service. In the current roaming procedure, when the user performs roaming, the above procedure is performed without notifying the billing information. However, when roaming actually occurs, the billing system is not charged by the service guide fee of the visited N / W320 received while roaming, unlike the home N / W310 used by the user. .. For this reason, it is necessary to provide the user with information related to billing fluctuations so that the user can decide whether or not to use the roaming service. Also, roaming services must be requested before being sent to the home N / W 310 to enable roaming procedures. However, in reality, such a situation is not always possible, so roaming must be possible even after the terminal has moved from one area to another. The roaming procedure in Figure 3 assumes that the method used to decrypt the content or service encrypted and received in step 305 is OMA DRM 2.0. However, it must be updated so that the content or service can be encrypted / decrypted by methods other than OMA DRM 2.0. Therefore, there is a need for improved methods to support roaming services in mobile broadcast systems.
<p num="0030"> Therefore, the present invention has been made in view of the problems of the prior art, and an object of the present invention is to provide a roaming service method and a system thereof in a mobile broadcasting system. Another object of the present invention is to provide a roaming service method and its system that can support various billing systems in a mobile broadcasting system. Another object of the present invention is to provide a roaming service method and its system that support various encryption methods in a mobile broadcasting system.</p>
<p num="0031"> In order to achieve the above object, according to one aspect of the present invention, it is a roaming service method in a mobile broadcasting system, and when a terminal moves to a roaming area, the service is provided by the corresponding visited service provider by the terminal. Upon receiving the guide, the terminal transmits a roaming request message requesting an acceptable purchase item for each service to the home service provider based on the received service guide, and when the roaming request message is received, Depending on the home service provider, the stage of negotiating roaming availability and allowable scope with the visiting service provider where the terminal is located based on the roaming request message, and by the home service provider. The stage of transmitting roaming availability and permissible range by service to the terminal negotiated with the visited service provider, the stage of transmitting consent and opposition to the permissible range by service to the visited service provider, and the stage of visiting. The service provider has a stage of transmitting an encryption key for receiving the agreed service when the terminal agrees.</p><p num="0032"> In an embodiment of the invention, the roaming request message provides a roaming service method that further includes an acceptable request for a particular service selected by the terminal. In the embodiment of the present invention, the steps of negotiating the roaming possibility and tolerance are the steps of transmitting a message including the subscription type of the terminal to the visited service provider for roaming registration by the home service provider. A roaming service method is provided, which comprises a stage in which a visited service provider determines roaming availability and permissible range for each service based on a subscription type and transmits the roaming availability to the home service provider. In an embodiment of the present invention, the encryption key provides a roaming service method characterized by being a long-term key.</p><p num="0033"> According to another aspect of the present invention, it is a roaming service method in a mobile broadcasting system, in which when a terminal moves to a roaming area, the terminal receives a service guide from the corresponding visited service provider, and the terminal determines. , The stage of transmitting a roaming request message requesting an acceptable purchase item for each service to the visited service provider based on the received service guide, and when the roaming request message is received, the roaming request is made by the visited service provider. Based on the message, the stage of determining whether or not the roaming service of the terminal is permitted by the home service provider in the area where the terminal subscribes, and the availability of the roaming service of the terminal and the permissible range for each roaming service depending on the visited service provider. It is characterized by having a stage of confirming and transmitting the result to the terminal.</p><p num="0034"> In the embodiment of the present invention, the service agreed by the visited service provider when the terminal agrees with the step of transmitting at least one of the consent and the opposition to the service-specific tolerance to the visited service provider by the terminal. Provide a roaming service method further comprising a step of transmitting an encryption key for receiving. In an embodiment of the present invention, the step of transmitting a roaming request message provides a roaming service method, characterized in that the roaming request message further includes a permittable request for a service selected by the terminal.</p><p num="0035"> In the embodiment of the present invention, in the step of determining whether or not the roaming service of the terminal is permitted, the visited service provider transmits a message including the subscription type of the terminal to the home service provider for roaming registration. It is characterized by having a stage and a stage in which the home service provider determines roaming availability based on the subscription type and transmits it to the home service provider.</p><p num="0036"> According to another aspect of the present invention, when a roaming request message is received from a predetermined terminal, the roaming availability and roaming service coverage with the visiting service provider (Visited Service Provider) where the terminal is located are based on the roaming request message. Check the received roaming availability and roaming service tolerance with the home service provider who negotiates with the visited service provider who transmits the negotiated roaming availability and roaming service tolerance to the terminal. It is characterized by including a terminal that receives an encryption key from at least one of a home service provider and a visited service provider.</p><p num="0037"> In an embodiment of the invention, the terminal provides a mobile broadcasting system characterized in that the roaming request message further includes a permittable request for a service selected by the terminal. In an embodiment of the present invention, there is provided a mobile broadcasting system characterized in that the encryption key is a long-term key.</p><p num="0038"> According to another aspect of the present invention, upon receiving a roaming request message from a given terminal, roaming availability with respect to services that can be granted to the home service provider in the area to which the terminal subscribes, based on the roaming request message. When a visit service provider (Visited Service Provider) who confirms the permissible range for each roaming service and transmits the result to the terminal and a request for the roaming service of the terminal from the visited service provider are received, the roaming service of the terminal is started. Of the home service providers and the visited service providers, determine whether to allow or not, check the roaming availability and the permissible range for each roaming service, and the home service provider who transmits the result to the visited service provider. It is characterized by including a terminal that receives an encryption key from at least one. In an embodiment of the present invention, the terminal provides a mobile broadcasting system characterized in that a roaming request message is transmitted by further including a permission request for a service selected by the terminal.</p><p num="0039"> According to another aspect of the present invention, it is a roaming service method in a terminal of a mobile broadcasting system, and when the terminal moves to a roaming area, permission for each service is possible based on a service guide received from a visited service provider. The stage of transmitting a roaming request message requesting a good purchase item to at least one of the home service provider and the visited service provider in your area, and at least one of the home service provider and the visited service provider. The stage of receiving a roaming response message from one, confirming roaming availability and tolerance by service, and transmitting at least one of consent and disagreement to the home service provider or visited service provider, and confirmed roaming. If the conditions are agreed, it is characterized by having a stage of receiving an encryption key from at least one of a home service provider and a visited service provider.</p><p num="0040"> In an embodiment of the invention, the terminal provides a roaming service method comprising further including a permissible request for the selected service in a roaming request message. In an embodiment of the present invention, the roaming response message provides a roaming service method characterized in that the terminal further includes billing information regarding the roaming service. According to another aspect of the present invention, a terminal in a mobile broadcasting system, when the terminal moves to a roaming area, a purchase item that can be permitted for each service based on the service guide received from the service provider of the visited destination. A control unit that generates a requesting roaming request message and decodes a response message to the roaming request, and transmits the generated roaming request message to the home service provider and the visited service provider to provide the home service provider and the visited service. It includes a transmission / reception unit that receives a roaming response message from at least one of the providers and transmits the roaming response message to the control unit.</p><p num="0041"> In an embodiment of the invention, the control unit provides a terminal that further includes a permissible request for the service selected in the roaming request message. In an embodiment of the invention, the roaming response message provides the terminal with a terminal that further includes billing information about the roaming service.</p>
<p num="0042"> The present invention provides a procedure and method capable of roaming in a mobile broadcasting system, in which the procedure is performed with the home service provider that the user first subscribed to and the visited service provider who has a roaming contract with the home service provider. Provides communication procedures between. The present invention also has the effect of providing messages and procedures that make it possible to support a variety of service billing systems for roaming services requested by users.</p>
<figref num="1">It is a figure which shows the functional configuration of a mobile broadcasting system.</figref><figref num="2">It is a figure which shows the structure of the service guide used for receiving a broadcasting service in a general mobile broadcasting system.</figref><figref num="3">It is a figure which shows the conventional roaming service procedure in OMA BCAST.</figref><figref num="4">It is a figure which shows the roaming procedure by embodiment of this invention.</figref><figref num="5">It is a flowchart which shows the BSM operation of the visited SP by embodiment of this invention.</figref><figref num="6">It is a flowchart which shows the BSM operation of the home SP by embodiment of this invention.</figref><figref num="7">It is a flowchart which shows the terminal operation by embodiment of this invention.</figref><figref num="8">It is a figure which shows the roaming procedure by embodiment of this invention.</figref><figref num="9">It is a flowchart which shows the BSM operation of the visited SP by embodiment of this invention.</figref><figref num="10">It is a flowchart which shows the BSM operation of the home SP by embodiment of this invention.</figref><figref num="11">It is a flowchart which shows the terminal operation by embodiment of this invention.</figref><figref num="12">It is a figure which shows an example of the protocol stack which can be used for communication between BSMs by embodiment of this invention.</figref><figref num="13">It is a figure which shows the roaming procedure by embodiment of this invention.</figref><figref num="14">It is a flowchart which shows the BSM operation of the visited SP by embodiment of this invention.</figref><figref num="15A">It is a flowchart which shows the BSM operation of the home SP in embodiment by this invention.</figref><figref num="15B">It is a flowchart which shows the BSM operation of the home SP in embodiment by this invention.</figref><figref num="16">It is a flowchart which shows the terminal operation by embodiment of this invention.</figref><figref num="17">It is a figure which shows the request procedure of the purchase item list at the time of roaming by embodiment of this invention.</figref><figref num="18">It is a flowchart which shows the BSM operation of the visited SP by embodiment of this invention.</figref><figref num="19">It is a flowchart which shows the BSM operation of the home SP by embodiment of this invention.</figref><figref num="20">It is a flowchart which shows the terminal operation by embodiment of this invention.</figref><figref num="21">It is a figure which shows the request procedure of the purchase item list at the time of roaming by embodiment of this invention.</figref><figref num="22">It is a flowchart which shows the BSM operation of the visited SP by embodiment of this invention.</figref><figref num="23">It is a flowchart which shows the BSM operation of the home SP by embodiment of this invention.</figref><figref num="24">It is a flowchart which shows the terminal operation by embodiment of this invention.</figref>
Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. It is clear to those who have ordinary knowledge in the art that the embodiments of the present invention are capable of various modifications without departing from the scope and spirit of the present invention. In addition, when it is determined that a specific description of a known function or configuration related to the present invention makes the gist of the present invention unclear, the detailed description thereof will be omitted.
In the description described below, a typical embodiment of the present invention will be presented. For convenience of explanation, 3GPP (3) is an asynchronous mobile communication standard group.<sup>rd</sup> The names of entities defined in BCAST of the Generation Partnership Project) or OMA (Open Mobile Alliance), which is a standard group of mobile terminal applications, are used in the same way, but such standards and names limit the scope of the present invention. Of course, it is applicable to systems with similar technical backgrounds. In the above BCAST configuration, the home N / W 310 and the visited N / W 320 shown in FIG. 3 are actually the home service provider (home SP) and the visited service provider (visited service provider). It should be used in place of SP).
Prior to the description of the BCAST roaming procedure according to the embodiment of the present invention, the information necessary for this procedure will be described. <Table 1> to <Table 4> below show the items stored in the service guide context fragment 201 shown in FIG. <Table 1> to <Table 4> are separated from one table for convenience, and are disclosed in detail in Korean Patent Application No. 2005-94675, "Service Guide Context Transmission / Transmission Method and Device in Mobile Broadcasting Systems". ing. Since the embodiment of the present invention uses some information provided in <Table 1> to <Table 4>, the description of unused items is omitted for the sake of simplicity and clarification. Therefore, the detailed description of <Table 1> to <Table 4> below refers to the above-mentioned patent filed in advance.
<tables num="1"><img id="000002" he="181" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
<tables num="2"><img id="000003" he="188" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
<tables num="3"><img id="000004" he="180" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
<tables num="4"><img id="000005" he="199" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
With reference to these <Table 1> to <Table 4>,'name' indicates the name for the element value and attribute value that compose the corresponding message. Type indicates whether or not the corresponding name corresponds to an element value or an attribute value. The element values have values of E1, E2, E3, and E4. E1 represents the upper element value for the entire message, E2 represents the lower element value of E1, E3 represents the lower element value of E2, and E4 represents the lower element value of E3. The attribute value is represented by A, and A indicates the attribute value of the corresponding element. For example, A under E1 represents the attribute value of E1. The'category'is used to indicate whether the element or attribute value is required, has a value of M if the above value is required, and a value of O if the above value is optional. Has. Cardinality represents the relationship between elements and has values of '0', '0 ..1', '1', '0 .. n', and '1 .. n'. '0' means optional relation, '1' means mandatory relation, and'n' means possible to have multiple values. For example, '0 .. n'means that there is no corresponding element value, or that the corresponding element value is n. 'Description' defines the meaning of the relevant element or attribute value.
As shown in FIG. 2, the service guide context 201 provides general information about the service guide, and in particular has the attribute BSDAid and the element ServiceProvider. The attribute BSDAid is the identifier of BSDA103 for transmitting the BCAST service in the relevant area. The element ServiceProvider is composed of the attributes of ProviderURL and ProviderName, and these are the identifier information of the service provider who provides the BCAST service in the corresponding area. That is, the terminal 105 can acquire information about the service provider and the transmitter at the place where the service is received through the information stored in the BSDAid and the Service Provider.
The following <Table 5> to <Table 7> indicate the items stored in the purchased item fragment 211. <Table 5> to <Table 7> are separated from one table and are explained in detail in the OMA standard document for convenience. Since the embodiment of the present invention uses some information provided in <Table 5> to <Table 7>, the description of items not used for simplicity and clarification will be omitted. For a detailed description of <Table 5> to <Table 7>, refer to the OMA Internet website http://www.openmobilealliance.org/ftp/Public_documents/BAC/BCAST/Permanent_documents/OMA. -TS-TS-BCAST_ServiceGuide-V1_0_0-20050930-D.zip refer to the document. The reference document is the latest version at the time of this application, and the modified version will be applied if there is any change in this document in the future.
<tables num="5"><img id="000006" he="152" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
<tables num="6"><img id="000007" he="152" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
<tables num="7"><img id="000008" he="87" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
As shown in Figure 2, the purchased item fragment 211 provides pricing information for the service or service bundle, and the attribute'id'in <Table 5> to <Table 7> is the service displayed by the corresponding purchased item fragment 211. Represents the identifier ID of.
<Table 8> to <Table 10> below indicate the items stored in the purchasing channel fragment 213. <Table 8> to <Table 10> are separated from one table and are explained in detail in the OMA standard document for convenience. Since the embodiment of the present invention uses some information provided in <Table 8> to <Table 10>, the description of items not used for simplicity and clarification will be omitted. For a detailed explanation of <Table 8> to <Table 10>, refer to the OMA website http://www.openmobilealliance.org/ftp/Public_documents/BAC/BCAST/Permanent_documents/OMA-TS-TS. -BCAST_ServiceGuide-V1_0_0-20050930-D.zip refer to the document. The reference document is the latest version at the time of filing the application, and if there is any change in this document in the future, the changed version will be applied.
<tables num="8"><img id="000009" he="174" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
<tables num="9"><img id="000010" he="174" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
<tables num="10"><img id="000011" he="110" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
As shown in FIG. 2, the purchasing channel fragment 213 provides information indicating the entities that the service user must access in order to actually purchase the service or service bundle displayed by the purchasing item fragment 211. The element PortalURL of <Table 8> to <Table 10> has the URL of BSM104 that executes purchasing management. As shown in FIG. 1, the BSM104 performs not only purchasing management but also user management. In <Table 1> to <Table 10>, the elements and attributes mentioned for roaming are organized in <Table 11>, and the uses of the above elements and attributes during roaming will be described below.
<tables num="11"><img id="000012" he="97" wi="158" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
BSDAid is an identifier of BSDA103, through which the entity providing the service can be identified. When the terminal 105 is located at the home SP, the BSDAid is the URL of the BSDA of the service provider to which it has subscribed. When terminal 105 is located at the visited SP after roaming, BSDAid is the URL of BSDA of the service provider in the roaming area. The attributes ProviderURL and ProviderName of the element ServiceProvider represent the unique URL information and name of the service provider, respectively. If the terminal 105 is located at the home SP, the ProviderURI is the URL of the service provider that it subscribed to, and if the terminal 105 is located at the visited SP after roaming, the ProviderURI is the service provider in the roaming area. URL. The terminal 105 uses BSDAid, ProviderURI, and ProviderName when roaming to identify each service provider when roaming is registered to the visited SP and the home SP. For example, BSDAid is necessary to determine the region where a roaming terminal wants to receive the service when one service provider provides BCAST service in various regions. The attribute'id'is the identifier of the service that the user wants to receive in the roaming area when roaming, and is used when registering the roaming service. Finally, the Portal URL is used to obtain information about the BSM104 of the home and visited SPs that perform and manage roaming registrations. The roaming service registration request is actually transmitted to the location stored in the above Portal URL.
In addition to the information provided by the elements or attributes mentioned in <Table 11>, the unique identifier of the terminal 105 requesting the service is required. The unique identifier of the terminal is an identifier basically possessed by the terminal. In addition, regarding the information of the items mentioned in <Table 11>, all the information related to the home SP of the roaming terminal is known by the terminal through the service guide of the home SP. The attributes and elements mentioned in <Table 11> as necessary for roaming are examples created based on the BCAST standard document. Therefore, when the BCAST standard document is updated, the names of attributes and elements that affect the present invention may be changed accordingly.
Next, an example of the roaming procedure according to the embodiment of the present invention will be described. This roaming procedure can be performed in two main ways. One method is that when the terminal first attempts to register a roaming request at the visited SP after roaming, the registration request entity is the BSM of the home SP. In another method, when the terminal first attempts to register a roaming request at the visited SP after roaming, the registration request entity is the BSM of the visited SP. A detailed description of each method is as follows.
Prior to explaining each method, FIG. 12 will be described. FIG. 12 shows an example of a protocol stack that can be used for communication between BSM104s according to an embodiment of the present invention. The HTTP protocol in Figure 12 was initially designed to transmit web pages, but is now used as a protocol for transmitting a variety of information. In addition, a message for roaming defined in the embodiment of the present invention is also generated and transmitted using the above HTTP protocol. Roaming messages encapsulated in HTTP are encapsulated by a transmission hierarchy protocol such as lower TCP. Since TCP is a typical protocol of the transmission hierarchy, it is described as an example. Other transmission hierarchy protocols may also be used for security or efficiency. Once TCP encapsulation is complete, IP will be used as the network hierarchy protocol. OMA Since BCAST is an IP-based mobile broadcasting service, IP must be used as a network hierarchy protocol. However, for security reasons, IPsec can be used with IP. When the transmitting BSM transmits a message to the receiving BSM according to the above procedure, the receiving BSM can obtain the actual message transmitted by decapsulating the message in the reverse order of the above procedure. In the communication between BSMs according to the embodiment of the present invention, the message is changed by using the protocol stack of FIG.
FIG. 4 shows a roaming procedure according to an embodiment of the present invention. Prior to explaining each step of the roaming procedure, each entity of FIG. 4 will be described. Since each BSA 424 and 414 existing in the home SP 420 and the visited SP 410 have the same function as the BSA 102 in FIG. 1, they are described separately in order to discriminate between the BSA of the home SP 420 and the visited SP 410 when roaming. Similarly, BSM423 and 413 have the same functionality as BSM104 in FIG. 1, BSDA422 and 412 have the same functionality as BSDA103 in FIG. 1, and group entities 421 and 411 have BDS-SD, BDS, respectively. It is composed of and IN, and has the same function as BDS-SD111, BDS112, and IN113 in FIG. The terminal 400 has the same functions as the terminal 105 of FIG. Since not all of the entities mentioned above are used in the roaming procedure, the entities used in the roaming procedure according to the embodiments of the present invention will be described below.
Steps 401 and 402 are parts that are not directly specified in the roaming procedure, where terminal 400 arrives in the roaming area and transmits BCAST services BDS, IN, and / or BDS-SD group entities 411 and BSDA412. Suppose it is performed automatically by. However, for reference, in step 401, the group entity 411 of BDS, IN, and / or BDS-SD, which is a sub-network of BCAST, performs roaming, provides roaming display information to terminal 400, and terminals. Basic information must be provided based on the ability of the aircraft 400 to receive the service guide. Using this basic information, the terminal 400 can receive the service guide in step 402 by receiving the service guide context fragment 201 of FIG.
Upon receiving the service guide in step 402, terminal 400 acquires the information described in <Table 11>. In step 403, using the information obtained from <Table 11>, the terminal 400 generates a message for making a roaming registration request to the home SP420 and sends it to the BSM423 of the home SP420. The content of the roaming request message generated by the terminal 400 in step 403 is as shown in <Table 12> below.
<tables num="12"><img id="000013" he="42" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The first item in <Table 12>, the request ID, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time when it is generated in FIG. 4 until the roaming registration request procedure in FIG. 4 is completed. The terminal ID is a unique ID for uniquely identifying the terminal. The terminal ID is used to identify who made the roaming registration request. The visited SP ID is an identifier of a service provider who provides a service in the area where the roaming terminal stays. The visited SP ID is used to provide the home SP420 service provider with information indicating who the terminal requests roaming with. Here, the BSM423 of the home SP420 can determine from the visited SP ID that it does not have its own roaming contract, and immediately proceed to step 406 to notify the terminal 400 that roaming is not permitted. Visit SP BSM The ID is used to inform the home SP of the entity that actually negotiates the roaming service registration procedure with the BSM identifier used by the visited SP410. The visited BSDA ID is the identifier of the BSDA used by the visited SP, and since one service provider can provide services through various BSDAs, the terminal being roamed is used by the visited SP. Of these, it is used to inform which BSDA you want to receive the service through. Finally, the purchased item ID is used to signal the service that the roaming user wants to receive. For the terminal that requested roaming registration in step 403, the BSM413 of the visited SP410 can additionally carry out the authentication process for the terminal, and the detailed process of the authentication stage is the gist of the present invention. Since it is irrelevant, the explanation is omitted for the sake of simplicity.
In step 404, in response to the roaming registration request received from the terminal 400 from step 403, the roaming registration request is transmitted to the BSM413 of the visited SP410 where the terminal 400 is roaming. The content of the message sent from the BSM423 of the home SP420 to the BSM413 of the visited SP410 in step 404 is as shown in <Table 13> below.
<tables num="13"><img id="000014" he="48" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The request ID, which is the first item in <Table 13>, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time when it is generated in FIG. 4 until the roaming registration request procedure in FIG. 4 is completed. The terminal ID is a unique ID for uniquely identifying the terminal. The terminal ID is used to identify who made the roaming registration request. The home SP ID is used to inform which service provider originally received the service from the terminal that requested roaming registration at the visited SP410. Using this information, it can be seen that the BSM413 of the visited SP410 belongs to the service provider whose roaming contract is with the terminal that requested roaming. The home SP BSM ID is used to inform the visited SP410 of the entities required for the roaming registration process. The BSM413 of the visited SP410 responds to the roaming registration result based on the home SP BSM ID. Visit BSDA The ID is used to provide the visited SP410 with information indicating the service area where the terminal currently requests service. The subscription type of the terminal is information provided to evaluate the class at which the terminal that made the roaming request to the visited SP410 can receive the service of the visited SP410, and is a purchase item. Evaluated with ID. The subscription type of the terminal can be the grade of service in which the terminal requesting roaming based on the roaming contract between the home SP420 and the visited SP410 receives roaming from the requested visited SP410. It can be defined in the form of roaming authorization grade numbers or codes discussed between the two service providers, which form is not defined in the embodiments of the present invention. The purchase item ID is a service requested by the terminal, which can be received at a separate cost, or the terminal that requested roaming based on the roaming contract between the visited SP410 and the home SP420. Receivability is determined based on an assessment of what is processed by the subscription.
In step 405, the BSM413 of the visited SP410 sends a response to the request received in step 404. The main purpose of step 405 is to inform the roaming service tolerance requested by the terminal using the information received in step 404. Along with the permission for the roaming service requested by the terminal, the range of services that the terminal can receive from the visited SP410 is also provided. The message sent from BSM413 of the visited SP410 to BSM423 of the home SP420 in step 405 is as shown in <Table 14> below.
<tables num="14"><img id="000015" he="22" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The first item in <Table 14>, the request ID, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time when it is generated in FIG. 4 until the roaming registration request procedure in FIG. 4 is completed. The roaming permission state is used in step 404 to provide the result of evaluating the possibility of roaming using the information provided by the visited SP410 to the BSM423 of the home SP420 of the terminal 400 that requested roaming. The roaming service tolerance is notified to indicate the receive permission that the roaming terminal 400 actually has at the visited SP410 when roaming is possible and the value of the terminal subscription type received in step 404 is roaming. To do. This roaming service tolerance also defines the receivability of the service corresponding to the purchase item ID requested by the terminal 400. Information related to the occurrence of additional costs or changes in the billing system during roaming is also added to the roaming service allowable range.
The above steps 404 and 405 can be omitted if necessary. As an example, it can also be omitted when the terminal 400 attempts to make an additional service request in the middle of receiving a service after completing the roaming registration procedure. At this time, the BSM423 of the home SP420 knows part or all of the cost policy for roaming of the BSM413 of the visited SP410.
In step 406, the home SP 420 notifies the terminal 400 of the result of the roaming registration request received through the visited SP 410 in step 405. In step 406, the BSM423 of the home SP420 actually transmits the message received in step 405 to the terminal 400. In step 403, after the home SP420 analyzes the roaming registration request of the terminal, if there is no roaming contract with the visiting SP410 in the area where the terminal 400 is staying, the home SP420 proceeds to step 406 and <Table 14 > Satisfies the content of roaming request registration failure and sends it to the terminal 400. In such cases, roaming has failed.
At step 407, terminal 400 sends a response to the roaming registration request sent to its home SP420. In step 406, terminal 400 informs BSM413 of the visited SP410 whether or not it agrees with the roaming service tolerance of the received message. If the terminal 400 does not agree to the additional costs and changes in the billing system incurred when roaming, the roaming service will not be provided. However, if the terminal 400 agrees, the process proceeds to the next stage. <Table 15> below shows a message that the terminal 400 provides the visited SP410 with a final confirmation for roaming.
<tables num="15"><img id="000016" he="16" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The first item in <Table 15>, the request ID, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time when it is generated in FIG. 4 until the roaming registration request procedure in FIG. 4 is completed. The roaming confirmation state is an item for notifying the visited SP410 whether or not the terminal 400 performs roaming.
In step 408, when the terminal 400 finally determines to receive the roaming service, it receives a Long-term key message for deciphering the received service. In step 408, the terminal 400 receives the long term key message using the long term key receiving method defined in the BCAST standard, which method is not dealt with in the embodiments of the present invention. At step 409, terminal 400 receives service from the visited SP410 through roaming.
Along with the roaming procedure described in FIG. 4, it is possible to enable roaming by using the message item defined in FIG. 4 for the service provisioning message and procedure defined in OMA BCAST, which is dealt with in the present invention. Absent. Documents on the OMA website http://www.openmobilealliance.org/ftp/Public_documents/BAC/BCAST/Permanent_documents/OMA-TS-BCAST_Services-V1_0_0-20050909-D.zip for the above service supply Refer to. The reference document is the latest version at the time of filing the application, and if there is any change in this document in the future, the changed version will be applied.
FIG. 5 is a flowchart showing the operation of BSM413 of the visited SP410 according to the embodiment of the present invention. FIG. 5 will be described with reference to FIG. In step S501, the BSM413 of the visited SP410 receives a roaming registration request from the BSM423 of the home SP420 of the terminal 400 that is roaming, and decodes the received request message. The content of the received message is as shown in <Table 13>, and the BSM413 of the visited SP410 analyzes the terminal subscription type in the content of the received message in step S502. After that, BSM413 of the visited SP410 analyzes the relationship between the subscription of the terminal requesting roaming and its own subscription policy in step S503 to determine the roaming possible range. When the subscription of the terminal requesting roaming is insufficient to support roaming, the BSM413 of the visited SP410 generates a message rejecting the roaming request in step S504 and transmits it to the BSM423 of the home SP420. However, when it is determined that roaming is possible by subscribing to the terminal that requested roaming, the BSM413 of the visited SP410 determines in step S505 whether or not there is a specific request such as a purchased item. When there is a specific request, BSM413 of the visited SP410 calculates the charge, and if there is no specific request, it calculates the additional charge incurred when roaming. After the calculation is complete, the visited SP410 BSM413 generates a response message to the roaming request. The content of the generated message is as shown in <Table 14>.
After the completion of step S505, the BSM413 of the visited SP410 waits for the final confirmation of roaming from the terminal 400 in step S506. When the terminal 410 requesting roaming sends a final confirmation message for roaming, the BSM413 of the visited SP410 receives and decodes the message in step S507. The content of the received message is as shown in <Table 15>, and the BSM413 of the visited SP410 determines in step S508 whether or not the terminal 400 agrees with the roaming conditions. If the terminal 400 does not agree with the roaming conditions, the roaming procedure with the terminal 400 ends. On the other hand, if the roaming condition is agreed, the BAM413 of the visited SP410 is sent a long term key message for decoding the service received in step S509. Upon receiving the long-term key message, the terminal 400 can use the roaming service within the range agreed by itself.
FIG. 6 is a flowchart showing the operation of BSM423 of the home SP420 according to the embodiment of the present invention. FIG. 6 will be described with reference to FIG. In step S601, BSM423 of the home SP420 receives a roaming request message from the roaming terminal 400 and decodes the received message. The messages received by Home SP420 are as shown in <Table 12>. Using the decrypted message, the BSM423 of the home SP420 determines in step S602 whether or not there is a roaming contract with the visited SP410 where the terminal 400 requesting roaming stays. Without a contract, the home SP420 BSM423 proceeds to step S609 to perform the process without a roaming contract. In step S609, the home SP420 BSM423 can also include, if necessary, the reason for roaming disapproval, while notifying the roaming disapproval subscription, or if possible, a partially available service. Can convey the type of. However, if there is a roaming contract, the BSM423 of the home SP420 searches for the subscription of the corresponding terminal 400 in step S603, and then whether or not the subscription of the terminal 400 searched in step S604 is a roaming allowable subscription. Is determined.
If the subscription does not support roaming, the BSM423 of the home SP420 proceeds to step S609 to notify that it is a roaming unauthorized subscription. In step S609, the BSM423 of the home SP420 can notify the roaming disapproval subscription, while also including the reason for the roaming disapproval when needed, or, if possible, communicate the type of service partially available. .. If the subscription supports roaming, the BSM423 of the home SP420 sends a roaming permission request message to the BSM413 of the visited SP410 in step S605. The content of the message is as shown in <Table 13>. After sending the request message, BSM423 at home SP420 waits for a response from the visited SP410 in step S606. Upon receiving the response to the request, BSM423 at home SP420 decodes the received message in step S607 and analyzes the result for the request in step S608. When the request is accepted by the visited SP410, the BSM423 of the home SP420 generates and transmits a message notifying the result to the terminal 400 requesting roaming in step S610. If this is not the case, the BSM423 of the home SP420 will proceed to step S609 to notify the roaming disapproval subscription, while also including the reason for the roaming disapproval when necessary, or partially using it if possible. Can transmit service types.
FIG. 7 is a flowchart showing the operation of the terminal 400 according to the embodiment of the present invention. FIG. 7 will be described with reference to FIG. The terminal 400 can discover the visited SP410 through the lower BDS-SD111, BDS112, or IN113 in another area instead of its own home SP420 and search for the BCAST service in the corresponding area. When searching for the BCAST service, the terminal 400 can find the service guide context fragment 201 in step S701, and based on this, can receive all the service guides using the service guide transmission descriptor fragment 202. Upon receiving the service guide, if the terminal 400 wishes to receive the roaming service, in step S702, it sends a roaming request message for permitting the roaming service to BSM423 of its home SP420. At this time, the content of the message sent is as shown in <Table 12>. After transmitting the roaming request message, the terminal 400 waits for a response in step S703. When the roaming contract between the BSM423 of the home SP420 and the BSM413 of the visited SP410 is determined, the terminal 400 receives and decodes the response message to the request from the BSM423 of the home SP420 in step S704. The content of the response message is as shown in <Table 14>. After that, the terminal 400 determines in step S705 whether or not roaming is possible by decoding the response message.
If roaming is not possible, the terminal 400 gives up roaming. However, when roaming is possible, the terminal 400 confirms the roaming condition of the visited SP410 in step S706 and determines whether or not it is acceptable. If the roaming conditions are not agreed, in step S707, the terminal 400 transmits a confirmation message refusing roaming to the BSM413 of the visited SP410. However, if the conditions are agreed, the terminal 400 sends a confirmation message confirming the agreement to BSM413 of the visited SP410 in step S708. After transmitting the consent message, the terminal 400 receives the long term key message in step S709, and receives the BCAST service in step S710 after preparing for service or content decryption.
Next, the roaming procedure according to the embodiment of the present invention will be described. FIG. 8 shows a roaming procedure according to an embodiment of the present invention. Prior to explaining each step of the roaming procedure, each entity in FIG. 8 will be described. Since each BSA 824 and 814 existing in the home SP 820 and the visited SP 810 have the same function as the BSA 102 in FIG. 1, they are described separately to distinguish the BSA of the home SP 820 and the visited SP 810 when roaming. Similarly, BSM823 and 813 have the same functionality as BSM104 in FIG. 1, BSDA822 and 812 have the same functionality as BSDA103 in FIG. 1, and group entities 821 and 811 have BDS-SD, BDS, and IN, respectively. It has the same function as BDS-SD111, BDS112, and IN113 in FIG. The terminal 800 has the same functions as the terminal 105 of FIG. Since not all of the entities mentioned above are used in the roaming procedure, the entities used in the roaming procedure according to the embodiments of the present invention will be described below.
Steps 801 and 802 are parts that are not directly specified in the roaming procedure, where terminal 800 arrives in the roaming area and transmits BCAST services BDS, IN, and / or BDS-SD group entities 811 and BSDA812. Suppose it is performed automatically by. However, for reference, in step 801, the group entity 811 of BDS, IN, and / or BDS-SD, which is a sub-network of BCAST, performs roaming, provides roaming display information to terminal 800, and terminals. Basic information must be provided based on the ability of the aircraft 400 to receive the service guide. Using this basic information, the terminal 800 can receive the service guide in step 802 by receiving the service guide context fragment 201 of FIG.
Upon receiving the service guide in step 802, the terminal 800 acquires the information described in <Table 11>. In step 803, using the information obtained from <Table 11>, the terminal 800 generates a roaming request message to make a roaming registration request to the visited SP810 and sends it to the BSM813 of the visited SP810. The content of the roaming request message generated by the terminal 800 in step 803 is as shown in <Table 16> below.
<tables num="16"><img id="000017" he="36" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The first item in <Table 16>, the request ID, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time it is generated in FIG. 8 until the roaming registration request procedure in FIG. 8 is completed. The terminal ID is a unique ID for uniquely identifying the terminal. The terminal ID is used to identify who made the roaming registration request. The home SP ID is an identifier used by roaming terminals to inform the visited SP810 who their home SP820 is. Using this information, the visited SP810 can determine the entity to which the terminal 800 that requested roaming belongs first, and can confirm the roaming relationship with that entity. Here, if the BSM813 of the visited SP810 does not have a roaming contract with himself from the home SP ID, he / she can proceed to step 806 and notify the terminal 800 of the roaming disapproval.
The home SP BSM ID is used as the identifier of the BSM used by the home SP820 to inform the visiting SP810 of the entity that actually negotiates the roaming service registration procedure. Finally, the purchased item ID is used to signal the service that the roaming user wants to receive. For the terminal that requested roaming registration in step 803, the BSM813 of the visited SP810 can additionally perform the authentication process for the terminal. This can be done voluntarily by the BSM813 of the visited SP810, or through a third authentication entity. Therefore, since the detailed process of the certification stage has nothing to do with the gist of the present invention, the description thereof will be omitted for the sake of simplicity.
In step 804, in response to the roaming registration request received from the terminal 800 in step 803, the BSM813 of the visited SP810 transmits the roaming registration request to the BSM823 of the home SP820 of the terminal 800. The content of the message sent from BSM813 of the visited SP810 to BSM823 of the home SP820 in step 804 is as shown in <Table 17> below.
<tables num="17"><img id="000018" he="29" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The first item in <Table 17>, the request ID, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time it is generated in FIG. 8 until the roaming registration request procedure in FIG. 8 is completed. The terminal ID is a unique ID for uniquely identifying the terminal. The terminal ID is used to identify who made the roaming registration request.
The visited SP ID is used by the visited SP810 to inform the BSM823 of the home SP820 of the terminal that requested roaming registration of its information. The visited SP BSM ID is used by the visited SP810 to inform the BSM823 of the home SP820 of the entity with which it has roaming-related negotiations. This is because the visited SP810 can have various BSMs.
At step 805, the home SP820 BSM823 sends a response to the roaming registration request received at step 804. <Table 18> below shows the message content sent from BSM823 of home SP820 to BSM813 of visited SP810.
<tables num="18"><img id="000019" he="23" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The first item in <Table 18>, the request ID, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time it is generated in FIG. 8 until the roaming registration request procedure in FIG. 8 is completed. The roaming permission status is determined after the home SP820 determines and confirms whether roaming is permitted by searching for the subscription of the terminal 800 that requested roaming to the visited SP810 using the terminal ID received in step 804. , Used to provide the results to the visited SP810. The subscription type of the terminal is information provided by the visited SP810 to evaluate the reception right of the roaming terminal 800 at the visited SP810. The subscription type of the terminal can be the grade of service that the terminal 800 that requested roaming based on the roaming contract between the home SP820 and the visited SP810 receives roaming from the requested visited SP810. It can be defined in the form of a roaming authorization grade number or code agreed between the two service providers, which form is not defined in the embodiments of the present invention.
The above steps 804 and 805 may be omitted if necessary. As an example, the above step can be omitted if the terminal 800 wishes to request an additional service while receiving the service after completing the roaming registration procedure.
In step 806, the visited SP810 sends a response to the roaming registration request received by the terminal 800. The content of the message sent by the BSM813 of the visited SP810 to the terminal 800 in step 806 is as shown in <Table 19> below.
<tables num="19"><img id="000020" he="23" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The first item in <Table 19>, the request ID, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time it is generated in FIG. 8 until the roaming registration request procedure in FIG. 8 is completed. The roaming permission state is used in step 805 to provide the terminal 800 that requested roaming with the result of evaluating the possibility of roaming using the information provided by the home SP820.
The roaming service tolerance allows the value of the terminal subscription type received in step 805 to represent the receiving rights that the roaming terminal 800 actually has at the visited SP810 when roaming is possible. Used for. The receivability of the service corresponding to the purchase item ID requested by the terminal 800 is also defined in this roaming service tolerance. Information related to the occurrence of additional costs or changes in the billing system during roaming is also added to the roaming service allowable range.
In step 807, the terminal 800 informs the BSM813 of the visited SP810 whether or not it agrees with the roaming service acceptable information of the message received in response to the roaming registration request to the visited SP810 in step 806. Inform. The roaming service cannot be realized unless the terminal 800 agrees to the additional cost incurred when roaming or the change of the billing system. However, if the terminal 800 agrees, the next step is taken. <Table 20> below shows a confirmation message that the terminal 800 provides the visited SP810 with a final confirmation for roaming.
<tables num="20"><img id="000021" he="17" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The first item in <Table 20>, the request ID, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time it is generated in FIG. 8 until the roaming registration request procedure in FIG. 8 is completed. The roaming confirmation state is an item for notifying the visited SP810 whether or not the terminal 800 performs roaming.
In step 808, when the terminal 800 finally determines to receive the roaming service, it receives a long-term key message for decoding the received service. In step 808, the terminal 800 receives the long term key message using the long term key receiving method defined in the BCAST standard, which method is not dealt with in the embodiments of the present invention. At step 809, terminal 800 receives service from the visited SP810 through roaming.
Similar to the roaming procedure described in FIG. 8, the service provisioning messages and procedures defined in OMA BCAST can be roamed using the message items defined in FIG. I will not handle it. Documents on the OMA website http://www.openmobilealliance.org/ftp/Public_documents/BAC/BCAST/Permanent_documents/OMA-TS-BCAST_Services-V1_0_0-20050909-D.zip for the above service supply Refer to. The reference document is the latest version at the time of filing the application, and if there is any change in this document in the future, the changed version will be applied.
FIG. 9 is a flowchart showing the operation of the BSM813 of the visited SP810 according to the embodiment of the present invention. FIG. 9 will be described with reference to FIG. In step S901, the BSM813 of the visited SP810 receives a roaming request message for a roaming registration request from the roaming terminal 800 and decodes it. The content of the received message is shown in <Table 16> below. Using the contents of the decrypted message, the BSM813 of the visited SP810 determines in step S902 whether the terminal 800 requesting roaming is the terminal of the service provider having a roaming contract. If the terminal 800 that requested roaming belongs to a service provider that does not have a roaming contract, the BSM813 of the visited SP810 proceeds to step S907 and proceeds to the roaming disapproval response message (or roaming service disapproval response). Message) is transmitted to the terminal 800. In step S907, the BSM813 of the visited SP810 can convey the roaming disallowed message while also including the reason for the roaming disallowed, or if possible, partially available types of services. can do.
However, when the terminal 800 belongs to a service provider having a roaming contract relationship, the BSM813 of the visited SP810 transmits a terminal request message to the BSM823 of the home SP820 of the terminal that requested roaming in step S903. .. The content of the transmitted message is as shown in <Table 17>. After that, the BSM813 of the visited SP810 waits for a response message from the BSM823 of the home SP820 of the terminal 800 that requested roaming in step S904. Upon receiving the response message from the home SP820 BSM823, the visited SP810 BSM813 decodes the message received in step S905. At this time, the content of the received message is as shown in <Table 18>. After that, the BSM813 of the visited SP810 confirms the content of the received message in step S906, whether or not to allow roaming of the terminal 800, and roams the terminal 800 using the subscription information of the terminal. Determine whether to allow or not. If the BSM813 of the visited SP810 does not allow the terminal 800 to perform roaming, the roaming disapproval message is transmitted to the terminal in step S907. In step S907, the BSM813 of the visited SP810 can carry a roaming denial message while also including the reason for the roaming denial when needed, or if possible, convey the type of service that is partially available. can do.
When the BSM813 of the visited SP810 permits the terminal 800 to perform roaming, the terminal 800 uses the subscription information of the terminal 800 to generate a response message that reflects the additional charges and changes in the billing system that occur during roaming. To transmit to. After transmitting the response message, the BSM813 of the visited SP810 waits for a response from the terminal 800 in step S909. Upon receiving the final confirmation message for roaming from the terminal 800, the BSM813 of the visited SP810 decodes the message received in step S910 and determines whether or not the terminal performs roaming in step S911. When the content of the received message indicates roaming refusal, the roaming request procedure ends. On the other hand, when the content of the received message indicates roaming acceptance, the long term key message is transmitted to the terminal in step S912.
FIG. 10 is a flowchart showing the operation of BSM823 of the home SP820 according to the embodiment of the present invention. FIG. 10 will be described with reference to FIG. In step S1001, the BSM823 of the home SP820 receives a roaming request message for the terminal making the roaming request from the BSM813 of the visited SP810. The content of the message received by this home SP820 is as shown in <Table 17>. The BSM823 of the home SP820 searches for the subscription of the terminal that requested roaming in the visited SP810 in step S1002, and determines whether or not to allow the terminal 800 that requested roaming in step S1003 to receive the roaming service. .. If the terminal 800 is authorized to receive roaming services, the BSM823 of the home SP820 will in step S1005 a message containing the content shown in <Table 18> above that includes the subscription of the terminal 800. Is transmitted to the visited SP810. If the terminal 800 that made the roaming request is not permitted to receive the roaming service, the BSM823 of the home SP820 transmits a roaming disapproval message (or a roaming disapproval message) to the visited SP810 in step S1004. Here, the content of the message is as shown in <Table 14>.
FIG. 11 is a flowchart showing the operation of the terminal 800 according to the embodiment of the present invention. FIG. 11 will be described with reference to FIG. The terminal 800 can discover the visited SP810 through the lower BDS-SD111, BDS112, or IN113 in another area instead of its own home SP820 and search for the BCAST service in the corresponding area. When searching for the BCAST service, the terminal 800 can find the service guide context fragment 201 in step S1101 and, based on this, receive the entire service guide using the service guide transmission descriptor fragment 202. Upon receiving the service guide, if the terminal 800 wishes to receive the roaming service, in step S1102, a roaming request message for permitting the roaming service is sent to the BSM813 of the visited SP810. The content of the sent message is shown in <Table 16>.
After transmitting the roaming request message, the terminal 800 waits for a response in step S1103. When the roaming contract between the BSM823 of the home SP820 and the BSM813 of the visited SP810 is determined, the terminal 800 receives and decodes the response message to the request from the BSM813 of the visited SP810 in step S1104. The content of the response message is shown in <Table 19>. After that, the terminal 800 determines in step S1105 whether or not roaming is possible by decoding the response message.
If roaming is not possible, terminal 800 abandons roaming. However, when roaming is possible, the terminal 800 confirms the roaming condition of the visited SP810 in step S1106 and determines whether or not it is acceptable. If the roaming conditions are not agreed, in step S1107, the terminal 800 transmits a confirmation message refusing roaming to the BSM813 of the visited SP810. However, if the conditions are agreed, the terminal 800 sends a confirmation message indicating consent to the BSM813 of the visited SP810 in step S1108. After sending the consent message, the terminal 800 receives the long term key message in step S1109 and the BCAST service in step S1110 after preparing for service or content decryption.
FIG. 13 shows a roaming procedure according to an embodiment of the present invention. Prior to explaining each step of the roaming procedure, each entity of FIG. 13 will be described. Since each BSA 1324 and 1314 existing in the home SP 1320 and the visited SP 1310 have the same function as the BSA 102 in FIG. 1, they are described separately to distinguish the BSA of the home SP 1320 and the visited SP 1310 when roaming. Similarly, BSM1323 and 1313 have the same functionality as BSM104 in FIG. 1, BSDA1322 and 1312 have the same functionality as BSDA103 in FIG. 1, and group entities 1321 and 1311 have BDS-SD, BDS, and IN, respectively. It has the same function as BDS-SD111, BDS112, and IN113 in FIG. The terminal 1300 has the same functions as the terminal 105 of FIG. Since not all of the entities mentioned above are used in the roaming procedure, the entities used in the roaming procedure according to the embodiments of the present invention will be described below.
As shown in FIG. 13, steps 1301 and 1302 are parts that are not directly specified in the roaming procedure, and the terminal 1300 arrives at the roaming area and transmits the BCAST service to the lower network BDS, IN, and / or BDS-. Suppose it is automatically performed by SD group entities 1311 and BSDA1312. However, for reference, in step 1301, the group entity 1311 of BDS, IN, and / or BDS-SD, which is a sub-network of BCAST, performs roaming, provides roaming display information to terminal 1300, and terminals. Basic information must be provided based on the ability of the aircraft 1300 to receive the service guide. Using this basic information, the terminal 1300 can receive the service guide in step 1302 by receiving the service guide context fragment 201 of FIG.
Upon receiving the service guide in step 1302, terminal 1300 acquires the information described in <Table 11>. In step 1303, using the information obtained from <Table 11>, the terminal 1300 generates a message for making a roaming registration request to the home SP1320 and sends it to the BSM1323 of the home SP1320. The content of the roaming request message generated by the terminal 1300 in step 1303 is as shown in <Table 21> below.
<tables num="21"><img id="000022" he="41" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The request ID, which is the first item in <Table 21>, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time when it is generated in FIG. 13 until the roaming registration request procedure in FIG. 13 is completed. The terminal ID is a unique ID for uniquely identifying the terminal. The terminal ID is used to identify who made the roaming registration request.
The visited SP ID is an identifier of the service provider who provides the service in the area where the roaming terminal is staying. The visited SP ID is used to provide the home SP1320 service provider with information indicating who the terminal requests roaming with. Here, the BSM1323 of the home SP1320 can determine from the visited SP ID that it does not have its own roaming contract, and immediately proceed to step 1306 to notify the terminal 1300 that roaming is not permitted. The visited SP BSM ID is used to inform the home SP1320 of the entity that actually negotiates the roaming service registration procedure with the BSM identifier used by the visited SP1310. Visit BSDA The ID is the identifier of the BSDA used by the visited SP, and since one service provider can provide the service through various BSDAs, which BSDA the roaming terminal 1300 wants to receive the service through. Used to inform. Finally, the purchased item ID is used to signal the service that the roaming user wants to receive. For the terminal 1300 that requested roaming registration in step 1303, the BSM1323 of the home SP1320 can additionally carry out the authentication process for the terminal 1300, and the detailed process of the authentication stage is the gist of the present invention. Since it has nothing to do with, the explanation is omitted for the sake of simplicity.
In step 1304, in response to the roaming registration request received from the terminal 1300 to step 1303, the roaming registration request is transmitted to the BSM 1313 of the visited SP1310 in which the terminal 1300 is roaming. The content of the message sent from the BSM1323 of the home SP1320 to the BSM1313 of the visited SP1310 in step 1304 is as shown in <Table 22> below.
<tables num="22"><img id="000023" he="48" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The first item in <Table 22>, the request ID, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time when it is generated in FIG. 13 until the roaming registration request procedure in FIG. 13 is completed. The terminal ID is a unique ID for uniquely identifying the terminal. The terminal ID is used to identify who made the roaming registration request. The home SP ID is used to inform which service provider originally received the service from the terminal that requested roaming registration at the visited SP1310. Using this information, it can be seen that the BSM1313 of the visited SP1310 belongs to the service provider whose roaming contract is with the terminal that requested roaming. The home SP BSM ID is used to inform the visited SP1310 of the entities required for the roaming registration process. Visit SP1310 BSM1313 is home SP BSM Respond to roaming registration results based on ID. Visit BSDA The ID is used to provide the visited SP1310 with information indicating the service area where the terminal currently requests service. The subscription type of the terminal is information provided to evaluate the class at which the terminal that made the roaming request to the visited SP1310 can receive the service of the visited SP1310, and is evaluated together with the purchase item ID. Will be done. The subscription type of the terminal can be a grade of service in which the terminal requesting roaming based on the roaming contract concluded between the home SP1320 and the visited SP1310 receives roaming from the requested visited SP1310. It can be defined in the form of roaming authorization grade numbers or codes discussed between the two service providers, which form is not defined in the embodiments of the present invention. The purchase item ID is a service requested by the terminal, which can be received at a separate cost, or the terminal that requested roaming based on the roaming contract between the visited SP1310 and the home SP1320. Receivability is determined based on an assessment of what is processed by the subscription.
In step 1305, the BSM1313 of the visited SP1310 sends a response to the request received in step 1304. The main purpose of step 1305 is to use the information received in step 1304 to inform the roaming service tolerance requested by the terminal. Along with the permission for the roaming service requested by the terminal, the range of services that the terminal can receive from the visited SP1310 is also provided. The message sent from the BSM1313 of the visited SP1310 to the BSM1323 of the home SP1320 in step 1305 is as shown in <Table 23> below.
<tables num="23"><img id="000024" he="23" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The request ID, which is the first item in <Table 23>, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time when it is generated in FIG. 13 until the roaming registration request procedure in FIG. 13 is completed. The roaming permission state is used in step 1304 to provide the result of evaluating the possibility of roaming using the information provided by the visited SP1310 to the BSM1323 of the home SP1320 of the terminal 1300 that requested roaming. The roaming service tolerance is notified to indicate the receive permission that the roaming terminal 1300 actually has at the visited SP1310 when roaming is possible and the value of the terminal subscription type received in step 1304 is roaming. To do. This roaming service tolerance also defines the receivability of the service corresponding to the purchase item ID requested by the terminal 1300. Information related to the occurrence of additional costs or changes in the billing system during roaming is also added to the roaming service allowable range.
The above steps 1304 and 1305 may be omitted if necessary. As an example, it can also be omitted when the terminal 1300 attempts to make an additional service request while receiving a service after completing the roaming registration procedure. At this time, the BSM1323 of the home SP1320 knows part or all of the cost policy for roaming of the BSM1313 of the visited SP1310.
In step 1306, the home SP1320 notifies the terminal 1300 of the result of the roaming registration request received through the visited SP1310 in step 1305. In step 1306, the BSM1323 of the home SP1320 actually transmits the message received in step 1305 to the terminal 1300. In step 1303, after the home SP1320 analyzes the roaming registration request of the terminal, if there is no roaming contract with the visited SP1310 in the area where the terminal 1300 is staying, the home SP1320 proceeds to step 1306 and <Table 23. > Satisfies the content of roaming request registration failure and sends it to the terminal 400. In such cases, roaming has failed.
At step 1307, terminal 1300 sends a response to the roaming registration request sent to its home SP1320. The terminal 1300 informs the BSM1323 of the visited SP1320 whether or not it agrees with the roaming service tolerance of the message received in step 1306. If the terminal 1300 does not agree to the additional cost or change in the billing system incurred when roaming, the roaming service will not be provided. However, if the terminal 1300 agrees, proceed to the next step. <Table 24> below shows a message that the terminal 1300 provides the home SP1320 with a final confirmation for roaming.
<tables num="24"><img id="000025" he="17" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The request ID, which is the first item in <Table 24>, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID is the same from the time when it is generated in FIG. 13 until the roaming registration request procedure in FIG. 13 is completed. The roaming confirmation state is an item for notifying the home SP1320 whether or not the terminal 1300 performs roaming.
At step 1308, the BSM1323 at home SP1320 sends the long-term key message needed to decipher the service requested by terminal 1300 by the terminal 1300 agreeing to roaming at step 1307. Send to.
In step 1309, the BSM1313 of the visited SP1310 delivers the long-term key message requested by the BSM1323 of the home SP1320. At step 1325, BSM1323 at home SP1320 delivers the long-term key message needed to decrypt the roaming service requested by terminal 1300.
Steps 1308, 1309, and 1325 are performed using the long term key transmission / reception method defined in the BCAST standard, and the embodiments of the present invention do not cover detailed processes. At step 1326, terminal 1300 receives the service of the visited SP1310 through roaming.
In addition to the roaming procedure described in FIG. 13, the message items defined in FIG. 13 can be used to enable roaming for service provisioning messages and procedures defined in OMA BCAST. I will not handle it. Documents on the OMA website http://www.openmobilealliance.org/ftp/Public_documents/BAC/BCAST/Permanent_documents/OMA-TS-BCAST_Services-V1_0_0-20050909-D.zip for the above service supply Refer to. The reference document is the latest version at the time of filing the application, and if there is any change in this document in the future, the changed version will be applied.
FIG. 14 is a flowchart showing the operation of BSM1313 of the visited SP1310 according to the embodiment of the present invention. FIG. 14 will be described with reference to FIG. In step S1401, the BSM1313 of the visited SP1310 receives a roaming registration request from the BSM1323 of the home SP1320 of the terminal 1300 that is roaming, and decodes the received request message. The content of the received message is as shown in <Table 22>, and the BSM1313 of the visited SP1310 analyzes the terminal subscription type in the content of the received message in step S1402. After that, BSM1313 of the visited SP1310 analyzes the relationship between the subscription of the terminal requesting roaming and its own subscription policy in step S1403 to determine the roaming possible range. Request roaming If the terminal subscription is insufficient to support roaming, the BSM1323 at home SP1320 generates a message rejecting the roaming request and transmits it to BSM1323 at home SP1320 in step S1404. However, when it is determined that roaming is possible by subscribing to the terminal that requested roaming, the BSM1313 of the visited SP1310 determines in step S1405 whether or not there is a specific request such as a purchased item. When there is a specific request, BSM1313 of the visited SP1310 calculates the charge, and if there is no specific request, it calculates the additional charge incurred when roaming. After the calculation is complete, the visited SP1310 BSM1313 generates a response message to the roaming request. The content of the generated message is as shown in <Table 23>.
After the completion of step S1405, the BSM1313 of the visited SP1310 waits for the final confirmation of roaming from the terminal 1300 in step S1406. When the terminal 1300 requesting roaming sends a final confirmation message for roaming, the BSM1313 of the visited SP1310 receives and decodes the message in step S1407. After decoding the received message, the BSM1313 of the visited SP1310 determines in step S1408 whether the terminal 1300 agrees to the roaming conditions. If the terminal 1300 does not agree with the roaming conditions, the roaming procedure with the terminal 1300 ends. On the other hand, if the terminal 1300 agrees to the roaming conditions, the BAM1313 of the visited SP1310 sends a long-term key message for decoding the service received in step S1409 to the home SP1320. Upon receiving the long-term key message, the home SP1320 transfers the received long-term key message to the terminal 1300, and the terminal 1300 can use the roaming service within the range agreed by itself.
15A and 15B are flowcharts showing the operation of BSM1323 of the home SP1320 according to the embodiment of the present invention. 15A and 15B will be described with reference to FIG.
Home SP In step S1501, the 1320 BSM1323 receives a roaming request message from the roaming terminal 1300 and decodes the received message. The messages received by Home SP1320 are as shown in <Table 21>. Using the decrypted message, the BSM1323 of the home SP1320 determines in step S1502 whether or not there is a roaming contract with the visited SP1310 in which the terminal 1300 requesting roaming stays. Without a contract, BSM1323 at home SP1320 proceeds to step S1509 to perform the process without a roaming contract. In step S1509, BSM1323 at home SP1320 may include, if necessary, the reason for roaming disapproval, or if possible, a partially available service while notifying the roaming disapproval subscription. Can convey the type of. However, if there is a roaming contract, the BSM1323 of the home SP1320 searches for the subscription of the corresponding terminal 1300 in step S1503, and then whether or not the subscription of the terminal 1300 searched in step S1504 is a roaming allowable subscription. Is determined.
BSM1323 of home SP1320 proceeds to step S1509 to notify that it is a roaming unauthorized subscription if it is a subscription that does not support roaming. In step S1509, BSM1323 at home SP1320 can include the reason for roaming disapproval when needed, or, if possible, communicate the type of service that is partially available, while notifying the roaming disapproval subscription. .. If the subscription assists roaming, BSM1323 at home SP1320 sends a roaming permission request message to BSM1313 at visited SP1310 in step S1505. The content of the message is as shown in <Table 22>. After sending the request message, BSM1323 at home SP1320 waits for a response from the visited SP1310 in step S1506. Upon receiving the response to the request, BSM1323 at home SP1320 decodes the received message in step S1507 and analyzes the result for the request in step S1508. If the requirement is unacceptable, BSM1323 at home SP1320 will proceed to step S1509, including the reason for roaming disapproval when needed, or partially using it if possible, informing them of the roaming disapproval subscription. Can be transmitted. However, if it is determined that roaming is possible by subscribing to the terminal that requested roaming, the BSM1323 of the home visit SP1320 will be like a purchased item in step S1510 in addition to the message received in step S1507. Determine if there is a specific request. When there is a specific request, BSM1323 of the home SP1320 calculates the charge, and if there is no specific request, it calculates the additional charge incurred when roaming. After the calculation is complete, BSM1323 at home SP1320 generates a response message to the roaming request. The content of the generated message is as shown in <Table 23>.
After the completion of step S1510, the BSM1323 of the home SP1320 waits for the final confirmation of roaming from the terminal 1300 in step S1511. When the terminal 1300 requesting roaming sends a final confirmation message for roaming, BSM1323 of the home SP1320 receives and decodes the message in step S1512. The content of the received message is as shown in <Table 14>, and the BSM1323 of the home SP1320 determines in step S1513 whether or not the terminal 1300 agrees with the roaming conditions. If the terminal 1300 does not agree with the roaming conditions, the roaming procedure with the terminal 1300 ends. Otherwise, if the roaming conditions are agreed, BAM1323 at home SP1320 will be sent a long term key message to decrypt the service received in step S1514. Upon receiving the long-term key message from the visited SP1310 in step S1515, the home SP1320 transfers the long-term key message received to the terminal 1300 in step S1516 so that the terminal 1300 is within the range agreed by itself. You can use the roaming service at.
FIG. 16 is a flowchart showing the operation of the terminal 1300 according to the embodiment of the present invention. FIG. 16 will be described with reference to FIG. The terminal 1300 can discover the visited SP1310 through the lower BDS-SD111, BDS112, or IN113 in another area instead of its own home SP1320 and search for the BCAST service in the corresponding area. When searching for the BCAST service, the terminal 1300 can search for the service guide context fragment 201 in step S1601, and based on this, can receive the entire service guide using the service guide transmission descriptor fragment 202. Upon receiving the service guide, if the terminal 1300 wishes to receive the roaming service, in step S1602, it sends a roaming request message for roaming service permission to BSM1323 of its home SP1320. At this time, the content of the message to be sent is as shown in <Table 21>. After sending the roaming request message, the terminal 1300 waits for a response in step S1603. When the roaming contract between the BSM1323 of the home SP1320 and the BSM1313 of the visited SP1310 is determined, the terminal 1300 receives and decodes the response message to the request from the BSM1323 of the home SP1320 in step S1604. The content of the response message is as shown in <Table 23>. After that, the terminal 1300 determines in step S1605 whether or not roaming is possible by decoding the response message.
If roaming is not possible, the terminal 1300 gives up roaming. However, when roaming is possible, the terminal 1300 confirms the roaming condition of the visited SP1310 in step S1606 and determines whether or not it is acceptable. If the roaming conditions are not agreed, in step S1307, the terminal 1300 transmits a confirmation message refusing roaming to the BSM1313 of the visited SP1310. However, if the conditions are agreed, the terminal 1300 sends a confirmation message confirming the agreement to BSM1313 of the visited SP1310 in step S1608. After transmitting the consent message, the terminal 1300 receives the long term key message in step S1609, and receives the BCAST service in step S1610 after preparing for service or content decryption.
Next, the purchase item list request procedure during roaming according to the fourth embodiment of the present invention will be described. FIG. 17 shows a purchase item list request during roaming according to an embodiment of the present invention. When roaming according to the embodiment, first, each entity of FIG. 17 will be described prior to the description of each step of the purchase item list request procedure.
Since each BSA 1724 and 1714 existing in the home SP 1720 and the visited SP 1710 have the same function as the BSA 102 in FIG. 1, they are described separately in order to differentiate the BSA of the home SP 1720 and the visited SP 1710 when roaming. Similarly, BSM1723 and 1713 have the same functionality as BSM104 in FIG. 1, BSDA1722 and 1712 have the same functionality as BSDA103 in FIG. 1, and group entities 1721 and 1711 have BDS-SD, BDS, and IN, respectively. It has the same function as BDS-SD111, BDS112, and IN113 in FIG. The terminal 1700 has the same functions as the terminal 105 of FIG. Since not all of the above-mentioned entities are used in the purchase item list request procedure during roaming according to the embodiment of the present invention, only the entities used in the purchase item list request procedure for roaming will be described. Also, the procedure shown in FIG. 17 is selectively used during roaming and can be used between steps 402 and 403 in FIG. 4 or between steps 1302 and 1303 in FIG.
Referring to FIG. 17, using the information shown in <Table 11> obtained through the reception of the service guide in step 1701, the terminal 1700 requests information indicating the purchase items that can be subscribed to when roaming. Generate a purchase item list request message and send it to BSM1723 at home SP1720. The content of the purchase item list request message generated by terminal 1700 in step 1701 is as shown in <Table 25> below.
<tables num="25"><img id="000026" he="35" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The request ID, which is the first item in <Table 25>, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID can be used with the roaming purchase item list request procedure shown in FIG. 17 and is the same as the request ID in <Table 16> to <Table 20> or <Table 21> to <Table 24>. The terminal ID is a unique ID for uniquely identifying the terminal. The terminal ID is used to identify who made the roaming registration request. The visited SP ID is an identifier of a service provider who provides a service in the area where the roaming terminal stays.
The visited SP ID is used to provide the home SP1720 service provider with information indicating who the terminal requests roaming with. Here, the BSM1723 of the home SP1720 can determine from the visited SP ID that it does not have its own roaming contract, and immediately proceed to step 1704 to notify the terminal 1700 that roaming is not permitted. The visited SP BSM ID is used to inform the home SP1320 of the entity that actually negotiates the roaming service registration procedure with the BSM identifier used by the visited SP1710.
The visited BSDA ID is the identifier of the BSDA used by the visited SP1710, and since one service provider can provide services through various BSDAs, the roaming terminal 1700 is used by the visited SP1710. It is used to inform which of the BSDA's BSDA you want to receive the service. In step 1701, the BSM1723 of the home SP1720 additionally performs an authentication process for the terminal for the terminal that requested the purchase item list during roaming, and this authentication process has nothing to do with the gist of the present invention. The description is omitted for clarity.
Upon receiving the purchase item list request message from terminal 1700 in step 1702, BSM1723 at home SP1720 sends a request for the purchase item list to BSM1713 at visit SP1710 where terminal 1700 is roaming. The content of the message sent from BSM1723 of home SP1720 to BSM1713 of visited SP1710 is as shown in <Table 26> below.
<tables num="26"><img id="000027" he="42" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The request ID, which is the first item in <Table 26>, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID can be used with the roaming purchase item list request procedure shown in FIG. 17 and is the same as the request ID in <Table 16> to <Table 20> or <Table 21> to <Table 24>. The terminal ID is a unique ID for uniquely identifying the terminal. The terminal ID is used to identify who made the roaming registration request.
The home SP ID is used to inform which service provider originally received the service from the terminal 1700 that requested roaming registration at the visited SP1710. Using this information, it can be seen that the BSM1713 of the visited SP1710 belongs to the service provider whose roaming contract is with the terminal that requested roaming. The home SP BSM ID is used to inform the visited SP1710 of the entities required for the roaming registration process. The BSM1713 of the visited SP1710 responds to the roaming registration result based on the BSM ID of the home SP1720.
The visited BSDA ID is used to provide the visited SP1710 with information indicating the service area where the terminal currently requests service. The subscription type of the terminal is information provided for evaluating the class at which the terminal that has made a roaming request to the visited SP1710 can receive the service of the visited SP1710. The subscription type of the terminal can be the grade of service that the terminal 1700 that requested roaming based on the roaming contract concluded between the home SP1720 and the visited SP1710 receives roaming from the requested visited SP1710. It can be defined in the form of roaming authorization grade numbers or codes discussed between the two service providers, which form is not defined in the embodiments of the present invention.
In step 1703, the BSM1713 of the visited SP1710 sends a response to the request received in step 1702. The main purpose of step 1703 is to use the information received in step 1702 to inform the roaming service tolerance requested by terminal 1700. The BSM1713 of this visited SP1710 can also selectively provide roaming service tolerances. In step 1703, the message sent from the BSM1713 of the visited SP1710 to the BSM1723 of the home SP1720 is as shown in <Table 27> below.
<tables num="27"><img id="000028" he="30" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The request ID, which is the first item in <Table 27>, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID can be used with the roaming purchase item list request procedure shown in FIG. 17 and is the same as the request ID in <Table 16> to <Table 20> or <Table 21> to <Table 24>. The roaming permission state is used in step 1702 to provide the result of evaluating the possibility of roaming using the information provided by the visited SP1710 to the BSM1723 of the home SP1720 of the terminal 1700 that requested roaming. The roaming service tolerance is notified to indicate the receive authority that the roaming terminal 1700 actually has at the visited SP1710 when roaming is possible and the value of the received terminal subscription type is roaming. The purchase item list is a service list that the terminal 1700 roaming to the purchase item ID list can subscribe to at the visited SP1710.
In step 1704, the home SP1720 notifies the terminal 1700 of the result of the roaming purchase item list request received through the visited SP1710 in step 1703. In step 1704, in fact, in step 1704, the BSM1723 of the home SP1720 further transmits the message received in step 1703 to the terminal 1700. In step 1701, after the home SP1720 analyzes the roaming registration request of the terminal, if there is no roaming contract with the destination SP1710 in the area where the terminal 1700 is staying, the home SP1720 immediately proceeds to step 1704 and <Table. Fill the content of 27> with the requested process failure and send it to the terminal 1700. In this case, the terminal 1700 fails the above request. Upon receiving the purchase item list in step 1704, the terminal 1700, when displaying the purchase items of the service guide received by itself to the user, compares the purchase items in the received list with the purchase items present in the above list. Show only.
FIG. 18 is a flowchart showing the operation of BSM1713 of the visited SP1710 according to the embodiment of the present invention. FIG. 18 will be described with reference to FIG. Referring to FIG. 18, the BSM1713 of the visited SP1710 receives and decodes the purchase item list request message from the BSM1723 of the home SP1720 of the roaming terminal 1700 in step S1801. This received message is shown in <Table 26>. In step S1802, BSM1713 of the visited SP1710 analyzes the terminal subscription type in the content of the received purchase item list request message.
After analyzing the content with the subscription policy of the terminal that requested the purchase item list in step S1802, the BSM1713 of the visited SP1710 confirms the purchase item list that can be subscribed during roaming in step S1803. Since the subscription of the roaming requested terminal 1700 is insufficient to support roaming, in step S1805, a request rejected message is generated and transmitted to the BSM 1723 of the home SP1720. Joining the terminal that requested roaming When it is determined that roaming is possible, in step S1804, a purchase item list is generated and a response message is sent to BSM1723 of the terminal home SP1720. The content of this message is shown as shown in <Table 27>.
FIG. 19 is a flowchart showing the operation of the BSM 1732 of the home SP1720 according to the fourth embodiment of the present invention. FIG. 19 will be described with reference to FIG. Referring to FIG. 19, the BSM1723 of the home SP1720 receives and decodes the purchase item list request message from the roaming terminal 1700 during roaming in step S1901. The messages received by the home SP1720 are as shown in <Table 25>. Using the decrypted message, BSM1723 of the home SP1720 first checks whether step S1902 has a roaming contract relationship with the visited SP1710 where the terminal 1700 that requested the purchase item list during roaming stays. If not in a contractual relationship, BSM1723 at home SP1720 proceeds to step S1909 to carry out the process without roaming permission. In step 1909, the BSM1723 of the home SP1720 can also include the reason for roaming disapproval when needed while notifying the roaming disapproval subscription.
However, in the case of a roaming contract relationship, the BSM1723 of the home SP1720 searches for the subscription of the corresponding terminal 1700 in step S1903, and determines whether or not the subscription of the searched terminal 1700 is a roaming allowable subscription.
If the received subscription of terminal 1700 is a subscription that does not support roaming, BSM1723 of the home SP1720 proceeds to step S1909 to process to notify that it is a roaming unauthorized subscription. In step S1909, the reason for roaming disapproval can be included when necessary while notifying the roaming disapproval subscription.
For subscriptions that support roaming, BSM1723 at home SP1720 sends a roaming purchase item list request message to BSM1713 at visited SP1710. The content of this message is as shown in <Table 26>. The BSM1723 of the home SP1720 that sent the request message waits for a response from the visited SP1710 in step S1906. Upon receiving the result for the request, BSM1723 of the home SP1720 decodes the response message in step S1907, and generates and transmits a message notifying the result of the roaming purchase item list request requested to the terminal 1700 together with step S1908.
FIG. 20 is a flowchart showing the operation of the terminal 1700 according to the embodiment of the present invention. FIG. 20 will be described with reference to FIG. Referring to FIG. 20, in step S2001, terminal 1700 sends a purchase item list request message to BSM1723 of its home SP1720 during roaming in order to know the list of purchase items that it can subscribe to in the area when roaming. Send. After that, the terminal 1700 waits for a response from BSM1723 of the home SP1720 in step S2002. Here, the content of the transmitted message is shown as shown in <Table 25>. Upon receiving the response message from BSM1723 of the home SP1720, the terminal 1700 displays to the user the purchase items that exist when the purchase item list received in step S2003 is compared with the purchase items of the service guide received by itself. The messages received by the terminal at this time are shown in <Table 27>.
Next, the purchase item list request procedure at the time of roaming according to the embodiment of the present invention will be described. FIG. 21 shows a purchase item list request procedure during roaming according to an embodiment of the present invention. First, each entity of FIG. 21 will be described prior to the description of each step of the roaming procedure according to the embodiment.
Since each BSA2124 and 2114 existing in the home SP2120 and the visited SP2110 have the same function as the BSA102 in FIG. 1, they are described separately in order to differentiate the BSA of the home SP2120 and the visited SP2110 when roaming. Similarly, BSM2123 and 2113 have the same functionality as BSM104 in FIG. 1, BSDA2122 and 2112 have the same functionality as BSDA103 in FIG. 1, and group entities 2121 and 2111 have BDS-SD, BDS, and IN, respectively. It has the same function as BDS-SD111, BDS112, and IN113 in FIG. The terminal 2100 has the same functions as the terminal 105 of FIG. Since not all of the above-mentioned entities are used in the purchase item list request procedure during roaming according to the embodiment of the present invention, only the entities used in the purchase item list request procedure for roaming will be described. Also, the procedure shown in FIG. 21 is selectively used during roaming and can be used between steps 802 and 803 of the embodiments of the present invention.
Referring to FIG. 21, using the information shown in <Table 11> obtained through the reception of the service guide in step 2101, the terminal 2100 provides information indicating the purchase items that the terminal 2100 can subscribe to when roaming. Generate a purchase item list request message to request and send it to BSM2113 of the visited SP2110. The content of the purchase item list request message generated by the terminal 2100 in step 2101 is shown in <Table 28> below.
<tables num="28"><img id="000029" he="30" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The request ID, which is the first item in <Table 28>, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID can be used together with the purchase item list request procedure during roaming shown in FIG. 21, and is the same as the request ID in <Table 16> to <Table 20>. The terminal ID is a unique ID for uniquely identifying the terminal. The terminal ID is used to identify who made the roaming registration request.
The home SP ID is an identifier used by the roaming terminal 2100 to inform the visited SP2110 who their home SP2120 is. Using this information, the visited SP2110 can determine the entity to which the terminal 2100 that requested roaming belongs first, and can confirm the roaming relationship with that entity. Here, if the BSM2113 of the visited SP2110 does not have a roaming contract with himself / herself from the home SP ID, he / she can proceed to step 2104 and notify the terminal 2100 of the roaming disapproval.
The home SP BSM ID is used as an identifier for the BSM2123 used by the home SP2120 to inform the visiting SP2110 of the entity that actually negotiates the roaming service registration procedure. Finally, the purchased item ID is used to signal the service that the roaming user wants to receive. For the terminal that requested roaming registration in step 2101, the BSM2113 of the visited SP2110 can additionally carry out the authentication process for the terminal. This can be done voluntarily by the BSM2113 of the visited SP2110, in contact with the BSM2123 of the home SP2120, or through a third authentication entity. Therefore, since the detailed process of the certification stage has nothing to do with the gist of the present invention, the description thereof will be omitted for the sake of simplicity.
In step 2102, the BSM2113 of the visited SP2110 transmits the roaming registration request to the BSM2123 of the home SP2120 of the terminal 2100 in response to the roaming registration request received from the terminal 2100 to the step 2101. The content of the message sent from the BSM2113 of the visited SP2110 to the BSM2123 of the home SP2120 in step 2102 is as shown in <Table 29> below.
<tables num="29"><img id="000030" he="30" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The first item in <Table 29>, the request ID, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID can be used together with the purchase item list request procedure during roaming shown in FIG. 21, and is the same as the request ID in <Table 16> to <Table 20>. The terminal ID is a unique ID for uniquely identifying the terminal. The terminal ID is used to identify who made the roaming registration request. The visited SP ID is used by the visited SP2110 to inform the BSM2123 of the home SP2120 of the terminal that requested roaming registration of its information. The visited SP BSM ID is used by the visited SP2110 to inform the BSM2123 of the home SP2120 of the entity with which it has roaming-related negotiations. This is because the visited SP2110 can have various BSMs.
At step 2103, BSM2123 at home SP2120 sends a response to the roaming registration request received at step 2102. <Table 30> below shows the message content sent from BSM2123 of home SP2120 to BSM2113 of visited SP2110.
<tables num="30"><img id="000031" he="24" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The request ID, which is the first item in <Table 30>, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID can be used together with the purchase item list request procedure during roaming shown in FIG. 21, and is the same as the request ID in <Table 16> to <Table 20>. The roaming permission status is determined after the home SP2120 determines and confirms whether roaming is permitted by searching for the subscription of the terminal 2100 that requested roaming to the visited SP2110 using the terminal ID received in step 2103. , Used to provide the results to the visited SP2110.
The subscription type of the terminal 2100 is information provided by the visited SP2110 to evaluate the reception right of the roaming terminal 2100 at the visited SP2110. The subscription type of the terminal can be the grade of service that the terminal 2100 that requested roaming based on the roaming contract concluded between the home SP2120 and the visited SP2110 receives roaming from the requested visited SP2110. It can be defined in the form of a roaming authorization grade number or code agreed between the two service providers, which form is not defined in the embodiments of the present invention.
In step 2104, the visited SP2110 sends a response to the roaming registration request received by the terminal 2100. The content of the message sent by the BSM2113 of the visited SP2110 to the terminal 2100 in step 2104 is as shown in <Table 31> below.
<tables num="31"><img id="000032" he="24" wi="91" file="JP5241908B2_D0001.tif" img-format="tif" img-content="drawing" /></tables>
The request ID, which is the first item in <Table 31>, is an identifier given so that one roaming registration request procedure can be consistently identified and managed. The request ID is an identifier generated for the terminal to uniquely identify its roaming registration request. This request ID can be used together with the purchase item list request procedure during roaming shown in FIG. 21, and is the same as the request ID in <Table 16> to <Table 20>. The roaming permission state is used in step 2105 to provide the terminal 2100 requesting roaming with the result of evaluating the possibility of roaming using the information provided by the home SP2120. The purchase item list is a service list that allows the roaming terminal 2100 to subscribe to the visited SP2110 as a list of purchase item IDs.
Upon receiving the purchase item list in step 2104, the terminal 2100 displays the purchase items in the service guide received by the user to the purchase items in the above list in comparison with the purchase items in the received list. Show only.
FIG. 22 is a flowchart showing the operation of BSM2113 of the visited SP2110 according to the embodiment of the present invention. FIG. 22 will be described with reference to FIG. Referring to FIG. 22, the BSM2113 of the visited SP2110 receives and decodes the purchase item list request message during roaming from the terminal 1700 roaming in step S2201. The message received by BSM2113 of the visited SP2110 is as shown in <Table 28>. In step S2202, the BSM2113 of the visited SP2110 uses the contents of the decrypted message to determine whether the terminal 2100 that requested the purchase item list at the time of roaming is the terminal of the service provider having a roaming contract relationship. To judge. If the terminal 2100 belongs to a service provider not related to the roaming contract, the BSM2113 of the visited SP2110 proceeds to step S2208 and transmits a response message to the terminal 2100 to disallow roaming. In step 2208, the BSM2113 of the visited SP2110 can include the reason for roaming disapproval when necessary while notifying the roaming disapproval message.
However, if the terminal 2110 belongs to a service provider related to the roaming contract, the BSM2113 of the visited SP2110 will terminal to the BSM2123 of the home SP2120 of the terminal that requested the purchase item list at the time of roaming in step S2203. Transmit the machine request message. At this time, the content of the transmitted message is as shown in <Table 29>. After that, the visited SP2110BSM2113 waits for a response message from the BSM2123 of the home SP2120 of the terminal 2100 that made the roaming request in step S2204. The BSM2113 of the visited SP2110 decodes the received response message after receiving the response message from the BSM2123 of the home SP2120 in step S2205. At this time, the content of the received response message is as shown in <Table 30>.
After analyzing the content of the received message, BSM2113 at the visited SP2110 determines in step S2206 whether the terminal 2100 is allowed to provide a roaming purchase item list. The BSM2113 of the visited SP2110 can include the reason for roaming disapproval when necessary while notifying the roaming disapproval message in step S2208. However, if the BSM2113 of the visited SP2110 permits, in step 2207, the purchase item list at the time of roaming is generated using the subscription information of the terminal 2100 and transmitted to the terminal 2100.
FIG. 23 is a flowchart showing the operation of BSM2123 of the home SP2120 according to the embodiment of the present invention. FIG. 23 will be described with reference to FIG. Referring to FIG. 23, the BSM2123 of the home SP2120 receives and decodes the terminal subscription information request message for the terminal requesting the purchase item list request at the time of roaming from the BSM2113 of the visited SP2110 in step S2301. The content of the message received by this home SP2120 is as shown in <Table 29>. In step S2302, BSM2123 of the home SP2120 searches for the subscription of the terminal 2100 that requested the purchase item list at the time of roaming at the visited SP2110. After that, the BSM2123 of the home SP2120 determines in step S2303 whether or not the terminal 2100 requesting the purchase item list at the time of roaming receives the roaming service. When the terminal 2100 comes to receive the roaming service, in step 2304, a message including the content shown in <Table 30> including the subscription of the terminal 2100 is transmitted to the visited SP2110. However, if the terminal 2100 is prevented from receiving the roaming service, the BSM32123 of the home SP2120 transmits a roaming disapproval message to the visited SP2110 in step S2305.
FIG. 24 is a flowchart showing the operation of the terminal 2100 according to the embodiment of the present invention. FIG. 24 is described with reference to FIG. Referring to FIG. 24, in step S2401, the terminal 2100 sends a purchase item list request message to BSM2113 of the visited SP2110 at the time of roaming in order to know the purchase item list that can be subscribed in the corresponding area where the terminal 2100 performs roaming. .. At this time, the content of the transmitted message is as shown in <Table 28>. In step S2402, the terminal 2100 waits for a response from BSM2113 of the visited SP210. After that, in step S2403, the terminal 2100 receives a response message from BSM2113 of the visited SP2110, compares the received purchase item list with the purchase item of the service guide received by itself, and selects the purchase item in the above list. indicate. At this time, the message received by the terminal 2100 is shown as shown in <Table 31>.
Although the specific embodiments have been described above in the detailed description of the present invention, it is possible for a person having ordinary knowledge in the art to make various changes as long as the claims are not made. Is clear. Therefore, the scope of the present invention is not limited to the above-described embodiment, but should be determined based on the description of the scope of claims and equivalents thereof.
400; terminal 410; Visit SP 420; Home SP
56 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33 Sheet 34 Sheet 35 Sheet 36 Sheet 37 Sheet 38 Sheet 39 Sheet 40 Sheet 41 Sheet 42 Sheet 43 Sheet 44 Sheet 45 Sheet 46 Sheet 47 Sheet 48 Sheet 49 Sheet 50 Sheet 51 Sheet 52 Sheet 53 Sheet 54 Sheet 55 Sheet 56
Every citation, both waysCites: the store holds 4 of 5
| Document | Relation | Office |
|---|---|---|
| JP2001285916A | Cites | Japan |
| JP2004007422A | Cites | Japan |
| JP2007518380A | Cites | Japan |
| JP2008508831A | Cites | Japan |
| Mobile Broadcast Services,Open Mobile Alliance OMA-TS-BCAST_Services-V1_0-20080226-C,2008年 6月 9日,Candidate Version 1.0 - 26 Feb 2008,Appendix E. Walk-through of Broadcast Roaming (Informative),URL,http://technical.openmobilealliance.org/Technical/release_program/docs/BCAST/V1_0-20080609-C/OMA-TS-BCAST_Services-V1_0-20080609-C.pdf | Non-patent | – |
| Mobile Broadcast Services Architecture,Open Mobile Alliance OMA-AD-BCAST-V1_0-20050505-D,2005年 5月 5日,Draft Version 1.0 - 05 May 2005,5.4.8 Roaming related flows,URL,http://www.member.openmobilealliance.org/ftp/Public_documents/BAC/BCAST/Permanent_documents/OMA_AD_BCAST_V1_0_0-20050505-D.zip | Non-patent | – |
| Service Guide for Mobile Broadcast Services,Open Mobile Alliance OMA-TS-BCAST_ServiceGuide-V1_0_0-20050512-D,2005年 5月12日,Draft Version 1.0 - 12 May 2005,URL,http://member.openmobilealliance.org/ftp/Public_documents/bcast/Permanent_documents/OMA-TS-TS-BCAST_ServiceGuide-V1_0_0-20050512-D.zip | Non-patent | – |
27 members in 9 offices
Priority claims15
| Document | Office | Kind | Date |
|---|---|---|---|
| 1020050097241 | Republic of Korea | – | |
| 20050097241 | Republic of Korea | A | |
| 20050097241 | Republic of Korea | A | |
| 1020050106213 | Republic of Korea | – | |
| 20050106213 | Republic of Korea | A | |
| 20050106213 | Republic of Korea | A | |
| 1020060035949 | Republic of Korea | – | |
| 20060035949 | Republic of Korea | A | |
| 20060035949 | Republic of Korea | A | |
| 2005200597241 | – | – | – |
| 20052005106213 | – | – | – |
| 2006200635949 | – | – | – |
| KR20050097241 | – | – | – |
| KR20050106213 | – | – | – |
| KR20060035949 | – | – | – |
Members27
| Document | Office | Kind | |
|---|---|---|---|
| EP1775904A1 | European Patent Office (EPO) | A1 | |
| KR20070041296A | Republic of Korea | A | |
| AU2006300029A1 | Australia | A1 | |
| CA2622235A1 | Canada | A1 | |
| WO2007043849A1 | World Intellectual Property Organization (WIPO) | A1 | |
| US2007093202A1 | United States of America | A1 | |
| EP1909463A1 | European Patent Office (EPO) | A1 | |
| KR100856256B1 | Republic of Korea | B1 | |
| CN101288248A | China | A | |
| JP2009512329A | Japan | A | |
| RU2008114347A | Russian Federation | A | |
| RU2381624C2 | Russian Federation | C2 | |
| AU2006300029B2 | Australia | B2 | |
| EP2285143A1 | European Patent Office (EPO) | A1 | |
| EP2285144A1 | European Patent Office (EPO) | A1 | |
| US8055258B2 | United States of America | B2 | |
| US2012034909A1 | United States of America | A1 | |
| JP2012095332A | Japan | A | |
| JP4949406B2 | Japan | B2 | |
| US8249587B2 | United States of America | B2 | |
| EP1775904B1 | European Patent Office (EPO) | B1 | |
| CN101288248B | China | B | |
| JP5241908B2This record | Japan | B2 | |
| CA2622235C | Canada | C | |
| EP1909463B1 | European Patent Office (EPO) | B1 | |
| EP2285144B1 | European Patent Office (EPO) | B1 | |
| EP2285143B1 | European Patent Office (EPO) | B1 |
18 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 |
Numbers
- Publication
- 5241908
- Publication, DOCDB
- 5241908
- Publication, EPODOC
- JP5241908B
- Application
- 278054
- Application, DOCDB
- 2011278054
- Application, EPODOC
- JP20110278054
Titles2
- Japanese
- モバイル放送システムにおけるローミングサービス方法及びそのシステム
- English
- Roaming service method and its system in mobile broadcasting system
Classification
- CPC, 9
- H04H20/26
- H04W48/14
- H04H60/72
- H04L63/0428
- H04W4/06
- H04W36/00
- H04W80/04
- H04L67/04
- H04W36/0007
- IPC, 4
- H04W4 06
- H04W8 12
- H04W76 02
- H04W4 00
