JP2005277526A - Mobile communication system and server - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prevent information required for content request processing from becoming deficient even in case of a mobile terminal for WAP(Wireless Application Protocol)/MMS(Multimedia Messaging Service). <P>SOLUTION: When a mobile terminal (UE)1 acquires a content, profile information consisting of the information of a user agent related to the mobile terminal 1, user information (User-Profile), selfcare information (Selfcare-Profile), and mobile terminal information (UE-Profile) is created at the profile section 33 of an R2M11. The profile information is supplied from the profile section 33 to a JSP10b. The JSP10b attaches the extension header of a parameter indicative of the performance or capacity of the mobile terminal to a content request (HTTP Req) delivered from the mobile terminal 1 based on the profile information. The HTTP Req attached with the extension header is delivered to an origin server 21 so that a content capable of exhibiting the performance or capacity of the mobile terminal 1 sufficiently can be acquired. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a mobile communication system and a server device that can be connected to the Internet from a mobile terminal such as a mobile phone.

2. Description of the Related Art Conventionally, mobile communication systems that can connect to the Internet from mobile terminals such as mobile phones have been operated. However, in the conventional mobile communication system, a unique protocol is used for each mobile communication carrier.
In recent years, so-called third-generation mobile phone services are being introduced. In this third-generation mobile communication system, standardization is being promoted so that the same mobile terminal can be used in common all over the world. The WAP (Wireless Application Protocol) and MMS (Multimedia Messaging Service) standards are adopted as common specifications (Non-patent Document 1).

As described above, when the third generation service is started, there are mobile terminals that have been conventionally provided and that are compatible with each mobile carrier's own protocol and mobile terminals that are compatible with the WAP / MMS. It will be.
Each mobile telecommunications carrier provided a unique service based on its own protocol, but from now on, subscribers of WAP / MMS compatible mobile terminals will increase. For this reason, not only mobile terminals that support each mobile carrier's own protocol, but also those mobile terminals that support WAP / MMS have traditionally become mobile terminals that support each mobile carrier's own standard. It is required to provide a service similar to that provided to the customer.

  For example, in a mobile terminal in a conventional mobile communication system, specifications unique to the mobile communication carrier are embedded inside. For this reason, mobile terminal information and user information held by the mobile terminal itself are attached to a request for content sent from the mobile terminal when the content is acquired by connecting to the Internet. However, since it is assumed that a WAP / MMS compatible mobile terminal cannot embed information that could previously be embedded in the mobile terminal, user information or There are mobile terminals that cannot attach mobile terminal information to requests. As a result, there is a problem in that there is a possibility that a shortage of information necessary for request processing in a server providing content on the Internet side may occur.

In order to solve this problem, it is conceivable that the server on the mobile communication system side supplements the request with user information or mobile terminal information and sends the request to the Internet side. However, user information that can identify subscribers is stored in a database used for authentication and billing due to its nature, and mobile terminal information consisting of model information and information indicating performance is constructed by a mobile terminal manufacturer. Since the database is stored separately, the server cannot supplement user information and mobile terminal information unless inquiries are made at a plurality of locations. Therefore, there is a problem that the processing amount of the server to be supplemented at the time of receiving the request increases and service delay occurs, and even data that is not always required must be retained inside.
The WAP Forum Ltd., "WAP 2.0 Technical White Paper", [online], (2002.01.18), [searched on November 15, 2003], Internet <URL: http: //www.wapforum.org/what /WAPWhite#Paper1.pdf>

  Therefore, according to the present invention, even in a mobile terminal compatible with WAP / MMS, information required for processing a content request request is not short, and the mobile does not increase the processing amount of a server that supplements the required information. It aims at providing a body communication system.

  In the present invention, user information acquired from an information management server that centrally manages user-related information and mobile terminal information, and information that is lacking in content request requests are complemented by the mobile terminal information and sent to the origin server. This is the main feature.

  The mobile communication system and server device of the present invention complements information lacking in a content request request with user information and mobile terminal information acquired from an information management server that centrally manages user-related information and mobile terminal information.・ Being sent to the server, there is no shortage of information required when processing a content request from a WAP / MMS compatible mobile terminal, and the processing amount of the server that supplements the required information increases. Can be prevented.

FIG. 1 is a block diagram showing the overall configuration of an embodiment of a mobile communication system of the present invention.
In this figure, 1 is a mobile terminal (UE: User Equipment) such as a mobile phone, 2 is a radio base station (BTS: Base Transceiver Station) to which the mobile terminal 1 is connected, and 3 is a plurality of radio base stations 2. A radio base station controller (RNC) 4 to be managed is connected to the radio base station controller 3, and a mobile communication switching center (MSC) that performs call connection control, service control, etc. of the mobile terminal 1 Switching Center).
Reference numeral 5 denotes a gateway (SGSN) serving as the radio base station controller (RNC) 3 and a core network (packet network), and 6 denotes a gateway between the core network (packet network) and an IP network such as the Internet. (GGSN: Gateway GPRS Support Node).

  10 is a node (WAP-GW: WAP-Gateway) that converts WAP and HTTP (HyperText Transfer Protocol), and moves to a WAP standard function by converting the received request into an appropriate format and sending it to the subsequent stage. It is a coordination server (WAP-GW and JSP) having an application gateway (JSP: J-Phone Scheme Proxy) that performs coordination with an extended function by a telecommunications carrier. Note that HTTP is an application level protocol used for transferring a document such as an HTML (Hyper Text Markup Language) file between a web browser and a web server. 11 includes a RADIUS server 11a that performs RADIUS session management, and WAP / MMS service subscribers are required to use user information and information on mobile terminal capabilities (UE) when using services such as Web and Mail. -Profile) and the like, and is an information management server (R2M: RADIUS & Repository Manager) provided in response to a request from a client.

  The R2M11 includes a RADIUS server 11a that is a terminal of the RADIUS Accounting protocol with the GGSN6. The RADIUS server 11a is also equipped with functions such as session management and session log generation for each user. The session management information for each user is indispensable information for specifying the client for each access, and the replication function for the WAP-GW and JSP 10 and the function for responding to inquiries from other nodes are implemented for session management.

  Returning to FIG. 1, reference numeral 12 denotes a directory server (DIR) that centrally manages all subscriber information. This subscriber information is shared between all generations and all regions, and the DIR 12 is an information source of a DRS (Directory Replica Server) 13. Reference numeral 13 denotes a directory replica server (DRS) that copies subscriber information locally from the DIR 12 at regular intervals (for example, every minute) and maintains the subscriber information in response to a query request. Provide information. As a result, even when the DIR 12 is in trouble, services (except for order entry) can be continuously provided.

A web gateway (WGW) 14 is connected to the WAP-GW and the JSP 10 and connects the core network of the mobile communication system and the Internet 20. As shown in the figure, an origin server (a server in which a specified resource exists or is generated) 21 is connected to the Internet 20. Reference numeral 22 denotes a server (Portal) having a function for generating menus and menus displayed on the mobile terminal 1.
In FIG. 1, only one WAP-GW and JSP 10 are shown, but a plurality of these WAP-GWs and JSPs 10 are provided and a load balancer is provided so that the processing can be distributed. You may make it distribute. Further, the WAP-GW and the JSP 10 perform control so that the request from the user agent in the mobile terminal 1 is valid only while the RADIUS information of the corresponding user is replicated from the RADIUS server 11a and held.

Next, FIG. 2 shows a basic sequence of the WAP protocol executed in the mobile communication system according to the present invention shown in FIG. This basic sequence is a sequence when the mobile terminal 1 acquires content from the origin server 21 connected to the Internet 20.
As shown in FIG. 2, when a user agent operating on the mobile terminal 1 acquires content, a communication connection request is sent from the user agent, and in response to this communication connection request, the GGSN 6 sends Radius Accounting Req (Accounting -start) is sent out. Upon receiving this request, the RADIUS server 11a stores the session information for each user attached to the header of the request in a memory (Add / Modify Record). Next, the RADIUS server 11a sends Radius Accounting Replication to the WAP-GW and the JSP 10 in order to replicate the RADIUS information similar to the session information, and the WAP-GW and the JSP 10 that has received this send the replicated RADIUS information in the server. store. Then, the WAP-GW and JSP 10 return Radius Accounting Replication Res notifying that the RADIUS information has been replicated to the RADIUS server 11a. The RADIUS server 11a that has received this sends out Radius Accounting Res notifying that it is ready to connect to the GGSN 6. Thereby, TCP Handshake for establishing a TCP (Transmission Control Protocol) session is performed between the user agent and the WAP-GW and JSP 10, and a TCP session is established (Session Connected). The RADIUS information and the session information for each user are attribute information including subscriber information attached to Radius Accounting Req (Accounting-start).

  When the TCP session is established, the user agent transmits HTTP Req, which is a content request request for acquiring content from the origin server 21. The WAP-GW and JSP 10 that have received this HTTP Req refer to the stored RADIUS information and accept the HTTP Req only when the RADIUS information exists and the subscriber information matches. The WAP-GW and JSP 10 acquire from the R2M 11 mobile terminal information representing the performance of the mobile terminal 1 that requested the content, and complement the mobile terminal information that is missing in the received HTTP Req extension header. Next, TCP Handshake for establishing a TCP session is performed between the WAP-GW and the JSP 10 and the origin server 21 that acquires the content, and the TCP session is established (Session Connected). When the TCP session is established, WAP-GW and JSP 10 send HTTP Req to origin server 21, and origin server 21 sends HTTP Res that returns the requested content.

  At this time, the origin server 21 can know the performance of the mobile terminal 1 by referring to the extension header attached to HTTP Res, and according to the performance so that the performance of the mobile terminal 1 can be fully exhibited. Content can be returned. When the origin server 21 sends all the requested content, it sends a TCP Fin for closing the TCP session to the WAP-GW and JSP 10, and the WAP-GW and JSP 10 receiving this send HTTP Res and TCP Fin. Ack for notifying that it has been received and TCP Fin for closing the TCP session are sent to the origin server 21. The origin server 21 returns a TCP Ack notifying that this has been received and closes the TCP session, and the WAP-GW and JSP 10 receive the TCP Ack and close the TCP session, thereby causing the origin server 21 and the origin server 21 to receive the TCP Ack. The TCP session between the servers 21 ends (Session Disconnected).

  The WAP-GW and the JSP 10 that have acquired the requested content from the mobile terminal 1 refer to the mobile terminal information that represents the performance of the mobile terminal 1 that requested the content. Content conversion processing is performed so that it can be fully utilized. Next, the WAP-GW and the JSP 10 send HTTP Res that returns the converted content to the user agent. The user agent that has received HTTP Res displays the acquired content and sends Ack for notifying that the content has been received and TCP Fin for closing the TCP session to WAP-GW and JSP 10. Upon receiving this, the WAP-GW and JSP 10 return TCP Ack notifying that TCP Fin has been received, and the TCP session between the user agent and the WAP-GW and JSP 10 is terminated (Session Disconnected). Next, Radius Accounting Req (Accounting-stop) is transmitted from the GGSN 6 in response to a communication termination request for terminating communication from the user agent. The RADIUS server 11 a that has received this request discards the corresponding RADIUS information and sends Radius Accounting Res to the GGSN 6. Thereby, the communication between the user agent and the WAP-GW and JSP 10 is completed.

Next, FIG. 3 shows a detailed configuration of WAP-GW and JSP 10 and R2M 11 which are characteristic configurations in the mobile communication system of the present invention, together with an outline of the mobile communication system.
In FIG. 3, the R2M 11 includes a RADIUS server 11a, but is not explicitly shown. The R2M 11 includes a RAD Master 30 that is a database that holds RADIUS information, which is session information for each user managed by the RADIUS server 11a, and a user ID (UID: User ID) that is uniquely assigned to a subscriber. This is a database that holds Selfcare Profile information that includes unique information related to user settings, such as whether or not the user has agreed to the notification, and whether or not the user has URLs (Uniform Resource Locators) to be regulated. A Selfcare DB 31 and a CC / PP Repository 32 which is a database that holds parameters representing the model name, performance, and capability of the mobile terminal 1 for each model are provided. Further, the R2M11 has session information (Acct-Profile), user agent profile information (UA-Profile), mobile terminal information (UE-Profile), self-care information (Selfcare-Profile), user information (User -Profile) is created, and a profile section (Profile) 33 cached in the memory is provided while the session continues. Moreover, WAP-GW and JSP10 are comprised from WAP-GW10a and JSP10b. The menu generated by the portal server 22 can be displayed on the mobile terminal 1, and the Selfcare Profile information set / edited from the menu can be stored / updated in the Selfcare DB 31. The Profile Repository 40 is a database constructed by a mobile terminal manufacturer in which mobile terminal information (UE-Profile) including model information and performance information is stored.

  In the configuration shown in FIG. 3, as described above, when the mobile terminal 1 acquires content from the origin server 21, the Accounting Req (Accounting-start) is sent from the GGSN 6 in response to a communication connection request from the user agent of the mobile terminal 1. Is sent out. The R2M 11 that has received this request stores the attribute information of the request in the RAD Master 30 as RADIUS information. Then, the IP address issued by the GGSN 6 to the mobile terminal 1, the MSISDN (Mobile Station ISDN number) of the mobile terminal 1, the IMSI (International Mobile Subscriber Identity) which is the international identification number given to the mobile phone subscriber, etc. The RADIUS information consisting of is replicated to the WAP-GW 10 a and supplied to the Profile unit 33. In response to this, the Profile unit 33 starts creating profile information related to the mobile terminal 1 that has transmitted Accounting Req (Accounting-start). That is, the Profile unit 33 accesses the Selfcare DB 31 and acquires self-care information (Selfcare-Profile) including unique information set by the user using the mobile terminal 1. In addition, the Profile unit 33 accesses the CC / PP Repository 32 and acquires mobile terminal information (UE-Profile) including parameters indicating the model name, performance, and capability of the mobile terminal 1. In this case, when the corresponding entry does not exist in the CC / PP Repository 32, the mobile terminal information (UE-Profile) is stored in the CC / PP Repository 32 by making an inquiry to the Profile Repository 40. If the inquiry to the Profile Repository 40 cannot be made, the Default value set by the R2M11 is returned to the Profile unit 33. Further, the Profile unit 33 accesses the DRS 13 and acquires user information (User-Profile) of the user who is using the mobile terminal 1. This user information is composed of IMSI, MSISDN, and a user ID unique to the mobile carrier assigned to the subscriber. Then, the collected self-care information (Selfcare-Profile), mobile terminal information (UE-Profile), user information (User-Profile) and RADIUS information related to the mobile terminal 1 are collected into one profile for the corresponding mobile terminal 1. Create information and cache it in memory.

  When a TCP session is established between the user agent on the mobile terminal 1 and the WAP-GW 10a, HTTP Req is sent from the user agent as described above. When this HTTP Req is received by the WAP-GW 10a, the WAP-GW 10a passes the Request URI (URI: Uniform Resource Identifier), MSISDN, and IMSI indicating the requested resource in the HTTP Req to the JSP 10b. The JSP 10b acquires profile information corresponding to the passed MSISDN or IMSI by accessing the Profile unit 33. And when the mobile terminal information (UE-Profile) required in the extension header of HTTP Req is insufficient, JSP10b is insufficient based on the mobile terminal information (UE-Profile) of the acquired profile information. Complete parameters in HTTP Req extension header. In this case, since it is difficult for the user agent of the WAP / MMS-compatible mobile terminal to send HTTP Req with the extension header of the parameter of the mobile terminal information (UE-Profile) attached, the WAP / MMS-compatible mobile terminal The HTTP Req sent from the user agent is supplemented with an extension header to which the parameter of the mobile terminal information (UE-Profile) is attached. As a result, regardless of the type of mobile terminal that sent HTTP Req, the mobile communication system can send HTTP Req with the same extension header as before to the Internet. . Therefore, the origin server 21 requested for the content can return the requested content in the same manner as before.

  The HTTP Req in which the extension header is complemented as necessary in this way is sent from the JSP 10b, and the origin server 21 specified by the Request URI refers to the extension header and transmits the mobile terminal information (UE-Profile). Select or create content that matches the parameters, and send HTTP Res that returns the content to JSP 10b. However, there are servers that return content without referring to the extension header depending on the origin server 21, and the content acquired by the JSP 10b is not necessarily adapted to the performance and capability of the mobile terminal 1 that requested the content. Absent. Therefore, the JSP 10b that has received the HTTP Res refers to the mobile terminal information (UE-Profile) of the profile information related to the mobile terminal 1 that requested the content, and performs Trans-coding so as to match the performance and capability of the mobile terminal 1. Yes. Trans-coding is performed in order to correctly display the content on the mobile terminal 1, and Trans-coding performs processing for converting the content to a format suitable for the mobile terminal 1, editing or restricting it, and displaying the content correctly.

  In trans-coding performed in the JSP 10b, markup language (ML) conversion, character set conversion, and object conversion are performed. In ML conversion, the Content Type supported by the mobile terminal 1 is specified, and markup language conversion is performed according to the Content Type supported by the specified mobile terminal 1. Markup language types include SGML, HTML, and XTML. In the character set conversion, the character code and the pictogram are converted according to the ability of the mobile terminal 1 for the text of the content regardless of the type of the markup language. Character code conversion is performed when the mobile terminal 1 does not support the character code of the acquired content. For example, Shift-JIS, EUC-JP, ISO-2022-JP, UTF-8, ISO-10646-UCS The character code of -2 is converted to the character code of Shift-JIS or UTF-8 UE. In pictogram conversion, a conversion source Pictogram format and a post-conversion Pictogram format are defined, and the Pictogram format is converted according to the rules. The character code and pictogram conversion functions may operate independently and turn on / off each function. In the object conversion, a file format supported by the mobile terminal 1 is specified, and the file format of the object (content) is converted according to the specified file format supported by the mobile terminal 1. File formats include JPEG, GIF, PNG, and the like. In the object conversion, pixel number conversion and color depth conversion are performed according to the screen size of the mobile terminal 1 and the performance of the display unit. In addition, what is necessary is just to refer the mobile terminal information (UE-Profile) of the profile information which JSP10b acquired for the performance and capability of the mobile terminal 1.

  In this way, the content that has been subjected to the trans-coding process to be displayed correctly after being converted, edited, or restricted to a format suitable for the mobile terminal 1 is passed from the JSP 10b to the WAP-GW 10a, and from the WAP-GW 10a to the mobile terminal 1 HTTP Res that sends the content after Trans-coding processing is sent to. In the mobile terminal 1, content is acquired by receiving HTTP Res, and the acquired content is displayed. In this case, since the content is trans-coded, the content can be displayed by fully utilizing the performance and capability of the mobile terminal 1. As a result, similarly to a mobile terminal compatible with mobile telecommunications carriers and a mobile terminal compatible with WAP / MMS, it is possible to display contents by making full use of the performance and capability of mobile terminal 1.

Next, FIG. 4 shows a sequence showing an operation image for complementing the HTTP extension header described above.
As shown in FIG. 4, when a user agent (UA) operating on the mobile terminal 1 acquires content, the user agent sends Activate PDP Req, which is a communication connection request. This Activate PDP Req is received by the SGSN 5. Then, Create PDP Req with IMSI and MSISDN information attached is generated and sent to GGSN 6. The GGSN 6 that has received Create PDP Req issues an IP address to the user agent that has sent Activate PDP Req, generates Accounting Req to which this IP address and MSISDN or IMSI are attached, and sends it to the RADIUS server 11a. Accounting Req is the same request as Radius Accounting Req (Accounting-start) shown in FIG.

  The RADIUS server 11a that has received Accounting Req stores the information attached to the request in the RAD Master 30 as RADIUS information, and also generates RADIUS Replication and replicates it to the WAP-GW 10a. Further, the RADIUS server 11 a generates Save Profile Req for storing profile information related to the mobile terminal 1 and sends it to the Profile unit 33. The Profile unit 33 that has received the Save Profile Req makes an inquiry request to the DRS 13 with the acquisition User-Profile for acquiring user information (User-Profile), and acquires the user information (User-Profile) from the DRS 13. The parameter of the inquiry request at this time is MSISDN or IMSI. Further, the Profile unit 33 makes a request for inquiry to the Selfcare DB 31 based on the MSISDN or IMSI attached to the Save Profile Req to acquire self-care information (Selfcare-Profile), and makes a request for inquiry to the CC / PP Repository 32 to make the mobile terminal. Get information (UE-Profile). In this case, when there is no entry for which inquiry is requested, inquiry is made to the Profile Repository 40 and the mobile terminal information (UE-Profile) is stored in the CC / PP Repository 32. If the inquiry to the Profile Repository 40 cannot be made, the Default value set by the R2M11 is returned to the Profile unit 33. The Profile unit 33 caches the acquired information and the above-described user agent information in the memory as profile information.

  Then, HTTP Req which is a content request for acquiring content from the user agent in the mobile terminal 1 is sent out. The HTTP Req header includes the IP address of the user agent issued from the GGSN 6, the URI (Request-URI) of the origin server 21 that is the destination of the content, User-Agent (user agent information), or UA -Prof information is attached at least. The WAP-GW 10a that has received this HTTP Req passes the HTTP Req with the MSISDN and IMSI attached to the header to the JSP 10b. If UA-Prof information is attached to the header of the received HTTP Req, the WAP-GW 10a passes the UA-Prof information to the Profile unit 33, and complements the profile information related to the mobile terminal 1 that sent the HTTP Req. Then, acquisition and transmission (acquisition & Complement Profile) of profile information related to the mobile terminal 1 that transmitted HTTP Req is performed between the Profile unit 33 and the JSP 10b, and the profile information cached in the Profile unit 33 is stored in the JSP 10b. Passed to. When the mobile terminal information (UE-Profile) required in the extension header of HTTP Req is insufficient, the JSP 10b is a parameter that is insufficient based on the mobile terminal information (UE-Profile) of the acquired profile information. To the HTTP Req extension header. The JSP 10b sends an HTTP Req to which at least the extension header and Request-URI are attached to the origin server 21, and acquires the content requested from the origin server 21.

Here, a flowchart of the extension header complementing process performed in the JSP 10b is shown in FIG.
The extension header complementing process is started when HTTP Req with MSISDN and IMSI attached to the header is passed from WAP-GW 10a to JSP 10b. The profile information is acquired from the Profile section 33. Next, in step S11, it is determined whether or not a user ID (UID) is attached to the HTTP Req extension header passed from the WAP-GW 10a. In this case, if the mobile terminal 1 is a WAP / MMS compatible mobile terminal, no extension header is attached and NO is determined, and the process branches to step S14. If the mobile terminal is compatible with a mobile carrier, an extension header is attached, so that the determination is YES and the process proceeds to step S12. In step S12, it is determined whether or not the UID attached to HTTP Req is different from the UID of the user information (User-Profile) in the profile information acquired from the Profile section 33. Here, if the user IDs of the two are different, the user agent that sent the HTTP Req is different from the user agent of the profile information acquired from the Profile section 33. Is returned, and the extension header completion processing ends.

  When the attached user ID matches the UID in the profile information acquired from the Profile section 33, the user agent that sent HTTP Req and the user agent of the profile information acquired from the Profile section 33 are one. Then, the process branches to step S14 in order to proceed with the extension header complement processing. In step S14, it is determined whether another extension header is attached to HTTP Req. If it is determined that another extension header is attached to HTTP Req, the process proceeds to step S15. If it is determined that another extension header is not attached to HTTP Req, the process branches to step S18. In step S18, it is determined whether or not the user agrees to send the UID with reference to self-care information (Selfcare-Profile) in the profile information acquired from the Profile section 33. If the user agrees to send the UID, the process proceeds to step S19, where the UID is attached to the HTTP Req extension header and sent. If the user does not agree to send the UID, the process branches to step S20 to delete the UID from the HTTP Req extension header.

  When the process of step S19 or step S20 ends, the process proceeds to step S15, and the mobile terminal information (UE-Profile) that is missing in the HTTP Req extension header is attached. FIG. 6 shows a list of examples of header parameters to be attached to the HTTP Req extension header in this case. The list shown in FIG. 6 shows a target header parameter (Parameter), a parameter description (Explanation), a profile class (Profile class), and an acquisition location (origin of acquisition). X-jphone-msname indicating the model name shown in FIG. 6, x-jphone-display indicating the screen size (width * height), x-jphone-color indicating the color depth, x-jphone-sound indicating the number of pronunciations, X-jphone-smaf indicating SMAFFile compatible type, x-jphone-uid indicating user ID, x-jphone-msisdn indicating MSISDN, x-jphone-region indicating standby region, x-jphone-Imsi indicating IMSI It is a header parameter to be attached when parameters are missing. However, the parameter of x-jphone-msisdn indicating MSISDN is attached only for permitted nodes.

  Therefore, when the processing in step S15 is completed, it is determined in step S16 whether or not the origin server 21 that is the transfer destination of HTTP Req is permitted to attach the MSISDN parameter indicating IMSI or MSISDN. The nodes that are allowed to attach the msisdn parameter are determined by the mobile carrier and stored in the external setting file. If the origin server 21 of the transfer destination is a node that is permitted to attach the msisdn parameter with reference to the external setting file, the process proceeds to step S17 and the user information (User-) of the profile information acquired from the UDB. IMSI or MSISDN in (Profile) is attached to the extension header, and the extension header complementing process is terminated. If the origin server 21 of the transfer destination is a node that is not permitted to attach the msisdn parameter, the extension header complementing process is terminated as it is.

  By the way, if SSL (Secure Socket Layer) communication, which is an encryption protocol having an encryption communication function and an authentication function, is performed between the user agent of the mobile terminal 1 and the origin server 21, the tunneling is performed, so that the WAP− In the GW and the JSP 10, it is impossible to access the bidirectional data to be transferred, and the user information and the mobile terminal information cannot be supplemented to the HTTP Req. That is, since the WAP-GW and the JSP 10 send HTTP Req END to END, there is a possibility that a problem that information necessary for request processing in the origin server 21 is insufficient occurs. Therefore, for the purpose of performing application processing such as HTTP extension header complementation, SSL communication from the user agent is once terminated in WAP-GW and JSP10, and application processing such as HTTP extension header complementation processing is performed in WAP-GW and JSP10. After that, SSL communication may be started again with respect to the origin server 21. Furthermore, SSL communication from the origin server 21 is once terminated in the WAP-GW and JSP 10, and after application processing such as trans-coding processing is performed in the WAP-GW and JSP 10, SSL communication is started again for the user agent. You may make it do.

  As described above, in a mobile terminal compatible with a mobile communication carrier, an extension header of a parameter indicating the performance and capability of the mobile terminal is attached to the content request request. When the extension header is attached to the content request as described above, the origin server that provides the content in response to this request refers to the parameter attached as the extension header to sufficiently improve the performance and capability of the mobile terminal. It can provide content that can be used in two minutes. In addition, when the origin server does not provide a service that provides content that can fully utilize the performance and capability of the mobile terminal, the mobile terminal information (UE-Profile) of the profile information acquired from the R2M11 on the mobile communication system side The content can be converted based on the above so that the performance and capability of the mobile terminal can be fully utilized.

  In the mobile communication system according to the present invention, when a mobile terminal acquires content, the user agent information, user information (User-Profile), self-care information (Selfcare-Profile), and mobile terminal information (UE -Profile) is generated in R2M11. This profile information is supplied from the R2M11 to the JSP 10b. For this reason, an extension header of a parameter indicating the performance and capability of the mobile terminal can be attached to the content request request sent by the WAP / MMS compatible mobile terminal based on the profile information in the JSP 10b. Further, by referring to the mobile terminal information (UE-Profile) of the profile information acquired from the R2M11 in the JSP 10b, it is possible to convert the acquired content so that the performance and capability of the mobile terminal can be fully utilized. As a result, even mobile terminals that support WAP / MMS can receive original services based on the original protocols provided by mobile carriers, making full use of the performance and capabilities of mobile terminals. Content can be acquired. Furthermore, since the profile information is centrally managed in the R2M11, it is possible to reduce the load on the server that requires any information constituting the profile information when no extension header is attached.

  In the above description, the mobile terminal in the mobile communication system acquires content from the Internet. However, the present invention is not limited to this, and the present invention is also applicable when a communication terminal in a certain network acquires content from another network. be able to.

It is a block diagram which shows the whole structure of the Example of the mobile communication system of this invention. It is a figure which shows the basic sequence of the WAP protocol performed in the mobile communication system concerning this invention. It is a figure which shows the detailed structure of WAP-GW, JSP, and R2M which are characteristic structures in the mobile communication system of this invention with the outline | summary of a mobile communication system. It is a sequence diagram which shows the operation | movement image which complements the extension header of HTTP in the mobile communication system concerning this invention. It is a flowchart of the complementation process of the extension header performed in JSP in the mobile communication system concerning this invention. It is a figure which shows the list of an example of the header parameter made into the object attached to the extension header of HTTP Req in the mobile communication system concerning this invention.

Explanation of symbols

1 Mobile terminal (UE)
2 Radio base station (BTS)
3 Radio base station controller (RNC)
4 Mobile Communication Switching Center (MSC)
5 Gateway (SGSN)
6 Gateway (GGSN)
10 nodes and application gateways (WAP-GW and JSP)
10a WAP-GW
10b JSP
11 Information management server (R2M)
11a RADIUS server 12 Directory server (DIR)
13 Directory Replica Server (DRS)
14 Web Gateway (WGW)
20 Internet 21 Origin Server 22 Server (Portal)
30 RAD Master
31 Selfcare DB
32 CC / PP Repository
33 Profile section
40 Profile Repository

Claims (7)

In response to a content request from the mobile terminal, an adjustment server that obtains the requested content from the origin server and provides it to the mobile terminal;
An information management server that centrally manages user-related information and mobile terminal information;
The coordination server acquires at least mobile terminal information indicating the performance of the mobile terminal from the information management server when receiving a content request request from the mobile terminal, and the content request request is insufficient due to the acquired mobile terminal information. A mobile communication system, wherein information indicating the performance of the mobile terminal is supplemented and transmitted to the origin server.   The adjustment server, when receiving a content request from the mobile terminal, in addition to the mobile terminal information, the information related to the user related information including user-specific information that can be set by the user and user information that can identify the user. The mobile communication system according to claim 1, wherein the user information is supplemented to the content request and sent to the origin server in accordance with the acquired user specific information.   The information management server, when receiving a connection start request from the mobile terminal prior to the content request, the user-related information including user-specific information set by a user and user information that can identify the user, and 2. The mobile communication system according to claim 1, wherein profile information relating to the mobile terminal including the mobile terminal information is generated, and the profile information is passed upon request from the coordination server.   When the mobile terminal acquires content from the origin server by a protocol using tunneling, the coordination server temporarily terminates tunneling, and shows information indicating the performance of the mobile terminal that is insufficient in the content request request. The mobile communication system according to claim 1, wherein the content request is transmitted to the origin server by a protocol using complementing and tunneling. In response to a content request from a mobile terminal, the requested content is obtained from an origin server and provided to the mobile terminal,
Upon receiving a content request from the mobile terminal, the mobile terminal information indicating at least the performance of the mobile terminal is acquired from an information management server that centrally manages user-related information and mobile terminal information, and the content is obtained from the acquired mobile terminal information. A server device characterized in that information indicating the performance of the mobile terminal that is lacking in a request request is complemented and transmitted to the origin server.   Upon receiving a content request from the mobile terminal, the user related information including user-specific information that can be set by the user in addition to the mobile terminal information and user information that can identify the user is acquired from the information management server, 6. The server device according to claim 5, wherein the user information is complemented to the content request and sent to the origin server according to the acquired user specific information. When the mobile terminal acquires content from the origin server by a protocol using tunneling, the tunneling is temporarily terminated, and the information indicating the performance of the mobile terminal that is lacking in the content request request is supplemented. The server apparatus according to claim 5, wherein the content request is transmitted to the origin server by a protocol using.

Images