1. A radio apparatus for performing a HARQ-based automatic retransmission, comprising:
a redundancy version control unit for identifying a redundancy version in the preceding retransmission when a retransmission is needed based on a determination criteria which differs depending on whether the redundancy version in the preceding transmission handled systematic bits as priority or as nonpriority; and
a HARQ processing unit for performing rate matching for each of the systematic bits and parity bits of data to be retransmitted in accordance with the redundancy version identified by said redundancy version control unit.
2. The apparatus according to claim 1, wherein:
when the redundancy version in the preceding transmission handled the systematic bits as priority:
said redundancy version control unit will now specify the systematic bits as nonpriority in the redundancy version in the retransmission if the number of bits of the systematic bits applied to said HARQ processing unit is larger than the number of bits delivered from said HARQ processing unit, and if there are limits to the number of available codes; and
said redundancy version control unit will maintain the systematic bits as unchanged from priority in the redundancy version in the retransmission if the number of the systematic bits applied to said HARQ processing unit is equal to or smaller than the number of bits delivered from said HARQ processing unit andor if there are no limits to the number of available codes.
3. The apparatus according to claim 1, wherein said redundancy version control unit counts the number of times of retransmission, wherein:
when the redundancy version in the preceding transmission handled the systematic bits as nonpriority:
said redundancy version control unit will now specify the systematic bits as priority in the redundancy version in the retransmission if the number of times of retransmission is equal to or larger than a predetermined threshold; and
said redundancy version control unit will maintain the systematic bits unchanged from nonpriority in the redundancy version in the retransmission if the number of times of retransmission is smaller than the threshold.
4. A method of automatically retransmitting in accordance with HARQ processing, comprising:
a first step of identifying a redundancy version in the preceding retransmission when a retransmission is needed, based on determination criteria which differ depending on whether the redundancy version in the preceding transmission handled systematic bits as priority or as nonpriority; and
a second step of performing rate matching for each of the systematic bits and parity bits of data to be retransmitted in accordance with the redundancy version identified at said first step.
5. The method according to claim 4, wherein:
when the redundancy version in the preceding transmission handled the systematic bits as priority:
the systematic bits will now be specified as nonpriority in the redundancy version in the retransmission if the number of bits of the systematic bits applied to said HARQ processing unit is larger than the number of bits delivered from said HARQ processing unit, and if there are limits to the number of available codes; and
the systematic bits will be maintained unchanged from priority in the redundancy version in the retransmission if the number of the systematic bits applied to said HARQ processing unit is equal to or smaller than the number of bits delivered from said HARQ processing unit or if there are no limits to the number of available codes.
6. The method according to claim 4, wherein:
when the redundancy version in the preceding transmission handled the systematic bits as nonpriority:
the systematic bits will now be specified as priority in the redundancy version in the retransmission if the number of times of retransmission is equal to or larger than a predetermined threshold; and
the systematic bits will be maintained unchanged from nonpriority in the redundancy version in the retransmission if the number of times of retransmission is smaller than the threshold.
The claims below are in addition to those above.
All refrences to claim(s) which appear below refer to the numbering after this setence.
1. A method of accessing an application server, the method comprising:
at an application-independent generic hub, receiving a request from an external system to access application data stored in the application server, the request conforming to a first transfer protocol;
responsive to said receiving, verifying authorization of the external system to access the application server;
deriving, for input data in a data field of a user interface, an expected data type and a corresponding field length for the data field from metadata provided by a backend server’s data dictionary;
if the external system is authorized, validating the input data by:
determining data type and field length of the input data,
comparing the determined data type and field length to the expected data type and corresponding field length, and
discarding extraneous data from the input data when the field length of the input data exceeds the corresponding field length, wherein the extraneous data comprises data characters that are in excess of the corresponding field length; and
responsive to said validating, tunneling the request of the first transfer protocol in a second transfer protocol to the application server, wherein the request includes the input data.
2. The method of claim 1, wherein the expected data type and corresponding field length are field-dependent.
3. The method of claim 1, wherein the first transfer protocol and the second transfer protocol are different transfer protocols.
4. The method of claim 3, wherein the first transfer protocol is selected from the group consisting of HTTP, HTTPS, SOAP, and Remote Function Call (RFC).
5. The method of claim 3, wherein the second transfer protocol is selected from the group consisting of Remote Procedure Call (RPC), Remote Function Call (RFC), and SOAP.
6. The method of claim 1, wherein said tunneling comprises extracting request data from the external system request and transferring the request data using the second transfer protocol.
7. The method of claim 1, wherein said tunneling comprises encapsulating the external system request conforming to the first transfer protocol in the second transfer protocol, the external system request including the input data.
8. A non-transitory computer-readable storage medium containing a set of instructions, the set of instructions capable of causing a computer to implement a method comprising:
at an application-independent generic hub, receiving a request from an external system to access application data stored in the application server, the request conforming to a first transfer protocol;
responsive to said receiving, verifying authorization of the external system to access the application server;
deriving, for input data in a data field of a user interface, an expected data type and a corresponding field length for the data field from metadata provided by a backend server’s data dictionary;
if the external system is authorized, validating the input data by:
determining data type and field length of the input data,
comparing the determined data type and field length to the expected data type and corresponding field length, and
discarding extraneous data from the input data when the field length of the input data exceeds the corresponding field length, wherein the extraneous data comprises data characters that are in excess of the corresponding field length; and
responsive to said validating, tunneling the request of the first transfer protocol in a second transfer protocol to the application server, wherein the request includes the input data.
9. The computer-readable storage medium of claim 8, wherein the expected data type and corresponding field length are field-dependent.
10. The computer-readable storage medium of claim 8, wherein the first transfer protocol and the second transfer protocol are different transfer protocols.
11. The computer-readable storage medium of claim 10, wherein the first transfer protocol is selected from the group consisting of HTTP, HTTPS, SOAP, and Remote Function Call (RFC).
12. The computer-readable storage medium of claim 10, wherein the second transfer protocol is selected from the group consisting of Remote Procedure Call (RPC), Remote Function Call (RFC), and SOAP.
13. The computer-readable storage medium of claim 8, wherein said tunneling comprises extracting request data from the external system request and transferring the request data using the second transfer protocol.
14. The computer-readable storage medium of claim 8, wherein said tunneling comprises encapsulating the external system request conforming to the first transfer protocol in the second transfer protocol, the external system request including the input data.
15. A distributed architecture system, comprising:
a generic hub, configured to connect to an application server, comprising a processing unit and a memory unit, coupled to the processing unit, storing instructions adapted to be executed by the processing unit to
at an application-independent generic hub, receive a request from an external system to access application data stored in the application server, the request conforming to a first transfer protocol;
responsive to said receiving, verify authorization of the external system to access the application server;
derive, for input data in a data field of a user interface, an expected data type and a corresponding field length for the data field from metadata provided by a backend server’s data dictionary;
if the external system is authorized, validate the input data by:
determining data type and field length of the input data;
comparing the determined data type and field length to the expected data type and corresponding field length; and
discarding extraneous data from the input data when the field length of the input data the corresponding field length, wherein the extraneous data comprises data characters that are in excess of the corresponding field length; and
responsive to said validating, tunnel the request of the first transfer protocol in a second transfer protocol to the application server, wherein the request includes the input data.
16. The distributed architecture system of claim 15, wherein the expected data type and corresponding field length are field-dependent.
17. The distributed architecture system of claim 15, wherein the first transfer protocol and the second transfer protocol are different transfer protocols.
18. The distributed architecture system of claim 17, wherein the first transfer protocol is selected from the group consisting of HTTP, HTTPS, SOAP, and Remote Function Call (RFC).
19. The distributed architecture system of claim 17, wherein the second transfer protocol is selected from the group consisting of Remote Procedure Call (RPC), Remote Function Call (RFC), and SOAP.
20. The distributed architecture system of claim 15, wherein said tunneling comprises extracting request data from the external system request and transferring the request data using the second transfer protocol.
21. The distributed architecture system of claim 15, wherein said tunneling comprises encapsulating the external system request conforming to the first transfer protocol in the second transfer protocol, the external system request including the input data.