최종산출물 · 도서자료 기계독해

5G 이동통신 분야 표준문서 검색 가이드

uuid
c48f4f11-00c3-528b-9925-53ea3fb4201f
content_id
PCY_201504070911229001
doc_id
PCY_201504070911229001_7
발행기관
특허청
발행연도
KDC
560
답변 불가 (is_impossible)
True
문맥 (context)
NTT 도코모에서 2010년 2월 19일에 출원한 LTE 표준특허(출원번호: 10-2010-705882, 우선일: 2007.8.14.)에 대하여 3GPP 웹사이트의 Advanced search 검색 방법을 이용하여 표준문서를 검색하는 과정을 살펴보기로 한다. 본 특허는 LTE의 업링크제어채널(PUCCH)을 구성하는 방법에 관한 것으로 제어정보의 종류 별로 무선 리소스를 별도로 할당함으로써 제어정보를 다중화하는 것을 주요 특징으로 하고 있다. LTE의 업링크의 통신방식은 PAPR 특성이 좋은 SC-FDMA를 사용하고 있으며, 다수의 자원블록이 제어정보를 전송하기 위한 PUCCH, 데이터(데이터와 제어정보)를 전송하기 위한 PUSCH로 할당되어 있다. 그런데, LTE의 업링크에서는 single carrier property를 유지하기 위해서, 하나의 단말에 대하여 PUSCH로 이용하는 자원블록이 항상 연속적으로 할당되어야 한다. 따라서, PUSCH 블록을 연속적으로 할당할 수 있도록 하기 위하여 자원 블록의 양 끝에 있는 자원블록에는 PUCCH를 할당하고 가운에 자원블록에는 PUSCH를 할당한다. 싱글캐리어 방식으로 상향링크 제어채널을 기지국으로 송신하는 유저장치에 있어서, 상기 기지국으로부터 스케줄링에 의해 송신된 데이터에 대한 수신판정을 수행하고, 이 수신판정 결과를 제1 제어정보로서 생성하는 수신판정부; 및 상기 제1 제어정보를 시스템대역의 끝에 위치하는 제1 무선리소스에 할당하고, 유저 개별로 할당된 무선리소스로 송신되는 제2 제어정보를 상기 제1 무선리소스에 인접하는 제2 무선리소스의 지정위치에 할당함으로써, 상기 제1 및 제2 제어정보를 상기 상향링크 제어채널에 다중하는 제어정보 다중부;를 갖는 유저장치 “싱글캐리어 방식으로 상향링크 제어채널을 기지국으로 송신하는 유저장치ˮ에서, 싱글캐리어 방식은 SC-FDMA를 의미하고, 상향링크 제어채널은 LTE의 PUCCH을 의미한다. “기지국으로부터 스케줄링에 의해 송신된 데이터에 대한 수신판정을 수행하고, 이 수신 판정 결과를 제1 제어정보로서 생성하는ˮ은 기지국에서 전송한 데이터가 오류 없이 수신되었는지의 여부를 표시하는 제어정보를 생성하는 것을 의미하며, ACK/NACK 정보를 생성하는 것을 의미한다. 독립항 제1항을 살펴보면, “이동국과 통신을 수행하는 기지국장치에 있어서, 상기 이동국은, 싱글 캐리어-주파수 분할 다원 접속 방식, 또는, 직교 주파수 분할 다원 접속 방식에 의해, 상향링크의 신호를 송신하고, 상기 기지국장치는, 상기 이동국에 대해서, 상기 상향링크의 신호의 송신타이밍을 조절하기 위한 조절량을 통지하는 경우에, 상기 기지국장치는, 상기 이동국이 송신하는 채널의 종류에 기초하여, 상기 송신타이밍을 조절하기 위한 조절량의 범위로서, 다른 값을 정의하는 조절량 범위 정의수단;을 구비하는 것을 특징으로 하는 기지국장치ˮ라고 기재되어 있다. 청구항 제1항의 주요 특징은 채널의 종류에 따라 타이밍의 조절량을 달리 한다는 것인데, 단말이 초기에 업링크 시간 동기를 획득하기 위해서는 랜덤 액세스 채널을 이용하고, timing advance update를 하는 과정에서는 다른 채널을 이용하므로 채널 별로 타이밍의 조절량을 달리 한다는 것은 결국 initial timing advance 시에는 타이밍의 조절량을 크게 하고, timing advance update 시에는 타이밍의 조절량을 작게 한다는 것을 의미한다. 각 회의에서 발표된 LTE의 기고문은 회의 디렉토리에 순서대로 저장되어 있을 뿐, 기고문들이 별도의 기준에 따라 분류가 되어 있지는 않다. 기고문을 선행기술로 활용하기 위해서는 LTE의 세부 기술이 논의된 시점에 대한 정보가 중요하다. 하지만, 3GPP에서는 최종적으로 규격을 완성하는 것이 주 관심사이기 때문에 각 시기 별로 특정 기술을 논의한 시점이 체계적으로 정리된 자료를 제공하지는 않는다. 모든 기고문 파일의 내용을 확인하면 각 회의에서 어떤 기술들이 논의되었는지에 대한 정보를 알 수는 있겠지만, 수백 개의 기고문을 일일이 확인하는 것은 현실적으로 불가능하다. ftp 서버에서는 모든 기고문 파일을 조회하지 않더라도 세부 기술의 공개 시점을 파악하는 데 도움이 될 수 있는 파일들이 다수 존재하는데 이에 대해서 살펴보기로 한다. 3GPP ftp 검색사이트는 ftp에 올라오는 모든 문서를 데이터베이스화한 것으로 유럽특허청도 이 ftp에 있는 문서정보 및 ftp에 업로드 된 날짜정보를 활용하여 데이터베이스화한다. 기고문 검색이 용이하고 특히 Working Group 별로 검색이 가능하다. PDF 검색은 3GPP 기고문 다운로드 후 PDF 변환이 필요하며 복수의 기고문을 일괄 검색할 때 용이하다. 특히 표준 규격을 검색할 때 용이하게 쓸 수 있다. 표준특허의 출원시기를 알면 검색을 용이하게 할 수 있다. 표준기고문은 주로 표준 회의 일주일 전 기고문 제출 시기에 가장 많은 특허 출원을 한다. 기고문 검색 시 출원일 기준 2주 정도의 여유를 두고 기간 설정하고 선행기술을 검색 후 ftp 서버 및 이메일 기고문 공개일 등 정확한 공개일 확인하면 비교적 쉽게 표준 기고문을 찾을 수 있다. 표준특허는 주로 기고문 제출기한인 회의 일주일 전에 다량의 표준특허가 출원되고 가끔 표준회의 중에도 논의 과정에서 생긴 아이디어들이 출원되고, 또한 표준 회의 후에도 표준회의 내용을 정리하는 과정에서 새로운 아이디어가 표준 특허로 출원된다. 파일 다운로드 중에 파일의 전송을 잠시 중단하고자 하는 경우에는 “Server/ Local file”창으로 마우스를 다시 이동한 후 오른쪽 마우스 버튼을 클릭하고, 선택된“Process Queue”를 해제하면 된다. 3GPP ftp 서버는 회의가 개최될 때마다 새로운 표준문서가 계속 업데이트되므로, ftp 서버의 변경 사항을 반영하도록 개인 PC의 디렉토리도 계속 업데이트되어야 하는데, ftp 서버에서 새로 생성된 디렉토리만을 선택하여 다운로드하면 된다. 혹은, “WG1_RL1”디렉토리 전체를 선택한 후 중복된 파일은 재다운로드 하지 않고 skip하여도 된다. ftp 서버로부터 표준문서를 다운로드한 후에는 구글 데스크톱을 이용하여 색인화하는 작업이 필요하다. 구글 데스크톱은 PC에 저장된 모든 파일에 대하여 색인화하기 때문에 색인 과정에 장시간이 소요지만, 일단 색인화가 완료되면, 간단한 검색어 입력에 의하여 실시간으로 검색 결과를 볼 수 있다는 장점이 있다. 다운로드할 디렉토리를 선택한 후 오른쪽 마우스를 클릭하여 “Download”를 선택하면 선택한 디렉토리에 포함되어 있는 파일들이 순서대로 PC에 저장이 된다. 그런데, 3gpp ftp 서버는 자주 끊기는 현상이 발생되므로, 중간에 파일 전송이 중단하는 현상이 발생한다. 이를 해결하기 위해서 “Download” 대신에 “Add to queue”메뉴를 이용할 수 있다. “Add to queue” 메뉴를 선택하는 경우, 해당 디렉토리의 모든 파일을 큐에 저장이 된다. 맨 아래에 있는 “Server/Local file” 창으로 마우스를 이동하여 오른쪽 마우스 버튼을 클릭하면, 6 개의 메뉴가 나타나는데, 이 중 “Process Queue”를 선택하면 큐에 있는 파일을 차례대로 “Local site”에서 선택된 디렉토리 아래에 저장이 된다. 화면의 맨 아랫 부분에는 세 개의 창이 있으며, 각각 Queued files, Failed transfers, Successful transfers 항목이 표시되어 있는데, 파일 다운로드 실행시에는 각각의 항목에 대하여 큐에 저장된 파일 개수, 전송에 실패한 파일 개수, 전송에 성공한 파일 개수가 각각 괄호로 표시된다.
지시문 (instruction)
다음 문맥을 읽고 질문에 답하시오.
질문 (question)
3GPP ftp 서버에서 파일 다운로드 실행 시, 전송에 실패한 파일의 총 개수는 몇 개인가?
추론 과정 (compact_reasoning)
  1. 1과제 해석task_interpretation

    질문은 3GPP ftp 서버 다운로드 과정 중 전송에 실패한 파일의 구체적인 수치를 요구한다.

  2. 2정보 추출information_extraction

    문맥은 다운로드 상태를 보여주는 세 가지 항목(Queued files, Failed transfers, Successful transfers)과 각 항목이 개수를 괄호로 표시한다는 사실을 설명한다.

    • Queued files, Failed transfers, Successful transfers 항목이 표시되어 있는데, 파일 다운로드 실행시에는 각각의 항목에 대하여 큐에 저장된 파일 개수, 전송에 실패한 파일 개수, 전송에 성공한 파일 개수가 각각 괄호로 표시된다.
  3. 3근거 선택evidence_selection

    문맥에서 'Failed transfers' 항목이 실패한 파일의 개수를 표시한다는 근거는 찾을 수 있으나, 실제 실패한 파일이 몇 개인지는 명시되어 있지 않다.

    • Failed transfers
    • 전송에 실패한 파일 개수, 전송에 성공한 파일 개수가 각각 괄호로 표시된다.
  4. 4논리 통합logical_integration

    문맥은 정보를 표시하는 '방법'에 대해서만 기술할 뿐, 실제 다운로드 상황에서의 '데이터 값(개수)'은 제공하지 않는다.

  5. 5결론 도출conclusion_formulation

    질문이 요구하는 구체적인 수치 정보는 문맥 내에 존재하지 않는다.

  6. 6답변 생성answer_generation

    문맥에 없는 정보를 추측할 수 없으므로 답변 불가능으로 처리한다.

근거 (evidence)
  • Queued files, Failed transfers, Successful transfers 항목이 표시되어 있는데, 파일 다운로드 실행시에는 각각의 항목에 대하여 큐에 저장된 파일 개수, 전송에 실패한 파일 개수, 전송에 성공한 파일 개수가 각각 괄호로 표시된다.
  • Failed transfers
  • 전송에 실패한 파일 개수, 전송에 성공한 파일 개수가 각각 괄호로 표시된다.
최종 답변 (final_answer)
주어진 문맥만으로는 답을 확인할 수 없다.
분석 (analysis)
문맥은 파일 다운로드 시 전송 실패 개수가 표시되는 항목의 명칭과 표시 방식에 대해서는 설명하고 있으나, 실제 실패한 파일의 구체적인 수치는 언급하지 않는다. 따라서 질문에 답하기 위해서는 문맥에 없는 외부 데이터나 추측이 필요하다.